那天在 DDD 實踐演講中 Clean Architecture 裡未講完的部分

房屋貸款線上申請的 Domain Model

圖、以線上房貸系統為例的 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 The C4 Model for Visualizing software architecture

前面提到 c4 Model，它其實提供了一個非常宏觀的角度來讓你的 System Context 包含你的上下文，並如何切割看入系統的實作，就算我們不一開始就撰寫程式，記得我先前的文章中提到，許多 DDD 的開發者若忽略實作的工程方法，還是會造成隱憂，即便 Domain Model 多完美，或者，再完美的 Domain Model 若無法串接到實作那又有什麼用呢？這是我這場演講中的另一個想要傳達的重點。

再來，這次演講中，我也提到我使用 Clean Architecture 的 Plug-In 架構來實踐高可用性，這後續的工程實踐是配合 C4 Model 來進行的，因為我沒有一開始就決定的外部系統，這個 Application 外部是要有明確的 Context Map 來表達相依，這我以後有機會再詳細介紹，本篇先說明此演講中傳達或未傳達的部分。

圖（二）、在一個 Use Case Boundary 內的 System Context

Bounded Context 內的 Clean Architecture

演講中使用的 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 產生的四個專案

透過我撰寫的套件產生的 4 個專案


當時 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 範本設計

留言

張貼留言

這個網誌中的熱門文章

什麼是 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 也完全的跨平台。要在 .
閱讀完整內容

什麼是 gRPC（二）- 來撰寫第一個 Hello World 吧！

圖片
前言 上一篇 什麼是 gRPC ，筆者大致介紹了 gRPC Service 的基本概念，這一次，我們就來小試一下身手，撰寫一個 Hello World （迷之音：嘗試新技術時，總是得先來一個 Hello World ～我不想違背這良好傳統阿阿阿阿） 使用環境 Visual Studio 2019 .NET Core 3.0.100-preview3-010431 開始進行 撰寫 gRPC 除了先準備好基礎環境、選定一種 作業系統／ 程式語言 Language 外、（Framework／SDK／Runtime）等環境備妥後，就可以開始撰寫， (1). 開始撰寫 gRPC 第一步就是先定義 .proto 協議了 上一篇筆者提到，gRPC 的 Server 與 Client 必須使用相同的協議才可進行溝通，一般來說，你應該使用 protoc.exe 編譯器先行編譯過 greet.proto 協議檔，並產出 C# 程式碼檔案後才可繼續，而在 Visual Studio 2019 裡，拜 MSBuild 之賜，已經有人預先寫好 .Target 檔案了 （什麼是 MSBuild ？什麼是附檔名 .Target 檔案可參考： MSBuild .targets 檔案 ） 筆者先撰寫一個 SayHelloWorld 方法如下： 在協議裡，除了在 service Class 撰寫要公開存取的方法外， 必須在提供『傳入訊息型態』、『回傳訊息型態』 ，這邊我先定義兩個 message，一個是『 HelloMyFirstgRPC 』、另一個是『 HelloMyReply 』 在撰寫 proto 協議檔時，建議先決定 message 回傳型態與傳入的型態，那麼 Visual Studio 2019 會有 InteillSense 的完整支援。不得不說 Visual Studio 2019 在 .proto 協議編輯上的支援已經算不錯了。 注意： 一般來說，Visual Studio 2019 會在背景裡自動編譯 .proto 協議檔案，但始有可能不會有任何提示，所以您也可以自行使用命令列工具進行手動編譯，如下圖，若編譯失敗會出現錯誤訊息，如下圖顯示 return 關鍵字錯誤： protoc.exe 編譯器 & 相關 MSBuild Tools 會隨著 NuGet 套件在 Vis
閱讀完整內容

常見的程式碼壞味道（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 不過原歸正傳，我個人還是認為，其實適當
閱讀完整內容