首先，需要根據需求建立一個初步的領域模型，至少要識別出領域對象和領域對象之間的關系（可以是沒有方向的關聯關系）。這些領域對象只應該放在領域層中。如果存在應用職責，可以識別出應用類。它們用來協調領域對象，只負責提出問題，本身并不解決問題。解決問題是領域層的職責。這些應用類將被放在應用層中。

接下來分析領域模型，識別出實體對象和值對象。如果是實體對象，最好判斷其標識的組成與生成方式。然后，再細致地分析關聯關系，確定關聯關系的游歷方向。要注意幾種特殊的關聯關系。如果是多對多，則要看是否可以轉換為有限定的一對多。對于循環引用關系，則需要特別注意。可以考慮利用查詢（利用資源庫）來解除其中一方的引用關系。如果要繼續維護這種循環引用，需要考慮參與循環引用的多個對象之間的不變量。如果是雙向關聯，很可能是組成聚合的兩個對象，但要判斷哪個是聚合根。此時，彼此的構造函數是雙重委派的，但其中非根對象的創建應該封裝在根對象的構造函數（或者工廠）中。

之后，是劃分聚合的邊界，找到聚合根。放在聚合中的實體對象通常存在兩個特點：1)不需要對它進行全局訪問；2)它與聚合根有非常緊密的聯系。如果無法確定聚合根，且又不是某個聚合范圍中的對象，可以暫時當作聚合根對象來處理。

需要考慮資源庫（Repository）對象了。通常，我們只需要對聚合根考慮資源庫。主要是從查詢的角度來判斷資源庫（這里存在查詢方法的定義，需要哪些查詢關鍵字，或者利用Criteria）。接著考慮對象的創建。需要考慮幾個方面。一個是對象的構造函數參數，尤其是聚合根對象，要考慮聚合中的對象保持不變量。同時，還需要考慮標識的問題。第二要考慮是否需要工廠來封裝對象的創建；第三需要考慮是否需要復制對象，即是否采用原型模式。如果需要復制，則要考慮聚合中的對象，哪些需要創建新的對象，哪些需要復制。

接下來，需要對模型進行進一步的細化。例如重點考慮循環引用。同時，還要分析是否需要對象的抽象和多態，以及是否需要考慮服務對象。

最后，是對模塊的劃分。最好不要根據模式來分類，將實體對象、值對象、資源庫等對象分別放在一起，而應該按照業務邏輯的內聚性對對象進行模塊劃分。

注意，在識別領域模型時，對于業務規則和約束來說，需要利用規格（Specification）模式對這些進行封裝。另外，切忌將與業務和業務規則相關的職責放到應用層中。應用層應該是薄薄的一層。當然，在整個DDD設計過程中，還需要不斷迭代、精化和重構。

轉載于:https://blog.51cto.com/wayfarer/290790

總結

以上是生活随笔為你收集整理的领域驱动设计的简略设计步骤的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。