以領域為核心重新設計的線上房貸申請系統 use DDD （2）
以領域為核心重新設計的線上房貸申請系統 use DDD （2） 前言 在前一篇文章： 以領域為中心的：線上房貸申請系統設計 use DDD 中，筆者簡單的介紹一下以房貸線上申請為例子的的領域模型如何繪製、以及用一點時間將領域模型撰寫成基本的程式碼骨架，現在，本篇文章將接續直播的內容持續的調整程式碼。 Visual Studio 2019 的 .NET 5 的整潔架構骨架 這裡也同步的調整一開始的設計，也就是 Repositories 的擺放位置，一開始我是放在 Domain Service 也就是領域層，有網友發現表示以依賴反向來說，應是由 Application Service/Use Case Layer 來存取 Repositories，雖然 Entity 可以透過 Factory 來產生實例，但是 Entity 必須透過 Aggregate 來無持資料的完整性，但調用 Entities/Value Objects 本來就是 Application Services/Layer 的責任，所以 ICustomerDetailRepository 放置在 Application Seervice 是比較合理的，因為本來就是 Application 來操作 Aggregate Root 並維持資料的完整性。 圖（一）、透過常見的依賴反轉來解決問題 圖片取自：Clean Architecture 無暇的程式碼 - 整潔的軟體架構設計篇 因為 Entity 本來就在 Domain Layer，為了領域邏輯的獨立性，並不應該直接相依 Repository，外部調用 Domain 需要領域邏輯來操作得依靠 DIP 即可解決該問題。 另外，補充說明，就是其實以『依賴反向』來說，Clean Architecture 的 Aggregate Root 要封裝 Domain Layer 的多個的 Entities/Value Objects 的操作來講，將 ICustomerDetailRepository 放置在 Application Layer 這是正確的。 怎麼說呢？以 Clean Architecture 整潔架構一書中這張圖來說明，HL1 依賴 <I> 介面，早期我們大多用 OO 中的多型來達到這個效果，就是 HL1 要呼叫 +Ｆ()