出遊之前要規劃路線，在開發之前當然也要先想好目標。

先定義好要做的功能，才不會在實作的時候想到哪做到哪，最後卻發現方向跑偏、流程混亂。
雖然不用立刻就計較每個細節，但至少要有先訂好明確的目標、核心功能，甚至可以先區分好最小可行目標，其他的想法再另外安排優先順序，這樣才能確保專案能一步一步往前推進。

需求定義

核心需求：抽牌

• 從一副 78 張塔羅牌中隨機抽出數張，必需可依需求調整張數
• 可處理正位 / 逆位，在抽牌時隨機決定
• 可選擇不同的牌陣（單張、三張牌、十字牌陣）
• 輸出牌的名稱與象徵意義

資料結構設計

• 牌庫 (Deck)：一個 list，存放 78 張牌 (22 張大阿爾克納 + 56 張小阿爾克納)
• 使用 JSON 格式方便解析
• 每張牌可用 dict 或 class 表示，至少包含：

{
    "name": "愚者 — The Fool",
    "upright_meta": "正位關鍵詞",
    "reversed_meta": "逆為關鍵詞"
}

功能設計

• 初始化牌庫：從 S3 讀取檔案，載入完整的 78 張卡牌資訊。
• 洗牌 (shuffle)：隨機打亂牌庫。
• 抽牌 (draw)：根據需求抽出指定數量，並標註方向。

結果輸出：將抽出的牌整理成易讀的格式。

系統架構

實作步驟

1. 定義 78 張牌的資料
   • 先寫在程式中 (cards.py)
   • 之後改讀取 S3
2. 建立 deck.py：實作洗牌與抽牌功能。
3. 建立 main.py：呼叫抽牌，印出結果。

建立抽牌機制

專案結構

draw-card/           # 專案根目錄
├── main.py          # 主程式碼 
├── service/ 
│ ├── cards.py       # 塔羅牌資料 
│ ├── deck.py        # 洗牌 & 抽牌 
├── requirements.txt # 套件

本來是這樣想的，但是突然想起這段程式預計跑在 AWS Lambda...

參考官方文件：Working with .zip file archives for Python Lambda functions

You can declare simple functions written in Python or Node.js inline in an AWS CloudFormation template.
Because of these limitations, declaring functions inline is best suited for very simple code that does not change frequently.

Lambda 適用於功能單純、邏輯簡單的實作，很符合這次的練習情境。

Your .zip file should have a flat directory structure, with your function's handler code and all your dependency folders installed at the root as follows.

zip 檔案應該具有扁平的目錄結構，將函式處理程式碼和所有依賴資料夾都安裝在根目錄。

Lambda expects your source code and its dependencies all to be at the root of the .zip file. If the .py file containing your function’s handler code is not at the root of your .zip file, Lambda will not be able to run your code.

Lambda 要求原始碼和依賴都位於 .zip 檔案的根目錄。
如果處理函式 .py 檔案如果不是放在 .zip 的根目錄，Lambda 就跑不起來。

根據以上敘述，Lambda 適用的專案結構其實是這樣：

draw-card/              # 專案根目錄
├── main.py             # 主程式碼
├── cards.py            # 塔羅牌資料
├── deck.py             # 洗牌 & 抽牌
├── requirements.txt    # 套件

Lambda 可以使用 .zip 檔案部署，也支援 容器映像檔（Container Image）。
考慮到這次要實作的功能單純，只做串接而不是一個完整的服務，所以選用 .zip 的方式，因此優先參考 .zip 的部署文件。

到這裡，最小可行的需求、資料結構、功能設計和執行環境都已經構思完成。
如果一開始就盲目動手寫，不但可能寫到一半發現方向跑偏，還可能因為元件選擇錯誤，在部署和測試時遇到困境。

光有幹勁沒有規劃，當系統越是複雜，就越容易在多個功能和資料流之間迷路。
想要紮實地將專案往前推進，勢必需要先有謀略再付諸行動。

資訊補充

AWS 上那麼多運算服務，為麼選 Lambda?

1. EC2 (Elastic Compute Cloud)
   可視為架一台虛擬機，要自己維護 OS、網路、防火牆、安全性更新。
   → 為了一個小小的抽牌程式開 VM，成本和維運負擔都太重。
2. ECS / Fargate (容器服務)
   適合長時間運行或多容器協作的微服務架構，需要準備 Dockerfile、ECS Task 定義。
   → 運行成本和設定複雜度比 Lambda 高。
3. App Runner
   自動跑 web 容器，類似「無伺服器版的 ECS」，但是會一直開著服務，並產生固定費用。
   → 只是 demo 價格上不划算。

最主要的原因，當然還是...

依照目前的需求跟情境，Lambda 做起來簡單，還最便宜阿...