說道ddd不得不說傳統的架構與ddd的架構區別。
傳統的架構不外乎就是三層，而在這三層裡面又不斷的細分，始終沒有達到想要的效果，那麼為什麼當時還是採用三層。
當然在ddd沒有提出的時候三層是大多數人的選擇。
那麼當領域驅動被提出來的時候它又能帶給我們什麼樣的好處？？
近期博主看了一下dax.net大佬有關ddd的文章，這裡提出自己的一些心得，本著共同學習的精神一起進步。
我也來說說領域模型
1.為什麼叫領域模型？
首先傳統的模型（這裡指的只具備getter 和 setter）不包含其他業務邏輯泛指沒有具體的功能這種模型我們稱為失血（貧血）模式。
然後才是具備有業務的模型除了getter 和setter 外還有其他的業務邏輯包含在裡面，比如說我有乙個購物車，購物車內有5件商品，每件商品價值20元，那麼在銷售訂單的時候可以這樣寫總價=5*20。當然這個例子有點牽強，意會意會就行了。
2.下面我們看看**是如何設計。
首先我們有個user、address、saleorder、salelines、categorization、category、product、userrole、shoppingcart、shoppingcartitem幾個類
如下圖。
其中宣告ientity領域實體介面、iaggregateroot聚合根集合、aggregateroot聚合根介面的抽象類。
這裡不得不提到聚合個概覽。
引用一下：
生成的資料庫模型如下圖：
DDD領域驅動設計
公司裡面敏捷專案要講ddd領域驅動設計，加緊學習了一下，找了一些資料研究。eric evans的 domain driven design領域驅動設計 簡稱ddd，evans ddd是一套綜合軟體系統分析和設計的物件導向建模方法，本站jdon.com是國內公開最早討論ddd 之一，可訂閱 ddd專題...
DDD（領域驅動設計）
domain 領域 driven 驅動 design 設計 由eric evans最先提出，目的是對軟體所涉及到的領域進行建模，以應對系統規模過大時引起的軟體複雜性的問題。整個過程大概是這樣 開發團隊和領域專家一起通過 通用語言 ubiquitous language 去理解和消化領域知識，從領域知...
DDD領域驅動設計
極客時間學習筆記 為什麼微服務設計的時候需要ddd？1 軟體架構模式演進的三個階段 第一階段是單機架構 第二階段是集中式架構 第三階段是分布式微服務架構 2 在單機和集中式架構這兩種模式下，軟體無法快速響應需求和業務的迅速變化，最終錯失發展良機。3 微服務拆分困境產生的根本原因就是不知道業務或者微服...