首先，需要根據需求建立乙個初步的領域模型，至少要識別出領域物件和領域物件之間的關係（可以是沒有方向的關聯關係）。這些領域物件只應該放在領域層中。如果存在應用職責，可以識別出應用類。它們用來協調領域物件，只負責提出問題，本身並不解決問題。解決問題是領域層的職責。這些應用類將被放在應用層中。
接下來分析領域模型，識別出實體物件和值物件。如果是實體物件，最好判斷其標識的組成與生成方式。然後，再細緻地分析關聯關係，確定關聯關係的遊歷方向。要注意幾種特殊的關聯關係。如果是多對多，則要看是否可以轉換為有限定的一對多。對於迴圈引用關係，則需要特別注意。可以考慮利用查詢（利用資源庫）來解除其中一方的引用關係。如果要繼續維護這種迴圈引用，需要考慮參與迴圈引用的多個物件之間的不變數。如果是雙向關聯，很可能是組成聚合的兩個物件，但要判斷哪個是聚合根。此時，彼此的建構函式是雙重委派的，但其中非根物件的建立應該封裝在根物件的建構函式（或者工廠）中。
之後，是劃分聚合的邊界，找到聚合根。放在聚合中的實體物件通常存在兩個特點：1)不需要對它進行全域性訪問；2)它與聚合根有非常緊密的聯絡。如果無法確定聚合根，且又不是某個聚合範圍中的物件，可以暫時當作聚合根物件來處理。
需要考慮資源庫（repository）物件了。通常，我們只需要對聚合根考慮資源庫。主要是從查詢的角度來判斷資源庫（這裡存在查詢方法的定義，需要哪些查詢關鍵字，或者利用criteria）。接著考慮物件的建立。需要考慮幾個方面。乙個是物件的構造函式引數，尤其是聚合根物件，要考慮聚合中的物件保持不變數。同時，還需要考慮標識的問題。第二要考慮是否需要工廠來封裝物件的建立；第三需要考慮是否需要複製物件，即是否採用原型模式。如果需要複製，則要考慮聚合中的物件，哪些需要建立新的物件，哪些需要複製。
接下來，需要對模型進行進一步的細化。例如重點考慮迴圈引用。同時，還要分析是否需要物件的抽象和多型，以及是否需要考慮服務物件。
最後，是對模組的劃分。最好不要根據模式來分類，將實體物件、值物件、資源庫等物件分別放在一起，而應該按照業務邏輯的內聚性對物件進行模組劃分。
注意，在識別領域模型時，對於業務規則和約束來說，需要利用規格（specification）模式對這些進行封裝。另外，切忌將與業務和業務規則相關的職責放到應用層中。應用層應該是薄薄的一層。當然，在整個ddd設計過程中，還需要不斷迭代、精化和重構。
領域驅動設計的簡略設計步驟
首先，需要根據需求建立乙個初步的領域模型，至少要識別出領域物件和領域物件之間的關係 可以是沒有方向的關聯關係 這些領域物件只應該放在領域層中。如果存在應用職責，可以識別出應用類。它們用來協調領域物件，只負責提出問題，本身並不解決問題。解決問題是領域層的職責。這些應用類將被放在應用層中。接下來分析領域...
領域驅動設計的簡略設計步驟
首先，需要根據需求建立乙個初步的領域模型，至少要識別出領域物件和領域物件之間的關係 可以是沒有方向的關聯關係 這些領域物件只應該放在領域層中。如果存在應用職責，可以識別出應用類。它們用來協調領域物件，只負責提出問題，本身並不解決問題。解決問題是領域層的職責。這些應用類將被放在應用層中。接下來分析領域...
領域驅動設計系列（一） 為何要領域驅動設計？
領域驅動設計最近貌似開始火起來了，越來越多的人開始認識到領域設計的重要性，從我做過的專案來看，似乎歐洲已經有很多的公司開始實施領域驅動設計了，我看領域驅動設計也有些時間了，但是網上不管是文章還是 都顯得太過 高大上 一談領域驅動設計，一大堆的概念一股腦的給你上上來，搞的有點暈頭轉向，而我想在一些中小...