DDD領域模型閱讀思考

ddd領域模型閱讀思考

常見軟體設計模式注重資料庫和資料表模型，把錶捋出來來以後，彷彿**流程就出來了，但這個只是多個儲存模型，儲存資料的流程，這樣是能完成儲存資料的功能，但是是很底層的設計思路，思路固化以後，會容易寫出麵條串似的業務流程**， 沒有確定 領域邊界，不是至頂向下，而是從底向上的思考，這樣的**容易無組織，只有一串串堆疊的業務**配合。復用也不容易。

技術人員不要陷入專案剛開始，就糾結於技術細節實現的泥潭（只是從資料儲存，資料表方面等談），一些顯而易見的矛盾處還是應該指出，但一般業務從業人員也不會那麼業餘，先從戰略上面確定整體領域邊界和主要的領域模型，大白話就是系統組成模組邊界。

確立領域邊界後，每個領域邊界業務，利用包名的隔離性來單獨隔離業務**。對外提供的特定介面api 也需要起特定api包。利用介面進行互動。然後需要配合多個領域業務邊界的地方需要繼承

領域物件對外呼叫主要提供者是 所謂的 聚合根（就是利用聚合的方式，聚合了 領域物件，entity物件， 領域值物件是為了方便傳輸值存在的，要簡潔）,然後領域物件 entity 不止是資料庫表物件，可能是把幾個表 orm物件聚合在一起的東西，擁有自己的邊界,有自己的職責和方法。聚合根把各個 entity物件，值物件 聚合起來，介面邏輯聚攏起來，**邏輯內聚。強調的是對方呼叫方能呼叫的應該只有聚合根物件。 這個領域根物件還得理解其與持久化資料互動邏輯.

隔離真正service 和 普通呼叫者直接 可以加一層， acl(所謂的 anti-currupt-layer，防腐層), 防腐層意義是在 隔離真正提供service，做了一層**模式，用來溝通外部 業務，或者說外部領域 和 內部領域的資訊交換，防止交纏過多，產生含糊不清。

單體應用分拆module的話需要結合各個領域邊界業務，組合起來對外提供 service 的包， 利用proxy api層，然後需要module proxy 進行api bean注入,這個是單體應用的比較麻煩的地方。如果是微服務 邊界業務進行溝通，那直接就是走網路，或http 或rpc 框架來走通訊了，也就是 上下文整合手段。

領域服務的邊界，以電商為例， 商品邊界， 訂單邊界， **邊界， 這些邊界對外提供出口的服務層，不提api介面層的東西了，就說真正領域邊界對外提供出口，外部呼叫只能通過這些對外提供的服務來用，這些服務層，一般是通過 內部組合 儲存層服務來進行？

少了聚合根做邏輯的聚集，但是這樣是最顯而易見最好實施的一種方式，僅僅通過這種方式能很快地進行開發。 因為聚合根的聚合需要一定的狀態維護，會顯得比較難以編寫和意識邊界，可能不利於前期開發的速度。 但是為了後期做模組內部的功能**復用，建議還是要把 單純的每個

表的 dao 層，做 概念上的組合，就是乙個大塊概念的方式組合 這些dao 層, 這樣這個中間層，可能會顯得略龐大，需要相關別的方式來分割內部**。中間層要合理放置介面邊界，中間層概念理解為聚合根，聚合根要各司其職，足夠合理的劃分尺度

子話題 - 分布式環境下， 領域模型實踐，以及通過命令模式進行訊息傳遞

分布式環境，事務一致性問題，改為 最終一致性，而不是強一致性，在 ap和 cp 中 選了 ap, 通過冪等傳送，臨時訊息表， 事務方式插入訊息， 訊息佇列， 冪等處理訊息方式，保證了最終一致性， 但是 定時掃臨時訊息表，可能會導致高水位的表記錄，和表壓力，可以通過監聽資料庫變化的方式做更好地處理，例如 利用 canal 特性

微服務的冪等和事務更多依賴於事件驅動，也就是設計一套 傳送冪等， 依靠訊息佇列， 消費冪等的一套消費事務體系。

q&a 環節

– 提出問題:

實體物件是什麼？就是資料庫表嗎？

我目前理解是，實體物件是對業務來說，整體劃分出來乙個實體，它應該具有的特性是

實體

當乙個物件由其標識（而不是屬性）區分時，這種物件稱為實體（entity）。

例：最簡單的，公安系統的身份資訊錄入，對於人的模擬，即認為是實體，因為每個人是獨一無的，且其具有唯一標識（如公安系統分發的身份證號碼）。

DDD中的「領域模型」

在網上搜尋領域模型，有大量的文章。一種是 於最初的傳統軟體開發過程，一種 於領域驅動設計 ddd 在傳統軟體開發中，軟體設計師通常使用uml語言進行系統建模，裡面也在強調領域模型的重要性，這兩者很容易混淆。我給大家找到了一些資料，先來看看傳統軟體開發中，領域模型是什麼。領域模型是什麼？理論派觀點 實...

DDD領域驅動設計 充血模型 貧血領域模型

最早廣泛應用源於ejb2，最強盛時期則是由spring創造，把 分離到不同的物件中 貧血領域模型是乙個存在已久的反模式，它不是個好東西。它完全和物件導向設計背道而馳。物件導向設計主張將資料和行為繫結在一起，而貧血領域模型則更像是一種面向過程設計。貧血領域模型的根本問題在於，它引入了領域模型設計的所有...

DDD領域模型AutoMapper實現DTO（七）

dto的應用場景 定義產品類 public class product public decimal productunitprice 定義productdto物件 public class productdto public decimal productunitprice 定義兩個類 publi...