微服務 vs 單體：怎麼選？

單體架構（Monolith）

一個應用程式 = 所有功能
┌──────────────────────┐
│  使用者模組           │
│  訂單模組             │
│  商品模組             │
│  支付模組             │
│  通知模組             │
│  ── 共用一個 DB ──    │
└──────────────────────┘

優點：
✅ 開發簡單、部署簡單（一個專案、一個部署）
✅ 本地函式呼叫，效能好
✅ 資料一致性容易（同一個 DB、同一個 Transaction）
✅ 除錯容易（一個 process）

缺點：
❌ 整個應用一起部署（改一行程式碼要部署全部）
❌ 一個模組出錯影響全部
❌ 團隊越大越難協作（合併衝突）
❌ 技術選擇被鎖定（整個用同一個框架）

微服務架構

每個功能是獨立的服務
┌─────────┐ ┌─────────┐ ┌─────────┐
│ 使用者   │ │ 訂單     │ │ 商品     │
│ Service  │ │ Service  │ │ Service  │
│ [DB1]    │ │ [DB2]    │ │ [DB3]    │
└─────────┘ └─────────┘ └─────────┘
     ↕ HTTP/gRPC/Message Queue ↕

優點：
✅ 獨立部署、獨立擴展
✅ 一個服務掛了不影響其他
✅ 團隊可以用不同技術
✅ 適合大團隊分工

缺點：
❌ 分散式系統的複雜性（網路延遲、服務發現、負載平衡）
❌ 跨服務的 Transaction 很難（Saga Pattern）
❌ 除錯困難（分散式追蹤、Log 聚合）
❌ 運維成本高（每個服務要監控、部署、擴展）

什麼時候該用微服務？

Martin Fowler：「幾乎所有成功的微服務架構，都是從單體架構演進過來的。」

中間路線：模組化單體

// 單體應用內部，按模組拆分
/Modules
  /Users      ← 使用者模組（有自己的 Service、Repository）
  /Orders     ← 訂單模組
  /Products   ← 商品模組
/Shared       ← 共用的東西

// 模組之間透過介面通訊，不直接存取對方的 DB Table
// 未來真的需要拆微服務時，每個模組獨立出去就好

你的 DevLearn 就是單體架構，而且這是對的。一個人開發的學習平台，微服務只會增加複雜度。