DHH 的架構三部曲：Majestic Monolith、Citadel 與 Outposts

DHH（David Heinemeier Hansson，Rails 創始人）長期反對盲目採用微服務，提出了一套漸進式的架構演進觀，核心是三個層次：Majestic Monolith → Citadel → Outposts。

核心論點

「微服務所帶來的痛苦是巨大的。除了 Majestic Monolith，還應該有人整理出 The Citadel 這個模式。」
— DHH, Twitter

大多數系統不需要微服務。微服務架構在組織規模達到一定程度之前，通常帶來的複雜度遠超過其解決的問題。

架構三層次

graph TD
  A[Majestic Monolith 壯麗的單體] -->|壓力增加 無法應對| B[Citadel 城堡]
  B -->|特定需求 有限抽離| C[Outposts 前哨站]

1. Majestic Monolith（壯麗的單體）

第一選擇，也是預設架構。

所有功能部署在同一個應用程式中，共享同一個資料庫、同一個程式碼庫。

優勢：
- 部署簡單，只有一個服務需要維運
- 跨模組呼叫是本地函式呼叫，無網路延遲
- 交易（Transaction）天然保持一致性
- 重構容易，IDE 可跨模組追蹤

適合： 絕大多數應用程式，尤其是初期與中期規模

2. The Citadel（城堡模式）

當 Monolith 已達極限，但還不需要全面微服務化時的中間路線。

核心單體（Citadel）依然存在且佔據主導地位，但允許少數 Outposts 以獨立服務的形式存在於外圍，處理特定的發散性需求。

graph TD
  subgraph citadel[Citadel 核心城堡]
    M[Rails Monolith]
    M --- DB[(主資料庫)]
    M --- Auth[認證模組]
    M --- Wiki[Wiki 模組]
    M --- Blog[部落格模組]
  end

  subgraph outposts[Outposts 前哨站]
    O1[FHIR Gateway]
    O2[即時推播服務]
    O3[PDF 處理服務]
  end

  M -->|API 呼叫| O1
  M -->|事件推送| O2
  M -->|Job Queue| O3

關鍵原則：
- Citadel 是主體，Outposts 是例外
- Outposts 為了組織、效能或實作需求而存在
- Citadel 永遠可以呼叫 Outposts，但不依賴它們運作

3. Outposts（前哨站）

從 Citadel 抽離出來的個別服務，通常有明確的抽離理由：

抽離理由	範例
技術限制	FHIR 標準需要 Java 的 HAPI FHIR
效能需求	即時 WebSocket 用 Elixir/Phoenix
組織邊界	不同團隊負責不同服務
安全隔離	支付、醫療資料需要獨立部署環境

與微服務的對比

	微服務	Citadel
服務數量	數十至數百	1 核心 + 少數周邊
部署複雜度	高	低
跨服務通訊	大量	有限
資料一致性	需 Saga/Event Sourcing	單體內天然一致
適用時機	Netflix/Amazon 規模	絕大多數公司

與 NanoClaw 的對應

nicklecheng.turbos.tw 的架構本身就是一個 Citadel 模式的實踐：

graph TD
  subgraph citadel2[Citadel]
    Rails[Rails Blog]
    Rails --- PG[(PostgreSQL)]
    Rails --- Wiki[WikiEntry]
    Rails --- Series[Series/Post]
  end

  subgraph outposts2[Outposts]
    NC[NanoClaw AI Agent]
    Discord[Discord Bot]
  end

  NC -->|SSH / Rails Runner 發布 WikiEntry| Rails
  Discord -->|訊息觸發| NC

Rails 是核心城堡，NanoClaw 是外圍的 Outpost — 只在需要時（發布 wiki）才與核心溝通。