那天在 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 變更時,我能夠最快的調整程式碼、而重點 在於容易釐清模組之間...