在領域驅動下使用 Clean Achitecture 實現高可用軟體架構

圖（一）、Bounded Context

前言

先前筆者撰寫許多關於軟體架構相關文章，有敏捷的軟體架構、也談過 Clean Architecture、包括我自行設計的跨平台的 Web API Framework 框架 Easy Architect Framework 等等，不管談論哪一種都圍繞在軟體本身的高可維護性、擴充性等議題，但常言道，能力（技術）要在更往上一步就得忘掉現在所有所學的東西，不要被現有學習的東西所牽絆才能更上一層樓，金庸裡的張無忌也是忘掉九陽神功與乾坤大挪移後也才瞬間學會的張三丰的太極拳法，因為長久以來你都使用瀑布開發方法，專案也都能成功結案，看似當然也無問題，因為剛好都在你熟悉的產業即便設計完才做開發也不致有你非預期情況會發生，因為你已經非常熟悉改產業、但當遇到其他產業時，專案實作過程中便會遇到需求認知錯誤、錯估範圍、部分打掉重練、時間浪費、人力不足、現有架構無法發揮功用、時間到最後便不足而最後導致專案失敗的窘境，這就是熟悉一種開發方法時，久了就會無視其他的開發方法，就像 OOAD 非常熟悉，解決各種軟體開發大小問題都會迎刃而解，系統開發 90% 都可以在經驗種解決，最後也會無視訪間流行的它種開發方法像是 DDD 等等，但是當你遇到 cloud 環境、Microservices、或者 Serverless 環境的時候，你不再是以單就以物件的角度來思考、在分散式環境裡，有些是違背物件導向思考方式的，你可能是使用流程角度來思考，領域驅動開發的概念也應蘊而生。

DDD, Domain Driven Devlopment 領域驅動開發

近幾年來、DDD 領域驅動概念不斷的蓬勃發展起來，這是因為 Cloud/Microservices 議題不斷的是重視，傳統的 SOA 已經慢慢不敷使用了，如果要應付更大量的服務需求吞吐量、不太可能像傳統架設單一伺服器來解決，在領域驅動裡使用 Bounded Context 的概念來分界模型 Domain Modeling 的應用範圍，讓團隊成員在進行合作時什麼該保持一致？Bounded Context 與其他的 Bounded Context 該如何構通？以及『上下文如何關聯』有一個明確且共通的術語 Ubiquitous Language，這共通的語言可以是某一段程式碼、或者是團隊的組織、軟體系統機的介接用法、或者是該 Context 的 Domain Modeling 都可以是 Ubiquitous Language。在每一個 Bounded Context 之間都要嚴格地保持模型的一致性，不要受到外界的問題的干擾與混淆。

使用領域驅動開發有幾個好處：

  • 使用通用語言讓領域專家與技術人員緊密連結在一起。
  • 減少溝通的障礙。
  • 幫助你在系統建置時以『領域』為主體的思考方式。
  • 它非常適合用在敏捷的環境下、迭代的環境下搭配 TDD／BDD 等開發方法。
  • 每一個 Bounded Context 都是一個鬆散的耦合關係的存在，每一個 Bounded Context 的上下文都明確定義其溝通的方式，所以彼此的技術也完全獨立。
  • 呈上、所以領域驅動開發非常適合用在 Microservices 環境中使用。

與傳統 OOAD 思維的異同

有人好奇、甚至並不清楚領域驅動與傳統 OOAD 開發到底有什麼顯著的差異？又或者使用領域驅動開發就不需要 OOAD 了嗎？但事實上領域驅動開發也是基於 OOAD 再做一個擴展，但是你不能完全用 OOAD 的角度來思考，因為領域驅動開發有一部分是違背 OO 的，舉個例子：傳統系統開發我們是系統分析完、接著進行系統設計，但我們會在系統分析階段定義好資料結構、可能是 ER-Model 或者是資料擺放的架構，直到系統設計、甚至系統運行時的功能都是以『資料』導向的在進行處裡，想的都是資料最後會存到哪裡去，但是領域驅動想的是物件流怎麼流？考量的是領域內的流程與事件如何處哩，並不考量資料存到哪裡去，而傳統系統設計的思維則是圍繞在如何處理資料、像是典型 CRUD 等操作都使用 Database/Table/column 結構的資料來識別處裡資料。

但是領域驅動則不然，因為它將軟體架構又拆解為下面幾種：

  • Bounded Context
  • Context Maps
  • Entities
  • Value Object
  • Aggregates
  • Services
  • Domain Events
  • Architecture

