領域驅動設計
領域驅動設計是關于軟體開發時架構設計與建模的方法論，隨著微服務架構的普及，領域驅動設計也隨之被廣泛使用，在本文中，將對領域驅動設計中的重要概念進行介紹，
界限背景關系
在領域驅動設計中，首先需要根據客觀物件的實際內容以及對業務的理解，劃分出不同的領域，因此，引出了一個重要的概念：界限背景關系，界限背景關系（bounded context）指的是根據業務知識自然劃分出的業務邊界，比如，以書店為例，書店有兩種基礎的業務背景關系，分別是倉儲與銷售，在不同的背景關系中，書店這一客觀物體將被以不同方式理解，所有與特定背景關系相關的行為與邏輯都應該在這個背景關系中被解決，當涉及到多個背景關系互動的時候，通常會使用各個背景關系中的門戶物件進行交流（這一點有點類似于聚合中使用聚合根進行統一的管理與訪問）
[Tips]：界限背景關系實際上是一個解決方案側的概念，其本質上是問題域到解決方案域的一種映射與抽象，領域是業務場景中對應的業務域，領域與子域可以劃分為問題空間與解決方案空間，但一般主要指問題域，因此，界限背景關系可能會穿插在幾個子領域中，（參見《實作領域驅動設計》）
物體、值物件與聚合
界限背景關系中最主要的元素就是領域模型，領域模型又由聚合、模塊等基本元素組成，做一個淺顯的類比，界限背景關系好比一個城市的邊界，劃分完邊界后，可能還會根據業務的具體需要劃分出更細粒度的組織————聚合，聚合就好比在城市之中的各個街道與社區，當然，城市系統可以正常運作實際上離不開其中的人與物，類似于這一層級的概念，在領域驅動設計中我們將之稱作物體、值物件，
物體
- 物體，擁有唯一識別符號，經歷狀態變更后仍保持一致性，其重要特征是延續性和可標識性，比如在學生管理系統中，學生可以被設計為一個物體，每一個學生物體擁有唯一識別符號，在不同的界限背景關系中，名字相同的物體將會有不同的含義與側重點, 比如在倉儲的背景關系中，我們關心書的尺寸、重量與型別，而在銷售的背景關系中，我們關心書的內容、外觀、價格與評價，
- 相比于貧血模型的優勢，所謂貧血模型指的是，模型僅對資料庫中的表結構進行了簡單映射，其余的邏輯大量充斥在其他的類中，需要依賴大量的Utils類去計算與之相關的業務邏輯，
貧血模型的缺點[1]
- 無法保護模型物件的完整性和一致性：物件的所有屬性都是公開的，只能由呼叫方來維護模型的一致性，缺乏保障，
- 物件操作的可發現性極差：從物件的屬性上難以直觀的看出業務邏輯，什么時候可以被呼叫？賦值的邊界是什么？舉個例子，Long型別的值是否可以是0或者負數？
- 代碼邏輯重復：如校驗邏輯、計算邏輯等，很容易出現在多個服務的代碼塊里，這會提升后期維護的成本和bug出現的概率，
- 代碼的健壯性差：比如一個資料模型的變化可能導致從上到下的所有代碼的變更，
- 物體的合法性驗證最好具有自封裝性，即在setter或構造器中就進行自驗證，對復雜物體進行驗證時，可以采用延遲驗證，即使用專門的驗證類及其validate方法進行驗證，
值物件
- 值物件，擁有一系列屬性，沒有唯一識別符號，比如在學生管理系統中，家庭住址這一概念，可以由省、市、街道唯一編碼，是一組靜態的屬性值，通常是不可變的，值物件具有相等性，即其所有的部分若相等，則整體是相等可替換的，值物件的所有方法都是無副作用的，不會破壞其不變性，
聚合與聚合根
- 聚合，可以認為聚合是擁有一系列相關的，在特定界限背景關系中的物體與值物件的集合，在聚合中，我們通常使用聚合根來管理和訪問聚合以及其中的其他成員，聚合根本質上也是一種物體，一般被稱作為根物體，對于一個特定的界限背景關系，可以由單個或多個聚合構成，
背景關系映射圖
背景關系映射圖討論的是不同背景關系之間的映射、協作關系，在Evans的書中，總結了如下幾種基本的模式：
- 合作關系
- 共享關系
- 客戶與供應關系
- 防腐層（是一種較為常見的方式）
- 發布語言
等等
Domain Primitive
Domain Primitive 是一個在特定領域里，擁有精準定義的、可自我驗證的、擁有行為的 Value Object，（注：Domain Primitive的概念和命名來自于Dan Bergh Johnsson & Daniel Deogun的書 Secure by Design）
通常使用DP時，會遇到以下幾種需求：
- 讓隱性的概念顯性化
- 讓隱性的背景關系顯性化
- 封裝多物件行為
常見的需要用到DP的場景：
- 有格式限制的String或Integer欄位，如電話號碼、地址、姓名、成績等，因為一般含有校驗邏輯，此時可以在DP中封裝校驗邏輯
- 復雜的資料結構的操作，如
Map<String, List<Integer>>，可以使用DP來隱藏具體的細節，
具體細節可以參考這一篇博文
領域之間的互動
不同領域之間通過相互互動，完成特定的系統功能，一個上游領域在一個特定業務流程中，可能會與多個下游領域互動，比如購物車服務在后續需要與訂單服務、倉儲服務、郵件服務進行互動，但由于各個服務是以微服務形式存在的，如果使用上游服務去宣告式（同步）地與下游服務進行互動，那么一旦當中某一個下游服務因故障無法正確執行，則會造成整個系統狀態的不一致性，因此，使用異步的互動方式（發布-訂閱）能避免這一問題，上游服務可以在訊息中間件中下發特定的訊息，讓下游的服務異步進行消費，同時，這種異步的方式使上下游的服務相互解耦，當我們添加新的服務時，不需要改動無關的代碼，
事件風暴
開發人員與業務人員一起分析領域，并提出相關的建模，在每次討論中，只需要對特定的一個部分進行建模，而無需考慮全域的詳盡細節，可以以類似于敏捷開發的形式，迭代回圈，通常需要確定的是業務相關的事件，以及事件相關的活動，通常來說，我們可以先定義完整個事件流，然后每個事件流后補充對應的活動與規則，
參考
[1]Repository模式
[2]DDD領域驅動設計-概述
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/498995.html
標籤：其他
上一篇：嵌入式軟體架構設計-函式呼叫
下一篇：嵌入式軟體架構設計-訊息互動