軟體架構設計 與 DDD 相關問題的答客問

軟體架構設計 與 DDD 相關問題的答客問

圖片來源：https://c4model.com/

前言 由於我最近蠻多文章在介紹 Clean Architecture 與 DDD 領域驅動設計與開發以及 C4 Model，但是套用到他目前的專案中卻不知道如何開始？再者，TDD 只是概念上了解，但是在真實的專案中如何開始？包括我的 OOAD 課程中使用的 Modeling 的分析方法在 TDD 下真的也可以使用？UML 不會回歸 Waterfall 嗎？這些讓人一頭霧水？

問題一：

您部落格中提到的 C4 Model 的概念究竟是什麼？我現在在現有專案中要怎麼使用？


回答： 

我在前一篇文章中提到了 Simon Brown 的 C4 Model，也是我在當時 DDD 的分享中主要內容之一。

圖（一）、以決戰 OOAD 課程中的線上房貸申請系統為例的 C4 Model 以決戰 OOAD 課程中的線上房貸申請系統為例的 C4 Model

為什麼當時我會特別提到 C4 Model？主要是因為， 我覺得他的概念不錯的地方在於它是走 DDD 的角度來發展的，很多人說他為什麼要另外創創造一個表示法？部分比較傳統的開發者甚至是批評他的內容是四不像，但是這我覺得其實是種誤解，因為其實作者有說明 C4 其實沒有限定使用哪一種表示法，我覺得 C4 最棒的地方（也是有些朋友會誤解的）在於它將軟體分為 4 個層次（Level），這四個 Level 並不是指分層的結構，而是作者用一種抽象化的方式將軟體從最外的 System Context 視角（C4的System Context 也可對應到 DDD 的 Bounded Context），由外一塊塊的往內窺視，因為作者覺得軟體架構就像 Google Map 一樣，由最頂端往下看就是一顆地球，接著放大某些視角，就可以看見台灣，再放大台北市就可以看見都市、接著再放大就會看見街道，而街道 = Code ，就是最細節的部份。

套用 C4 的最主要目的，其實是希望透過這樣的『抽象』來建立一個【領域專家】與【開發團隊】溝通沒有隔閡的通用語言（Ubiquitous Language）、來讓『技術視角』與『業務視角』的溝通可以像 Google Map 視角一般，開發人員可以看見要建造哪一個『街道』，而領域專家也可以 看到整個地球的『哪一個國家的（街道）會被建造或是修改』。

而透過這樣的抽象，對應到軟件架構，讓我們快速可以反映架構的調整，進而做到高可用的軟件架構。

至於如果要在現有專案中使用的話，我的回答是這樣的：就如同我上方所提及的，C4 Model 使用一種抽象化的方式，將軟體架構建立 4 個層次的視角，但這不是一蹴可及的，你得先從基礎的『重構』開始做起，並搭配『單元測試』一起進行，專案的 執行／開發 過程中一定會頻繁的重構，可能因為需求的調整、或擴增的需求、又或者因為 Bug Fix，因為不管是清理遺留代碼，或者是增加可擴展性，重構都是必須的項目，當然，重構的過程當中得一定要有 Unit Test 的保護之下，你的重構的動作才是安全的，因為我可以很短的時間內快速的驗證商業需求是否仍然正常，沒有因為重構的動作而被改壞，這是確保專案開發過程中能夠『短時間的快速反應』並『達成敏捷』的最基本條件，這真的至關重要。關於如何讓軟體架構變得敏捷，先前我有撰寫許多相關文章：http://gelis-dotnet.blogspot.com/2019/06/blog-post.html 〔您的軟體架構構敏捷嗎？（二）-持續演進的軟體架構〕其實說穿了就是持續有撰寫單元測試的重構下才有短時間應付變化的能力，若能進一步以 TDD 為開發的方法效果會更好，當然門檻也越高，但是這也更適合在敏捷的環境下。

