那天在 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 變更時,我能夠最快的調整程式碼、而重點在於容易釐清模組之間的耦合性與相依關係,軟體專案開發而不是每天讀了什麼書?又看得了什麼內容,看了之後、究竟書中的內容那些你真的貫徹實行在哪一個產業、或者(做了/完成)了那些專案?因為大部分的企業端問題是你真的做過那個產業的 Known-how 你才會真的明瞭他們想解決什麼問題?或者什麼是最適合他們的?通常這才是我覺得比較有用的,因為軟體專案終究是要做出(實績/東西)出來的!是要交付給客戶的、要收錢的,不是自己做爽的,是要有產出的,不是看完書嘴砲完就結束了,這裡是業界,不是學界。而且帶學生做看板那真的不算什麼業界經驗,為什麼我這麼說?因為需求完全是自己發想,不是訪談而來,那是你想怎麼做就怎麼做,這種軟體成品是做給自己用,但專案不是你想怎麼做就怎麼做,因為客戶需求總是會變,所以我們才談敏捷、才談 TDD、就因為我們無法完全掌握住需求不是嗎?DDD 也是為了解決這樣的問題,因為軟體是做給客戶用的,所以,那充其量那只能稱為一個 Side Project 而已。
圖(一)、以線上房屋貸款為例的 C4 Model
前面提到 c4 Model,它其實提供了一個非常宏觀的角度來讓你的 System Context 包含你的上下文,並如何切割看入系統的實作,就算我們不一開始就撰寫程式,記得我先前的文章中提到,許多 DDD 的開發者若忽略實作的工程方法,還是會造成隱憂,即便 Domain Model 多完美,或者,再完美的 Domain Model 若無法串接到實作那又有什麼用呢?這是我這場演講中的另一個想要傳達的重點。
再來,這次演講中,我也提到我使用 Clean Architecture 的 Plug-In 架構來實踐高可用性,這後續的工程實踐是配合 C4 Model 來進行的,因為我沒有一開始就決定的外部系統,這個 Application 外部是要有明確的 Context Map 來表達相依,這我以後有機會再詳細介紹,本篇先說明此演講中傳達或未傳達的部分。
圖(二)、在一個 Use Case Boundary 內的 System Context
演講中使用的 VS 擴充套件是我撰寫的,由於時間急迫暫時由 DB 產生 Model 這部分我已經解釋過很多次了,這是這個 Tool 目前的限制部分,跟 Clean Architecture 架構被產生出來後可以解決的專案問題是兩回事,否則我如果在這個 tool 讓你一個 TextBox 一個個欄位讓你去新增 Dto 的欄位,你也很辛苦,效率也慢,所以我說了,它就是個工具,是個工具而已,幫助你少寫重複程式碼的工具而已,並不是我聲稱 "它" 可以產生 Clean Architecture 的程式碼,因為 "它" 確實是可以產生 Clean Architecture 的程式碼,請先去看過 "它" 產生的程式碼後再做評論好嗎?
接著,說明這個工具,共有四個 Project Templates:
- Application
- Domain
- Infrastructure
- WebUI for ASP.NET Core 3.1
它是一個 MediatR 實作的 CQRS 的 Clean Architecture,當專案都建起來時,方案總管應該要有這四個專案:
圖(三)、CleanArchitectureCQRSExtension 產生的四個專案
當時 DDD 演講中的範例,我已經上傳 Github 有興趣的可以上去了解。
Github: https://github.com/wugelis/DDDTaiwanLab
套件可重這裡下載與安裝: https://marketplace.visualstudio.com/items?itemName=GelisWu.CleanArchitectureCQRSTemplate
這個工具如何使用,可參考我先前文章: 在領域驅動下使用 Clean Achitecture 實現高可用軟體架構
我所分享的內容,都是我 20 多年來,在流通業、金融、信託、電信、政府機關大大小小的案子的實際專案開發經驗,而不是嘴砲的,熟悉我的朋友會知道,我們這裡的顧問可不是在客戶面前嘴砲完就拍拍屁股就走人了,我是要真的將它實作出來的,軟體專案開發是得在不同產業內的大大小小的案子中磨練 + 看書得到期中的養分之後再應用在實務中慢慢成長的,不是只有自己做爽的。
關於 Gelis:
資深 .NET 技術顧問
FB 社團 (軟體開發之路):
https://www.facebook.com/groups/361804473860062/
FB 粉絲團 (Gelis 的程式設計訓練營):
https://www.facebook.com/gelis.dev.learning/
我講授過的課程 SlideShare:
https://www.slideshare.net/GelisWu
以下是我經營的項目與內容:
(1). 企業內訓課程
(2). 專業顧問
企業內訓課程:
1. .NET Core 3.1 從入門到進階
先前實體課程連結
2. 跨平台的 Web API Framework 框架設計
先前實體課程連結
3. 決戰 OOAD 系列課程 - 使用 UML
先前實體課程連結
4. 單元測試 UnitTest 與 Moq 物件實務課程
先前實體課程連結
5. 快速開發系列 - C# Project Templates 範本設計
留言
張貼留言