什麼是 Clean Architecture？

Clean Architecture 是一種強調分層與解耦的架構設計模式，旨在保持系統的可維護性、可測試性與靈活性。透過嚴格的分層設計，Clean Architecture 確保了業務邏輯與框架、工具或外部依賴（如資料庫、使用者介面）分離，使得系統可以在不影響核心業務的前提下進行擴展或技術變更。

這樣的設計思想與 DDD（Domain-Driven Design）十分契合，DDD 強調以業務需求為導向，並透過劃分業務領域來管理系統的複雜性。而 Clean Architecture 則通過分層和依賴反轉（DIP）的方式，使核心業務邏輯可以獨立於技術實現，達到高內聚、低耦合的目標。

如果你對 DIP，Dependency Inversion Principle（依賴反轉原則)，不太清楚，建議先了解物件導向設計中的 SOLID 原則。這對後續在建置 Interface 的理解會非常有幫助。

在剛開始查詢 Clean Architecture 的時候會一直看到這張圖：

Reference: The Clean Code Blog by Robert C. Martin

這圖常讓初學者不知該如何讓自己的專案符合這樣的架構。實際上，事情並沒那麼複雜。只要專注讓專案有合理的分層，並確保內層專案（如 Domain、Entity）保持其獨立性，避免依賴外部專案（如 Application、API、UI、DB），就已經實現了乾淨的架構。

• 內層：專注於業務邏輯，保持獨立，不依賴外部系統或技術。
• 外層：可以依賴內層，但內層不應依賴外層，確保系統內部邏輯不受外部技術變更的影響。

請注意，Clean Architecture 本身是一種系統架構，不等同於 DDD，但可以用來實現 DDD。

Clean Architecture 與 DDD 的架構對應

1. Domain 層

• 核心目標：封裝業務邏輯，維護業務一致性。
• 內容：Domain 層是 Clean Architecture 的核心，包含 DDD 的 Aggregates、Entities 和 Value Objects。所有與業務相關的行為和規則都集中在這一層。
• 設計原則：
  • 聚合：Aggregates 負責管理相關業務對象，確保業務規則的一致性。
  • 不可變性：Value Objects 應保持不可變，避免業務狀態被意外修改。
  • 隔離外部依賴：Domain 層不應依賴基礎設施，只專注於業務邏輯。

2. Application 層

• 核心目標：處理具體應用流程，協調 Aggregates 操作。
• 內容：Application 層類似 DDD 中的 Application Service，負責具體的業務用例，以及管理系統的應用流程。這層不應包含業務邏輯，而是調用 Domain 層的 Aggregates 來執行業務操作。
• 設計原則：
  • 用例驅動：每個服務代表一個具體業務操作（如創建訂單、處理支付）。
  • 抽象基礎設施：Application 層定義接口，交由 Infrastructure 層實現，確保業務邏輯不依賴具體技術。
  • 依賴反轉：透過抽象來與外部系統交互，如使用 Repository 模式。

3. Infrastructure 層

• 核心目標：具體實現基礎設施的技術細節。
• 內容：Infrastructure 層負責與外部系統交互（如資料庫、第三方 API）。例如 Repository、Unit of Work 和 DbContext 的具體實現都在這一層。
• 設計原則：
  • 資料存取的抽象化：透過 Repository 實現資料存取邏輯，並抽象化應用層的接口。
  • 依賴反轉與接口實現：Infrastructure 層實現應用層定義的接口。
  • Unit of Work Pattern：管理多個資料庫變更操作，確保操作的原子性。（建議但非必需）

4. Presentation 層

• 核心目標：提供使用者介面與外部訪問點。
• 內容：Presentation 層負責提供系統的外部接口，包含 API、gRPC 或 GraphQL 等入口應用程式，用於接收外部請求並傳遞到 Application 層。
• 設計原則：
  • 獨立於業務邏輯：Presentation 層的改動不應影響應用層或核心業務邏輯。
  • 靈活替換：根據需求更換 UI 框架或 API 技術，不影響系統內部結構。

依賴方向與分層關係

Clean Architecture 與 DDD 的核心設計理念就是依賴反轉原則。外層依賴內層，而內層不應依賴外層的技術實現。於是 Domain 層是系統的核心，只負責業務邏輯，不應依賴任何外部技術或框架。Application 層通過接口與 Infrastructure 層進行交互，實現基礎設施的抽象化。最外層的 Presentation 層則負責將外部請求轉發到應用核心。

所以圖示會變成這樣，由外層依賴內層。

我們把它變得更直白一點。

這是不是一切都清晰了起來呢？未來在實作的時候，要注意絕對不能讓內/下層專案依賴著外/上層專案。

結論

Clean Architecture 與 DDD 的結合能夠讓系統具備高內聚、低耦合的特性：

• Domain 層：封裝業務邏輯，通過 Aggregates 確保業務規則的一致性。
• Application 層：處理具體業務流程，並通過抽象化接口與基礎設施交互。
• Infrastructure 層：實現具體技術細節，包括資料存取與第三方服務。
• Presentation 層：提供系統外部接口，處理用戶請求。

這樣的分層設計符合 Clean Architecture 的依賴反轉原則，也能充分發揮 DDD 的業務驅動特性，最終達到高靈活性、可測試性與可擴展性的目標。

到這裡，基本理論都快速介紹完了，我忽略了許多的故事與細節，畢竟這系列的重點是實作，明天就可以開始用 DDD 實際設計我們的 Todo List Application囉！