架構模式多到讓人困惑的原因是：很多人把它們當成選項，而不是解法。「Clean Architecture 還是 Layered？」這問法本身就錯了——它們解決的不是同一個問題。
這篇地圖的目的是：你知道自己在哪個問題上，就能找到對應的工具。
按問題類型分類
「我的業務邏輯和 UI/DB 耦合太深了」
→ Layered Architecture（三層）：分離 presentation / business / data，是所有後來模式的起點。複雜度低，適合大多數中小型系統。
→ Clean Architecture / Hexagonal / Onion：解決 Layered 沒有強制依賴方向的問題。Domain 不依賴任何外部，所有外部細節在邊緣。帶來更好的可測試性和可替換性，代價是更多的 interface 定義。三者本質相同，名字和強調點不同。
「多個部門叫同一個概念，code 裡卻只有一個混亂的 class」
→ DDD 戰略設計（Bounded Context + Ubiquitous Language）：在業務邊界上切割 domain model，讓不同 context 的「訂單」可以是不同的東西。適合業務複雜度真實、多個團隊各有自己語言的系統。
→ DDD 戰術設計（Entity / Value Object / Aggregate）：在一個 context 內部建模，讓 code 語言和業務語言對應。Aggregate 是一致性邊界，不是方便 JOIN 的 cluster。
「讀取和寫入的需求互相扯後腿」
→ CQRS：把讀模型和寫模型分開。Simple CQRS 只是程式碼組織；Full CQRS 是獨立的讀資料庫，帶來 eventual consistency 的代價。讀寫比極度不對稱、讀模型需要大量 denormalize 的系統才值得引入 Full CQRS。
「資料庫存的是當前狀態，但我需要歷史——每次改動發生了什麼」
→ Event Sourcing：用事件序列取代狀態快照，當前狀態 = fold(events)。Audit trail 免費附送，可以重播到任意時間點。代價是 schema 演進困難、projection 要維護。小系統不要碰。
「微服務拆開之後，跨服務的資料一致性怎麼保證」
→ Saga Pattern：用補償操作取代跨服務 transaction。Choreography 事件驅動（解耦但可見性差）vs Orchestration 中央協調（可見性好但耦合中心）。只有真正的多服務多資料庫場景才需要。
「前端的 UI 邏輯和業務邏輯混在一起」
→ MVC / MVP / MVVM：三種 UI 層的分離模式，各自針對不同環境。MVC 是起源，MVP 解決桌面應用的測試問題，MVVM 解決手動同步的問題。現代前端框架（React / Vue / Angular）不是純粹任何一種，但詞彙仍然有效。
複雜度 vs 適用場景
| 模式 | 適用場景 | 引入複雜度 |
|---|---|---|
| Layered（三層） | 大多數 CRUD / API 服務 | 低 |
| Clean / Hexagonal / Onion | 業務複雜、需要高測試覆蓋 | 中 |
| DDD 戰略設計 | 多團隊、多業務部門 | 中高 |
| DDD 戰術設計 | 複雜 domain rule | 中 |
| CQRS（Simple） | 讀寫邏輯明顯不同 | 低 |
| CQRS（Full） | 讀寫比極度不對稱 | 高 |
| Event Sourcing | 業務歷史重要、需要 replay | 高 |
| Saga | 微服務跨服務一致性 | 高 |
沒有「最好的架構」——只有「這個問題最適合的解法」。系統的複雜度應該和你實際遇到的問題複雜度匹配，不是和你想用的模式匹配。
各模式的深入說明在各自的文章裡，這裡只是地圖。遇到具體問題時，先確認問題類型，再選對工具。