歡迎各位來到本系列的第三篇文章！感謝各位看到這邊！

在前兩篇文章中我們對於Cloud Native、以及AWS Free Tier (薅羊毛使用手冊) 有了基本了解。
在本文中我們即將要來切入實戰的細節，運用一些方便的工具來動手設計一個簡單的架構，讓我們對於最終的專案能有個具體的想像

內容大綱：

• 專案目標 —— 多人時間表管理工具
• 業務邏輯 —— 系統要解決的問題
• 架構設計 —— 建立一個清晰的藍圖

專案目標

在這個系列中，我們的最終任務是打造一個 多人時間表管理工具。
這個應用的核心目標很簡單：讓團隊成員能在雲端快速、直觀地管理彼此的可用時間與重要事件。

想像一下，如果你正在與多位同事、同學或專案夥伴合作，經常需要安排會議或分配任務，那麼傳統的時間協調方式（例如訊息群組、Excel 表格）很快就會變得混亂。
而我們要做的，就是用雲原生的方式解決這個痛點。

這個專案將具備以下幾個核心功能：

1.多使用者身分辨識與權限控制：確保每位使用者只能存取自己的資料，也可以新增有更高權限的管理者。

2.可用時段與事件管理：讓成員能快速標記自己的可用時間，並建立或更新事件。

3.集中化 DashBoard：所有成員的時間安排在一個畫面中一目了然，方便協作與規劃。

4.雲端儲存與即時更新：資料安全儲存在雲端，並可在多裝置間同步顯示最新狀態。

在這個過程中，我們會一步步拆解需求，並用 AWS Free Tier 提供的服務（例如 Cognito、S3、API Gateway、Lambda、DynamoDB）來構建一個完全 Serverless 的系統。

業務邏輯

在開始動手之前，我們先退一步，從 業務邏輯（Business Logic） 來思考這個系統應該長什麼樣子。
這樣做有兩個好處：

1.我們可以更清楚知道系統要解決的問題與目標。

2.架構設計會更貼近實際需求，而不是單純為了用技術而用技術。

專案目標：多人時間表管理工具

想像一下，我們的系統需要做到以下幾件事：

• 支援多位使用者註冊與登入，並能辨別身分

• 每位使用者可以新增或編輯自己的「可用時段」與「事件」

• DashBoard 上能快速檢視所有成員在特定日期的狀態

• 資料要能安全儲存、快速查詢，並在多人同時操作時保持即時性

使用者流程範例

• 登入/註冊 → 將自己的資料儲存至系統中

• 建立事件 → 新增會議、代辦事項或可用時間

• 資料同步 → 其他使用者的 DashBoard 自動更新

• 權限管理 → 使用者只能管理自己的列表，動到其他人的不會有改變發生！

架構設計

在進入實作之前，我們先用一張簡單的架構圖，幫自己建立一個清晰的藍圖。
這也是我們在 30 天系列中的重要依據
繪圖工具推薦：Draw.io

市面上有許多架構圖工具，但我蠻推薦 Draw.io，他的優勢在於操作簡單直覺。
還同時有非常多AWS的官方圖示支援，當然也可以自己匯入圖片就是了~
同時也具備多人協作等等不錯的功能，最重要的是完全免費且在瀏覽器就可以使用！

我們的多人時間表管理系統，根據前面的「業務邏輯」需求，會用到以下關鍵元件：

前端（Amazon S3 + CloudFront）

• 負責存放與提供靜態網頁，讓使用者透過瀏覽器訪問系統

• CloudFront 作為 CDN，確保全球存取速度

使用者身份驗證（Amazon Cognito）

• 提供註冊、登入、權限驗證功能，確保不同角色存取正確資料

後端 API（API Gateway + AWS Lambda）

• API Gateway 接收來自前端的請求

• Lambda 處理業務邏輯，例如新增事件、讀取可用時段、更新資料

資料儲存（DynamoDB）

• 儲存所有使用者的時間與事件資料

儘管看起來有多個分開的部件需要完成，但我們幾乎不必擔心伺服器要架在哪，要配置多少運算資源等問題，這就是Serverless的特性，將基礎設施交給雲服務商處理，讓我們能夠將心力投入在業務邏輯的實現。

結語

雖然今天還沒有正式進入AWS Console進行實際操作，不過在經過今天基礎觀念的補充，未來的專案構建也會更加順利，在下一篇我們就即將正式進入AWS Console進行實際的配置囉！