領域驅動設計的簡略設計步驟

2021-09-04 10:33:45 字數 1075 閱讀 6626

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

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

之後,是劃分聚合的邊界,找到聚合根。放在聚合中的實體物件通常存在兩個特點:1)不需要對它進行全域性訪問;2)它與聚合根有非常緊密的聯絡。如果無法確定聚合根,且又不是某個聚合範圍中的物件,可以暫時當作聚合根物件來處理。

需要考慮資源庫(repository)物件了。通常,我們只需要對聚合根考慮資源庫。主要是從查詢的角度來判斷資源庫(這裡存在查詢方法的定義,需要哪些查詢關鍵字,或者利用criteria)。接著考慮物件的建立。需要考慮幾個方面。乙個是物件的構造函式引數,尤其是聚合根物件,要考慮聚合中的物件保持不變數。同時,還需要考慮標識的問題。第二要考慮是否需要工廠來封裝物件的建立;第三需要考慮是否需要複製物件,即是否採用原型模式。如果需要複製,則要考慮聚合中的物件,哪些需要建立新的物件,哪些需要複製。

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

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

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

領域驅動設計的簡略設計步驟

首先,需要根據需求建立乙個初步的領域模型,至少要識別出領域物件和領域物件之間的關係 可以是沒有方向的關聯關係 這些領域物件只應該放在領域層中。如果存在應用職責,可以識別出應用類。它們用來協調領域物件,只負責提出問題,本身並不解決問題。解決問題是領域層的職責。這些應用類將被放在應用層中。接下來分析領域...

領域驅動設計的簡略設計步驟

首先,需要根據需求建立乙個初步的領域模型,至少要識別出領域物件和領域物件之間的關係 可以是沒有方向的關聯關係 這些領域物件只應該放在領域層中。如果存在應用職責,可以識別出應用類。它們用來協調領域物件,只負責提出問題,本身並不解決問題。解決問題是領域層的職責。這些應用類將被放在應用層中。接下來分析領域...

領域驅動設計系列(一) 為何要領域驅動設計?

領域驅動設計最近貌似開始火起來了,越來越多的人開始認識到領域設計的重要性,從我做過的專案來看,似乎歐洲已經有很多的公司開始實施領域驅動設計了,我看領域驅動設計也有些時間了,但是網上不管是文章還是 都顯得太過 高大上 一談領域驅動設計,一大堆的概念一股腦的給你上上來,搞的有點暈頭轉向,而我想在一些中小...