實踐領域驅動設計-讀書筆記

如何用好這本書

 

DDD 總覽

 

早些時候，我講到了 DD 的通用語言（Ubiquitous Language,1)。通用語言

 

作用於某個限界上下文（Bounded Context,2），它對於領域建模是非常重要的，你應該好好地熟悉一下。請記住，不管你是在戰術上還是戰略上設計軟件模型，你都應該保證：在一個特定的限界上下文中只使用一套通用語言，並且保證它的清晰性和簡潔性。

戰略建模

限界上下文是一種概念上的邊界，領域模型便工作於其中。同時，限界上下文爲通用語言提供了一套環境，項目成員便通過通用語言來表達軟件模型，如圖 G.1

 

 

 

 

總覽：

 

領域和界定上下文

 

什麼是領域：

從廣義上講，領域（Domain）即是一個組織所做的事情以及其中所包含的切。商業機構通常會確定一個市場，然後在這個市場中銷售產品和服務。每個組織都有它自己的業務範圍和做事方式。這個業務範圍以及在其中所進行的活動便是領域。當你爲某個組織開發軟件時，你面對的便是這個組織的領域。這個領域對於你來說應該是明晰的，因爲你在這個領域中工作。

 

領域  1對多個 子域

子域 1對多個界定上下文

 

 

界定上下文=模型名+上下文

和你的業務領域模型相關，應該足夠大到可以很準確的表達其所對應的整套通用語言！

所以，通用語言是限界上下文的重要輸入和邊界限定的主要依據。

具體落地，體現在頂層模塊的名字。

com.xx.data.app.np.domain.*;

其中np就可以對應到一個限界上下文上。

 

 

上下文映射圖續

系統間的集成常常依賴於RPC，網絡和遠程系統的加載過程都是RPC產生延遲的原因。當RPC的目標系統不可用時，系統也就不可能用了。一種方式是選擇異步請求或者事件處理的方式。DDD主張在本地緩存由外部模型翻譯而來的領域對象，這些對象保留這本地模型所需的最小狀態集；然而，要與遠程模型保持同步，最好的方式是在遠程系統中採用面向消息的通知機制。

 

 

 

 

 

 

架構

 

 

 

六邊形架構：端口與適配器，

是一種依賴倒置的場景實現，服務提供方爲依賴它的consumer提供對應的實現（適配器）

 

面向服務架構

 

REST架構風格

資源是關鍵的概念

 

事件驅動架構

EDA：是一種處理事件生成、發現和處理等任務的軟件架構。

類似於管道和過濾器：

cat phone_number.txt | grep 130 | wc -l

 

長時處理過程Saga

事件驅動的、分佈式的並行處理模式—長時處理過程（long Running proces）

 

CQRS

CQRS（Command & Query Responsibility Segregation）命令查詢職責分離，和 REST 同屬於架構風格，如果單純理解

實現領域驅動設計CQRS，是比較容易的，另一種方式解釋就是，一個方法要麼是執行某種動作的命令，要麼是返回數據的查詢，命令的體現是對系統狀態的修改，而查詢則不會，職責的分離更加有利於領域模型的提煉，系統的靈活性和可擴展性也得到進一步加強。

 

總結：六邊形架構是DDD的首選架構方式，因爲領域內聚，不需要關心外部的依賴。通過適配器去解決外部依賴。

 

 

 

 

值對象

 

當你決定一個領域概念是否是一個值對象時，你需要考慮它是否擁有以下特徵

 

它度量或者描述了領域中的一件東西。

 

它可以作爲不變量

 

它將不同的相關的屬性組合成一個概念整體（Conceptual Whole）。

 

當度量和描述改變時，可以用另一個值對象予以替換。

 

它可以和其他值對象進行相等性比較。

 

它不會對協作對象造成副作用【Evans】。

 

java值對象：https://www.jdon.com/53373

一個實際case: 員工與地址，地址及可被設計成值對象，https://www.cnblogs.com/leo_wl/p/4122147.html

 

 

聚合