做到上方的要求只是第一個門檻，接著你得加強與實踐相關稍進階的工程方法，像是我課程中提到的 MDA/MDE/MDD 或者是 TDD/BDD/ATDD 甚至是 SBE 實例化需求等等，這些都需要一些抽象化思考的能力，但落實在程式碼上又需要與實際的工程方法結合與最基礎的 OOA 與 OOD 等等，這部分可參考先前的文章：DDD 中為人所忽略的『軟體工程』與『工程實踐』方法。

以 DDD 來說，MDA 是將您的抽象化的 Domain Modeling 對應到程式碼的一種方式之一。至於 Domain Modeling 使用哪一種圖形表示法在 C4 Model 並沒有限定種類，只是 MDA 基於 UML 上。

圖（二）、OMG 提出的 MDE 模型驅動工程 

在MDA上定位的BPMN 


圖片來源：https://research.linagora.com/pages/viewpage.action?pageId=3639295

當然你也可以使用 BPMN，但 BPMN 仍然是建構在 MDA 的 CIM (Computation Independent Model)上。

關於 MDA (model Driven Architecture) 的細部解釋可參考 決戰 OOAD 系列課程（線上版） 內有一個章節針對 MDA 有詳細的說明 & 實務開發。

傳送門： https://hiskio.com/courses/347/about?promo_code=437QJMG

當時有分享到 C4 Model 的演講投影片如下：

https://www.slideshare.net/GelisWu/clean-architecture-239574954


問題二： 

如何將它現在正在實作的專案改成支援 Clean Architecture 的軟體架構？


回答： 

若要將現有專案調整成乾淨架構 Clean Architecture 得先從基礎的『分層』開始，簡單的說，你得先將程式碼放置在『適合』的地方，這個適不適合是基於 Clean Architecture 角度來切割的，先把程式碼放置在對的地方後，接著是解決『相依性問題』。

幾個例子： 先將 DataAccess 抽離出來放置在 Infrastructure Layer 裡，這時你得抽離原本 Website 直接相依 DataAccess 問題，需改成相依 Infrastructure，然後建立 Application 層將 Business 業務邏輯抽離出來放置在 Application 裡，這裡就有很多程式碼重構等問題，包括拆 Libraries Project 抽離 Interfaces 等等，以上是如果你原先將業務邏輯寫在 Website 上的話，如果你原本就是有 Web API 與 明確的前後端 (Front-End Framework/Server Side) 的處裡或甚至 SPA 的應用架構的話以上這些動作會更容易。

再來，如果你原本沒有 Repository 得針對 Business 抽離並實作對應的 IRepository 比如客戶資料管理 ICustomerRepository 等並放置在 Domain 層，所以你必須將 Domain 層建立起來，把 ICustomerRepository放置在 Domain 層，並讓 Infrastructure 參考 Application，而因為 Application 本來就需要參照 Domain 所以自然能夠在 Infrastructure 裡實作 ICustomerRepository 的實體。

最後再將抽離出來的 Entities 放置在 Domain 裡面。

針對如何修改遺留代碼與讓它更好維護可參考這本書：

圖（三）、修改軟件的藝術-建構易維護代碼的9條最佳實踐 

修改軟件的藝術-建構易維護代碼的9條最佳實踐


讀這本書建議搭配 『重構-改善既有程式碼設計』與『Clean Code 無暇的程式碼』與『Clean Archiecture 無瑕的程式碼：整潔的軟體設計與架構篇』一起服用效果更佳。

關於 Clean Architecture 可參考我在 DDD 社群分享的內容的 Sample Code：

https://github.com/wugelis/DDDTaiwanLab


問題三： 

如何開始撰寫單元測試？如果是他手上的這個專案為例，要從哪裡開始？


回答： 

2023-11-22 （更新）

由於已經事過境遷，針對問題三，有些回覆已不符合現在情況，我現在稍作修正，來做比較全面性的回答。

