ddd（domain-driven design 領域驅動設計）是由eric evans最先提出，目的是對軟體所涉及到的領域進行建模，以應對系統規模過大時引起的軟體複雜性的問題。整個過程大概是這樣的，開發團隊和領域專家一起通過通用語言(ubiquitous language)去理解和消化領域知識，從領域知識中提取和劃分為乙個乙個的子領域（核心子域，通用子域，支撐子域），並在子領域上建立模型，再重複以上步驟，這樣周而復始，構建出一套符合當前領域的模型。
ddd概述
這裡需要注意幾點：
ddd中將系統分為ui層，應用層，領域層以及基礎設施層。
分層架構
上圖中，應用層是很薄的一層，因為它只負責接收ui層傳來的引數和路由到對應的領域模型，它不負責處理具體的業務邏輯。系統的業務邏輯放在了領域層中，所以，領域層在系統架構中佔據了很大的面積。
在層級結構中，上層模組呼叫下層模組提供的服務，這裡就會存在一種依賴關係，rebort c. martin提出的依賴倒置原則大致是如下：
上層模組不應該依賴於下層模組，兩者都應該依賴於抽象；在使用ddd設計系統時，主要包括entity，value object，service,aggregate,repository,factory,domain event,moudle等元素。抽象不應該依賴於實現，實現應該依賴於抽象;
ddd元素
在建模時，entity可以用來代表乙個事物。既然entity是用來代表乙個事物的，那麼它就應該有乙個唯一值來標識這個事物，同時，他還能記錄這個事物狀態的變化。比如：id為5的person物件，它的名字是張三，過兩天，他將自己的名字改為李四。但是，這個人（id=5）還是這個人（id=5），只是他名字的狀態以及發生了變化，而這個變化後的狀態被person這個entity記錄了下來。
value object是用來描述事物的某一方面的特徵，所以它是乙個無狀態的，且是乙個沒有識別符號的物件，這是和entity的本質區別。拿訂單來說，一張訂單在系統中應該有乙個唯一的標識，且具有狀態，所以訂單是乙個entity物件，而這張訂單共￥100元，則是描述了這個訂單的總額特徵，￥100元可以用值物件表示為，及金額和幣種的組合。在任何限界上下文中都描述的是￥100元，是因為他們比較的是裡面的內容（金額和幣種），而上面的張三在修了名後，還是原來的那個人，是因為它比較的是唯一標示id的值。
aggregate是一組相關物件的集合，它作為資料修改的基本單元，為資料修改提供了乙個邊界。每個聚合都有乙個根和乙個邊界，根也是乙個實體，聚合邊界以外的物件只能通過根對聚合內部元素操作。聚合將一組相關的物件內聚到一起，從而將系統的複雜程度降低。
repository用來儲存聚合，相當於每乙個聚合都應該有乙個倉庫例項。entity和value object都應該具有行為，而有些行為從語義上講，不適合放到這兩個物件中，所以就單獨抽象了乙個service物件，用來存放這些行為。factory是用來生成聚合的，當生成乙個聚合的步驟過於複雜時，可以將其生成過程放在工廠中。
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 微服務拆分困境產生的根本原因就是不知道業務或者微服...