其中領域模型的精隨就是你的 Domain Modeling，一個 Bounded Context 也許會對應一到多個 Domain Modeling，在領域驅動裡面商業邏輯在建模 Entities 的時候產生，這裡的 Entities 可以是 Domain Modeling，您可以使用 UML 還繪製或其他工具皆可沒有限定，容易理解即可，重點是 Entites 與我們在 MVC 裡探討的 Model 是不太一樣的，這裡的 Entities 是有自己的生命週期，也就是狀態會隨的業務的進行、與其內部屬性變更而有所改變，而且必須在分散式環境中可以被識別 (Runtime) ，這也是領域的核心點，它關心的是整個『作業流程』，也就是整個 Process 怎麼跑，它是一個 Process Base Thinking 的思考模式，而不是去想說資料最終會被塞到哪一個 Database 裡，那不是它關心的重點。

簡單的說，其實在做物件導向的系統分析 Domain Modelgin Design 時，思維可能需要改變，你要改成從流程角度來看待系統的設計、不是像傳統物件導向是以資料流為 Base 的處裡，在領域驅動裡是以物件流 (Object Base) 的角度來看待系統，而且裡面的每一個物件我都要可以去 Identity 他，也就是識別唯一性。所以在領域驅動角度下的物件 Class 關注的是它的責任是什麼？也就是它要能夠提供外界什麼服務？而當然，它還是標準物件導向底下的一個類別，有許多屬性的集合。

有一個與傳統物件導向相違背的地方就是 Services 的部分，在領域驅動裡物件裡的 Method/Operation 是透過 Services 來提供對外界需要的操作，不是傳統物件導向你密不可分的，他因為責任而切割在不同的地方。

領域透過一個 Aggregate Root 封裝了業務邏輯與狀態，因此裡面包含所有與聚合相關的業務操作 (Bounded Contet)，並確保業務邏輯的一致性 (上下文)。

無處不在的通用語言 Ubiquitous Language

當我們進行專案開發，不管是不是敏捷的專案開發，最重要的就是『溝通』，在一般情況下，一個大專案就是數十個 Bounded Context 同時得再進行、不同的 Bounded Context 之間可能有（不同的領域專家／甚至不同的團隊）可能又涉及到專案經理、系統分析師、系統設計師、開發人員、QA人員 等等..在進行著，每個 Bounded Context 內也許又有一到多個 Domain Modeling 因此每一個領域專家要理解其他領域並相互溝通是一件相當困難的事情，更不用說不同角色又有自己的術語，也因此造成溝通式的困難。

在領域驅動裡面希望透過 Bounded Context 與其內部的 Domain Modeling 幫助團隊定義出一種可乎相交流的『模型』語言，這就是通用語言 Ubiquitous Language，另外一個重要的觀念是，通用語言並不局限於只能使用像是 UML 類型的模型來表示，您可使用各種圖形表示法 BPMN (Bbusiness Process)、DFD、Flow Cahrt、Others... 或者甚至是手繪，對你沒看錯，手繪的也可以、為什麼呢？因為重點在於『交流』、『溝通』，在每個 Bounded Context 下的團隊下與其他團隊 & 角色間溝通 + 認知沒有障礙、誤差越小越好，記得我在『決戰 OOAD 系列』課程裡也提到，不要為了畫製 UML 而繪製 UML，如果您有一些現有圖形在您現有團隊裡面溝通非常不錯用、非常容易溝通的，沒有障礙的，那你就繼續用，新的圖形不見得會增加團隊的共識，但是通用語言希望團隊理出一種可以互相交流理解的一種『模型語言』。

圖（二）、使用 BPMN 作為建模的依據

基於敏捷

領域驅動開發非常適合在敏捷的環境中進行，再迭代的環境中、在Sprint Planning Meeting 中釐清需求，討論 Domain Modeling 甚至是技術細節如何實作，也同時理出一個概括的通用語言，雖然在這個階段還不是那麼明確，因此專案進行中最重要的還是 Refinement Meeting，因為除了些修正方向外，也會同步修正通用語言。

近代的軟體專案開發敏捷幾乎是最佳解法了，在迭代的環境中 (短周期)、討論並正視目前遭遇到困難，並且需要開發人員與領域專家一起通力合作，利用協作的方式，先聚焦我們所要解決的問題，只要釐清了想要解決的問題後，再透過所有人腦力激盪的方式在會議中初步產生潛在可行的解決方案後，才被切分為 Tasks，並預估完成的時間。

高可用架構（插件式架構）Clean Architecture

Clean Architecture 是最適合在迭代環境中，以領域為核心、由外而內，透過聚合根（Aggregate Root）來封裝業務邏輯與狀態，確保業務邏輯一致性，這邊我們利用 .NET Core 內建的 DI 來做由外而內的相依與反轉。

這邊我實作了一個 Clean Architecture 的 C# Project Tempaltes 範本來幫助產生一個支援 CQRS 的 Application 層與 Domain 層。

圖（三）、使用自行開發的 Project Templates 範本建立 Clean Architecture (CQRS) 框架

待續...

下一篇、我們真的試著來實作一個高可用的軟體架構，也再來看看這個 ［Clean Architecture (CQRS)］ 的 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 也完全的跨平台。要在 ....
閱讀完整內容