建站
咨詢
售后
建站咨詢
新聞中心
一、概述
這種設計一般是用在微服務的系統(tǒng)中，當我們聊微服務的時候，爭論最多的就是如何進行微服務的拆分，這也是最讓人產生爭議的地方。
創(chuàng)新互聯是專業(yè)的貴港網站建設公司，貴港接單;提供成都網站制作、成都網站建設、外貿營銷網站建設,網頁設計,網站設計,建網站,PHP網站建設等專業(yè)做網站服務;采用PHP框架,可快速的進行貴港網站開發(fā)網頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網站,專業(yè)的做網站團隊,希望更多企業(yè)前來合作!
當我們聊微服務也必然會會聊到中臺，中臺又是什么呢？
中臺
中臺從 2015 年提出，就已經被我們熟知，但是每個人對中臺的認識可能都千差萬別，有沒有一個大家都比較認可的定義呢？
將通用的可復用的業(yè)務能力沉淀到中臺業(yè)務模型，實現企業(yè)級能力復用。
因此中臺面臨的首要問題就是中臺領域模型的重構。
而中臺落地時，依然會面臨微服務設計和拆分的問題。
- 微服務：中臺落地時需要用微服務進行支撐。
- 中臺：復用業(yè)務，實現企業(yè)級能力復用。
- DDD：對中臺進行領域建模，實現適合企業(yè)發(fā)展的中臺。
DDD 可以說是微服務和中臺的產品經理。我們去寫業(yè)務功能時，是面向領域的，而不是面向數據庫表來實現代碼的。
二、DDD 是什么？
DDD 的核心思想：是通過領域驅動設計方法定義領域模型，從而確定業(yè)務和應用邊界，保證業(yè)務模型與代碼模型的一致性。
DDD 是一種處理高度復雜領域的設計思想，它試圖分離技術實現的復雜性，并圍繞業(yè)務概念構建領域模型來控制業(yè)務的復雜性，以解決軟件難以理解，難以演進的問題。
戰(zhàn)略設計：主要從業(yè)務視角出發(fā)，建立業(yè)務領域模型，劃分領域邊界，建立通用語言的限界上下文，限界上下文可以作為微服務設計的參考邊界。
戰(zhàn)術設計：則從技術視角出發(fā)，側重于領域模型的技術實現，完成軟件開發(fā)和落地，包括：聚合根、實體、值對象、領域服務、應用服務和資源庫等代碼邏輯的設計和實現。
三、DDD 架構分層
首先我們來看下架構分層的原理圖：
用戶接口層
用戶接口層主要包含用戶界面、Web 服務。
用戶接口層負責向用戶顯示信息和解釋用戶指令。這里的用戶可能是：用戶、程序、自動化測試和批處理腳本等等。
應用層
應用層不應該有業(yè)務邏輯。它是很薄的一層，理論上不應該有業(yè)務規(guī)則或邏輯，主要面向用例和流程相關的操作。
應用服務是在應用層的，它負責服務的組合、編排和轉發(fā)，負責處理業(yè)務用例的執(zhí)行順序以及結果的拼裝，以粗粒度的服務通過 API 網關向前端發(fā)布。還有，應用服務還可以進行安全認證、權限校驗、事務控制、發(fā)送或訂閱領域事件等。
領域層
領域層主要實現企業(yè)的核心業(yè)務邏輯，和之前的三層架構的 Service 層很像。
領域層當中又包含聚合，聚合里面就帶有聚合根、實體、值對象、領域服務等領域模型中的領域對象。
領域模型的業(yè)務邏輯主要通過實體和領域服務來實現，采用充血模型來時先所有與之相關的業(yè)務功能。充血模型后面會解釋。當單一實體(或值對象)不能實現時，領域服務就來進行聚合多個實體(或值對象)，來實現復雜的業(yè)務邏輯。
基礎層
基礎層為其他各層提供通用的技術和基礎服務，包括數據庫服務、消息中間件、對象存儲、緩存服務等。
它是封裝了所有的基礎服務，當切換基礎組件時，只用稍微修改下基礎服務就可以了。
比如之前用的對象文件存儲組件是阿里的，現在想換成騰訊的了，稍微改下基礎服務，切換成騰訊的就可以了，不用去改業(yè)務邏輯代碼。
這個就是采用了依賴倒置的原則，通過解耦來保持獨立的核心業(yè)務邏輯。
傳統(tǒng)三層架構轉 DDD 四層架構
傳統(tǒng)的三層架構就是 controller->service->model 這種模型，我們的思維習慣就是基于數據庫的表來開發(fā)業(yè)務功能。這種分層架構給開發(fā)人員帶來了便利，但是如果有其他人過來看你的代碼，他會很難從業(yè)務角度去理解，因為這些代碼都是為操作數據庫的表而寫。
有了 DDD 之后，代碼是面向業(yè)務功能的，而不是面向數據庫表的。
DDD 分層架構將業(yè)務邏輯層的服務拆分到了應用層和領域層。應用層快速響應前端的變化，領域層實現領域模型的能力。
三層架構數據訪問采用 DAO 方式、DDD 分層架構的數據庫等基礎資源訪問，采用了倉儲(Repository)設計模式，通過依賴倒置實現各層對基礎資源的解耦。
四、DDD 中各種 Object
- 數據持久化對象 (Persistent Object， PO)，與數據庫結構一一映射，它是數據持久化過程中的數據載體。
- 領域對象( Domain Object， DO)，微服務運行時核心業(yè)務對象的載體， DO 一般包括實體或值對象。
- 數據傳輸對象( Data Transfer Object， DTO)，用于前端應用與微服務應用層或者微服務之間的數據組裝和傳輸，是應用之間數據傳輸的載體。
- 視圖對象(View Object， VO)，用于封裝展示層指定頁面或組件的數據。
- 微服務基礎層的主要數據對象是PO。在設計時，我們需要先建立DO和PO的映射關系。大多數情況下DO和PO是一一對應的。但也有DO和PO多對多的情況。在DO和PO數據轉換時，需要進行數據重組。對于DO對象較多復雜的數據轉換操作，你可以在聚合用工廠模式來實現。當DO數據需要持久化時，先將DO轉換為PO對象，由倉儲實現服務完成數據庫持久化操作。當DO需要構建和數據初始化時，倉儲實現服務先從數據庫獲取PO對象，將PO轉換為DO后，完成DO數據構建和初始化。
- 領域層主要是DO對象。DO是實體和值對象的數據和業(yè)務行為載體，承載著基礎的核心業(yè)務邏輯，多個依賴緊密的DO對象構成聚合。領域層DO對象在持久化時需要轉換為PO對象。
- 應用層主要對象有DO對象，但也可能會有DTO對象。應用層在進行不同聚合的領域服務編排時，一般建議采用聚合根ID的引用方式，應盡量避免不同聚合之間的DO對象直接引用，避免聚合之間產生依賴。
- 在涉及跨微服務的應用服務調用時，在調用其他微服務的應用服務前，DO會被轉換為DTO，完成跨微服務的DTO數據組裝，因此會有DTO對象。在前端調用后端應用服務時，用戶接口層先完成DTO到DO的轉換，然后DO作為應用服務的參數，傳導到領域層完成業(yè)務邏輯處理。
- 用戶接口層主要完成DO和DTO的互轉，完成微服務與前端應用數據交互和轉換。facade接口服務在完成后端應用服務封裝后，會對多個DO對象進行組裝，轉換為DTO對象，向前端應用完成數據轉換和傳輸。facade接口服務在接收到前端應用傳入的DTO后，完成DTO向多個DO對象的轉換，調用后端應用服務完成業(yè)務邏輯處理。前端應用主要是VO對象。展現層使用VO進行界面展示，通過用戶接口層與應用層采用DTO對象進行數據交互。
五、領域分類
在研究和解決業(yè)務問題時，DDD 會按照一定的規(guī)則將業(yè)務領域進行細分，當領域細分到一定的程度后，DDD 會將問題范圍限定在特定的邊界內，在這個邊界內建立領域模型，進而用代碼實現該領域模型，解決相應的業(yè)務問題。簡言之，DDD 的領域就是這個邊界內要解決的業(yè)務問題域。
領域又可以分為多個子域，子域又包含核心域、通用域和支撐域。
- 核心域：核心業(yè)務，決定產品和公司核心競爭力的子域。
- 通用域：同時被多個子域使用的通用功能子域。
- 支撐域：支持其他子域，非核心域和通用域。
六、實現 DDD 流程
- 第一步：事件風暴，這里的風暴可以理解為頭腦風暴，領域專家會和設計、開發(fā)人員一起建立領域模型。
- 第二步：對領域中涉及到的場景(用戶故事)進行分析。
- 第三步：分析了場景之后，就要定義領域對象。設計實體、找出聚合根、設計值對象、設計領域事件、設計領域服務、設計倉儲。
- 第四步：領域對象需要包含業(yè)務邏輯，所以會形成一個代碼模型的映射。
- 第五步：根據代碼模型進行代碼落地。
六、限界上下文和通用語言
限界上下文
領域邊界就是通過限界上下文來定義的。
用來封裝通用語言和領域對象，提供上下文環(huán)境，保證在領域之內的一些術語、業(yè)務相關對象等(通用語言)有一個確切的含義，沒有二義性。
理論上限界上下文就是微服務的邊界。我們將限界上下文內的領域模型映射到微服務，就完成了從問題域到軟件的解決方案。
如果不考慮技術異構、團隊溝通等其它外部因素，一個限界上下文理論上就可以設計為一個微服務。
- 邏輯邊界：微服務內聚合之間的邊界是邏輯邊界。它是一個虛擬的邊界，強調業(yè)務的內聚，可根據需要變成物理邊界，也就是說聚合也可以獨立為微服務。
- 物理邊界：微服務之間的邊界是物理邊界。它強調微服務部署和運行的隔離，關注微服務的服務調用、容錯和運行等。
- 代碼邊界：不同層或者聚合之間代碼目錄的邊界是代碼邊界。它強調的是代碼之間的隔離，方便架構演進時代碼的重組。
通用語言
DDD 分析和設計過程中的每一個環(huán)節(jié)都需要保證限界上下文內術語的統(tǒng)一，在代碼模型設計的時侯就要建立領域對象和代碼對象的一一映射，從而保證業(yè)務模型和代碼模型的一致，實現業(yè)務語言與代碼語言的統(tǒng)一。
七、實體
實體概念
實體和值對象是組成領域模型的基礎單元。
類包含了實體的屬性和方法，通過這些方法實現實體自身的業(yè)務邏輯。
實體以 DO(領域對象)的形式存在，每個實體對象都有唯一的 ID。字段的值可以變。
實體是看得到、摸得著的實實在在的業(yè)務對象，實體具有業(yè)務屬性、業(yè)務行為和業(yè)務邏輯。
實體特點
有 ID 標識，通過 ID 判斷相等性，ID 在聚合內唯一。依附于聚合根，生命周期由聚合根管理。實體一般會持久化，但是與數據庫持久化對象不一定是一對一的關系。實體可以引用聚合內的聚合根、實體和值對象。
如下代碼所示，Product 屬于商品實體，有商品唯一 id。Location 屬于值對象，后面會講解值對象。
public class Product { // 商品實體
private long id; // 值對象，商品唯一 id
private String name; // 單一屬性值對象
private Location location; // 屬性值對象，被實體引用
}
public class Location { // 值對象，無主鍵 id
private String country; // 值對象
private String province; // 值對象
private String city; // 值對象
private String street; // 值對象
}
實體類通常采用充血模型。
充血模型和貧血模型的區(qū)別
貧血模型：數據和業(yè)務邏輯分開到不同的類中，比如 Model 類和 Service 類。
充血模型：數據和業(yè)務邏輯封裝在同一個實體類中。
八、值對象
值對象概念
值對象描述了領域中的一件東西，這個東西是不可變的，它將不同的相關屬性組合成了一個概念整體。
值對象是 DDD 領域模型中的一個基礎對象，它跟實體一樣都來源于事件風暴所構建的領域模型，都包含了若干個屬性，它與實體一起構成聚合。
值對象只是若干個屬性的集合，只有數據初始化操作和有限的不涉及修改數據的行為，基本不包含業(yè)務邏輯。值對象的屬性集雖然在物理上獨立出來了，但在邏輯上它仍然是實體屬性的一部分，用于描述實體的特征。
值對象的特點
無 ID，不可變，無生命周期，用完就不需要了。值對象之間通過屬性值判斷相等性。核心本質是值，是一組概念完整的屬性組成的集合，用于描述實體的狀態(tài)和特征，值對象盡量只引用值對象。
九、聚合和聚合根
聚合
聚合就是由業(yè)務和邏輯緊密關聯的實體和值對象組合而成。
聚合是數據修改和持久化的基本單元，每一個聚合對應一個倉儲，實現數據的持久化。
聚合有一個聚合根和上下文便捷，根據業(yè)務單一職責和高內聚原則，定義了聚合內部應該包含哪些實體和值對象，而聚合之間的邊界是松耦合的。
聚合屬于 DDD 領域層，領域層包含多個聚合，共同實現核心業(yè)務邏輯。
聚合內的實體以充血模型實現個體業(yè)務能力，以及業(yè)務邏輯的高內聚。
跨多個實體的業(yè)務邏輯通過領域服務來實現，跨多個聚合的業(yè)務邏輯通過應用服務來實現。
特點：高內聚、低耦合，它是領域模型中最底層的邊界，可以作為拆分微服務的最小單位，但是不建議對微服務過度拆分。一個聚合可以作為一個微服務，以滿足版本的高頻發(fā)布和極致的彈性伸縮能力。一個微服務也可以包含多個聚合，可以進行拆分和組合。
聚合根
聚合根是為了避免由于復雜數據模型缺少統(tǒng)一的業(yè)務規(guī)則控制，從而導致聚合、實體之間數據不一致性的問題。
聚合可以比作組織，聚合根就是這個組織的負責人。
外部對象不能直接訪問聚合內實體，需要先訪問聚合根，再導航到聚合內部實體。
特點：聚合根是實體，有實體的特點，具有全局唯一標識，有獨立的生命周期。一個聚合只有一個聚合根，聚合根在聚合內對實體和值對象采用直接對象引用的方式進行組織和協(xié)調，聚合根和聚合根之間通過 ID 關聯的方式實現聚合之間的協(xié)同。
十、領域事件
領域事件用來表示領域中發(fā)生的事件。一個領域事件將導致進一步的業(yè)務操作，在實現業(yè)務解耦的同時，有助于形成完成的業(yè)務閉環(huán)。
領域事件驅動設計可以切斷領域模型之間的強依賴關系，事件發(fā)布完成后，發(fā)布方不必關心后續(xù)訂閱方事件處理是否成功，可以實現領域模型的解耦，維護領域模型的獨立性和數據的一致性。微服務之間的數據不必要求強一致性，而是基于事件的最終一致性。
領域事件的執(zhí)行需要一系列的組件和技術來支撐：事件的構建和發(fā)布、事件數據持久化、事件總線、消息中間件、事件接收和處理。
網站題目：「查缺補漏」，DDD核心概念梳理
當前路徑：http://m.5511xx.com/article/ccisesc.html
