那天在 DDD 實踐演講中 Clean Architecture 裡未講完的部分
圖、以線上房貸系統為例的 Domain Model 領域模型 那天，在 DDD 分享了一個主題［實踐 Clean Architecture（實作高可用性的軟件架構）］，由於講得不好而招致 Teddy 的批評，還寫在部落格上，既然你都可以指名了，那我也不怕指名，今天，我就針對上次未講完的部分再來做個補充說明，也就是我怎麼在 DDD 裡實踐軟體架構設計時，怎麼樣具備高度延展性？如何真的做到高可用？在筆者的專案經歷裡面，也常常遇到類似的情況，比如新增店鋪或修改店鋪邏輯時不影響原有核心架構？或者是我依照使用者修改信託的申辦邏輯時，如何在修改的同時，又不易動到原有的已經申辦的會員後台管理系統？在還沒有 DDD 的思維介入時，將商業邏輯服務化是普遍的解決方式，筆者當時的跨平台 Web API Framework 框架便是要解決這樣的問題，因為我將商業邏輯變成可抽換的 Component (Business Object)。 補充：可抽換的商業邏輯架構可參考我公開的 NuGet 套件 Easy Architect Framework Ok, 如果切換為 DDD 以領域模型為主的思考模式差異會有多大？我們以那天，我在『實踐 Clean Architecture 實作高可用性的軟件架構』中所使用的［線上房貸申請為例］，需求如下： 需求1： 銀行顧客，或是非銀行顧客可到網路銀行線上房貸申請首頁，使用網銀帳號或簡訊密碼進行身份認證後，可填寫「基本資料」與「貸款資料」， 非銀行顧客須先填寫「基本資料」 課程中，我以 C4 Model 來開場的用意其實是要描述軟體架構 如何高可用 ？在 DDD 裡面，我們著重在領域核心，我們都不建議一開始就寫程式，而是先了解全貌，至於全貌是什麼？許多敏捷的概念我這裡不再祥提，有興趣的讀者可參考相關文章，沒了解全貌而貿然的設計 Domain Model ，即便是 DDD 我認為也會提高失敗的風險［可參考先前文章： DDD 中為人所忽略的『軟體工程』與『工程實踐』方法 ］， 我們在談理論時，最終就是要貫徹到實作中，而 C4 Model 提供一個對應到實作的一個很好的方法，搭配 Clean Architecture 這對於真正的高可用的軟體開發有非常大的幫助，因為在 Domain Model 變更時，我能夠最快的調整程式碼、而重點 在於容易釐清模組之間