這問題可以分兩部分：

1). 第一個部分針對 Legacy System 的如何撰寫單元測試？

因為針對『如果是他手上的專案為例』這不是立即能進行 TDD 或者馬上會有適合的切入點。所以，原先的回答比較是針對 Legacy System。

這個問題，我得先解釋在現有系統中撰寫單元測試有兩個主要好處：

  • 了解系統的複雜度
  1. 系統複雜度越高，代表職責越容易牽扯在一起
  2. 複雜度高，也代表不好維護，通常是重構的優先選擇
  3. 重構的過程，同步撰寫測試，在測試的保護下的重構才是安全的重構
  • 解決外部依賴
  1. 外部依賴越強，代表耦合性越強，代表越難撰寫與進行測試
  2. 如果因為外部依賴強，導致撰寫（測試／模擬）成本過高，那麼就建議直接撰寫整合測試
  3. 在有整合測試的保護下，後續對 Legacy Code 撰寫 Unit Test 才有個後盾

若真的不知道從何著手，一個是可先從系統中修改幅度最高的業務邏輯開始撰寫單元測試、第二個就是針對容易出現問題的業務邏輯（相關的功能切入尋找共用性最高的業務邏輯）來開始先撰寫、第三就是找我上單元測試 UnitTest 與 Moq 物件實務課程 XDDD

可參考先前實體課程-傳送門： https://mystudyway.kktix.cc/events/softshare-unit-test-01


2023-11-22 （更新）

2). 這是第二的部分對於 DDD 與 使用 Clean Architecture 的系統，反而能夠更容易的『只針對〔邏輯/Domain Layer〕做測試』，這裡也可以在後來的文章『軟體架構設計：無題』中解釋這部分怎麼進行，包括使用 TDD 驅動開發時，透過需求來驅動整個架構的拓展，對於一個容易擴展的架構該用哪一種架構最適合呢？答案當然是 Clean Architecture 或者是六角架構了。


我後來的文章『軟體架構設計：無題』裡有完整的呈現這個部分，有興趣的可閱讀此篇文章。


而完整的範例可參考：

https://github.com/wugelis/AdapterInOutLayerSapmle



問題四： 

接續上題、另外 TDD 開發方法在 DDD 領域驅動開發上如何使用？


回答： 

DDD 領域驅動開發是一個相當龐大的主題，它提供了『戰略（Strategic）』與『戰術（Tactical）』兩個方向的指導方針，簡單說、戰略除了對團隊開發合作甚至是協助企業如何運用資源外，也提供一種思考模式，稍微有別於傳統 OOAD 的思考模式。而戰術則提供建模、分析商業需求與捕捉領域知識，如何尋找領域模型與界定系統邊界的指導方針，可謂博大精深，我無法在這裡解釋完畢，未來再另闢章節完整介紹 DDD。

圖（四）、DDD 戰略建模 

DDD 戰略建模


TDD 的部分，有追我文章的讀者應該會有些概念才對，這裡就不再詳述，不熟悉可先參考【敏捷的軟體架構設計：可擴展的軟體架構】 [http://gelis-dotnet.blogspot.com/2019/04/blog-post_22.html] 與 【您的軟體架構夠敏捷嗎？】[http://gelis-dotnet.blogspot.com/2019/04/blog-post.html] 以及【您的軟體架構夠敏捷嗎？（三）- 使用 TDD 實現最後的設計】[http://gelis-dotnet.blogspot.com/2020/05/blog-post.html] 等、簡單的說，有了 Domain Model 再開始撰寫紅燈測試。

圖（五）、通用語言 Ubiquitous Language

領與專家 與 開發團隊 先有通用語言 Ubiquitous Language 後，建模時別忘了重要的技術實踐，程式碼可以對應到領域模型、在 Unit Test 的保護之下，基於 Clean Architecture 方可以真正實踐可擴展的商業模型的程式碼。


最後： 

這些實踐是一條漫漫長路，不是短時間內一蹴可及的，相關軟體工程實踐方法都不可少，反而要更（精煉／熟悉）這些原本的開發技術，因為國外在談敏捷的大師們通常都已經是撰寫程式的高手，他們談敏捷只是想解決如何讓這些高手們在同一個團隊一起工作而已。



關於 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 範本設計

留言

張貼留言

這個網誌中的熱門文章

軟體工程師 - 成長的 10 個階段

圖片
軟體工程師 - 成長的 10 個階段 前言 先前，我在 Study4 小聚 #6 分享的一場關於軟體工程師 & 架構設計的養成之路，在該議程中，我分享了軟體工程師的 10 個階段（你的階段如有雷同、應該是...純屬巧合。XDDD） 哪 10 個階段？ 我將軟體工程師的成長依序分為 10 個成長階段，因為隨著技能的提升，你該擴充的 不會只是只有軟體開發技術，溝通與協作能力尤其重要 ，也像是『康威定律』中所提到的， 你的軟件的設計 & 或系統設計本質上反映了企業的組織機構。系統各個模塊間的介面的設計，也反映了企業各個部門之間的信息流動和合作方式，這些技能再進行軟體架構設計時也息息相關 ，團隊在進行模組設計時需要頻繁的溝通，這些、都是是否能將軟體做好的關鍵因素。 如 Logo 圖片，我依序說明每個階段的成長歷程。 1). 初始開發階段、熟悉 Programming/Developer 階段（PM/PO/SD 給規格後加以實作出來），並能夠藉由 模仿 來學習。這是剛進入軟體產業的學習階段。 2). 此階段代表已懂得透過重構來讓程式碼有基本的可維護性 、已能熟用 DRY (Don't Repeat Yourself)，進入這個階段代表已經有基本的程式語言的基礎， 應付 Programming/Developer 日常 工作 上的需求基本上沒什麼太大的問題。 3). 這裡的專案收尾代表對於專案開發已經有某些程度的認知、掌握度。我所提的掌握度在於了解『技術債』的產生緣由 與 危害，在 Programming/Devloper 層面懂得透過 S.O.L.I.D./Design Patterns 解決問題 並 開始能夠 自我學習 + 自我成長 。 4). 我這裡用『紀錄』 代表能運用所學 + 將使用者需求運用 〔邏輯思考〕 與 〔抽象化〕 轉化為程式碼 + 並能 自我成長 將經驗保存下來。我認為這是跨越只是（寫程式／實作）進入另一個門檻的重要經驗與歷練。 這個階段花費的時間會較長一點，時間長短取決於個人歷練、經歷、學習的環境與工作內容。 5). 此階段含括上面所有技能，並能夠與〔團隊〕和〔客戶〕 溝通 與 協作 、並產生出〔產品〕。而所謂的協作代表，不只自身技術所長能應付本身開發工作工作所需，亦能帶領團隊解決軟體專案的大小事務、也能夠替...
閱讀完整內容

常見的程式碼壞味道（Code Smell or Bad Smell）

圖片
常見的程式碼壞味道（Code Smell or Bad Smell） 圖片取自：https://www.slideshare.net/ElMahdiBenzekri/art-of-refactoring-code-smells-and-microservices-antipatterns 前言 究竟重複的程式碼要不要共用它？傳統的軟體開發上，重複的程式碼幾乎被視為罪惡的來源，但是它真的有多可怕？ 常見的 Code Smells The Dispensable （一些可有可無的） Lazy Class (冗員類別） 如果一個類很少使用它會增加代碼庫的複雜性，從而阻礙開發。這樣的類可能是不必要的，它的功能可以成為另一個類的一部分。 Data Class (只有資料的類別） 一個類別只有包含『資料』未包含Methods，也就是說並未包含行為，不具行為模式的類別代表該『實例』容易被【其他類別所操控】。 Duplicate Code (重複的程式碼) 如描述，這也是上次有分享在我的 FB 社團 軟體開發之路［德國資深架構師給新手的建議］ 中有產生非常熱烈討論，這在社團朋友提醒下想起 Refactor 重構一書裡曾提過 rule of three 法則， 這個法則的定義是這樣的，有時部分程式碼重複其實是允許的（不是說重複一定是是被允許的）而是在某些 Context 情境下，該程式碼有一段時間不會衍伸別的功能 或 需求一段時間不會異動、且如要將它 DRY 會產生的『複雜度』或『花費時間』遠高於預估的時間 或 不值得在目前這個專案的節骨眼上花費這個時間來做這件事，加上它 DRY 產生的複雜度偶後產生的維護成本【遠高於】不 DRY 的情況下的維護本，那麼，在這個時候，這個異動頻率【極低】的程式碼就不需要花費這個時間來 DRY 了！！ 因為重點在於，重構是需要『成本』的。(迷之音：DRY 是種抽象化阿~😎) 這讓我想起之前，大約在 2016 年左右，在 101 的樓上某金融業客戶，曾經做過一個專案，這個專案就是因為客戶 DMZ 環境的因素，我讓內網的 Webside 與 DMZ 的網站保留了部分重複的程式碼，因為這段程式碼終年不需要異動，我也懶得花這個時間，而我居然也忘了這記件事情了.. 哈哈 Orz 不過原歸正傳，我個人還是認為，其實適當...
閱讀完整內容

什麼是 gRPC ？

圖片
圖片取自： https://grpc.io/docs/guides/ gRPC 是什麼？能吃嗎？ 在安裝了 .NET Core 3.0 之後，眼尖的朋友應該會發現，在新增 ASP.NET Core 網頁類型專案裡，會看見一個 gRPC Service 類型的專案，其實它也不是什麼很新的東西，早在十多年前 Google 就使用這樣的 RPC 協定進行一些大量的可靠性微服務的存取，聽到這，難道現有的 Web API 不可靠嗎？其實不是的，它主要用在移動設備等提供高效簡單且跨平台的通訊與熱插拔的驗證機制。 gRPC 的運作原理 gRPC 顧名思義，是種基於 RPC 的通訊協定，不同於 Web API 走的傳統 HTTP 基礎協定，它有點像是 Socket ，但應該說是基於 Socket， 或精確地來說它是基於 HTTP/2 的協定 ，gRPC 是種協議緩衝協定，它必須事先定義 IDL (Interface Definition Language) 描述檔，看到 IDL 對於一些熟悉 COM／DCOM 的朋友一定非常的熟悉，對！沒錯！就是類似的東西！但，這邊的 IDL 是用一種副檔名為 .proto 檔案來是先定義在分散式環境中，要傳輸的序列化結構資訊，當然它也可以跟 JSON 一起使用。 也就是說，要使用 gRPC 您必須先定義 .proto 協議，然後透過 Compile 的支援，編譯成特定語言框架。而很高興的是，C# 也支援了，然而其實根據官方的資料顯示，C# 應該在 .NET Core 2.1 開始就支援了，只是到了 .NET Core 3.0 才有樣版的支援。 而使用 gRPC 的協議緩衝區的服務可以做到 Stub 的機制，也就是說，它就像是許多 RPC 一樣，Client 在呼叫 Server 端時，其實是對 Stub 進行叫用，Stub 在這就像個緩衝區一般，但更細部的說，應該是一個遠程服務的替身，這應該又讓許多熟悉 COM／RPC 通訊的朋友覺得熟悉了起來，是的！沒有錯。 在 .NET Core 3.0 裡使用 gRPC 目前支援 .proto 擴展為 gRPC 協議緩衝區的編譯器只有 .NET Core 了 ， 根據 Github 上的說明 .NET Framework 4.5+ 以上或 Mono 4+ 以上也可支援，而 gRPC 也完全的跨平台。要在 ....
閱讀完整內容