解構領域驅動設計（二）分層架構

反映業務規則的**是整個軟體的核心，但是它一般只佔很小的一部分，在傳統的基於貧血模型的分層軟體架構中，業務規則可能分散到各個層、各個**段，從而使得通過**來還原業務規則或者保證**與業務規則一致將變得非常困難。ddd分層架構的核心思想就是將所有業務規則的**抽取到領域層，保證領域層的編碼與領域模型是完全一致的。

下圖是ddd的分層架構。

接下來，我將通過**來演示這個新的分層架構。

1 應用層

應用層在這裡非常的簡單清晰，它僅僅是將基礎設施層、領域層提供的功能裝配起來完成任務，這一層的**邏輯非常簡單。

下面是建立設計師訂單的裝配任務。

1 @service
2 @transactional(rollbackfor = exception.class)
3 public class designerorderserviceimpl implements designerorderservice 
17 18     @override
19     public void pay(int orderid, float amount) 
24 25         order.pay(amount);
26         designerorderrepository.update(order);
27     }
28 29     @override
30     public refundorder refund(int orderid, string cause) 
35 36         refundorder refundorder = order.refund(cause);
37 38         designerorderrepository.update(order);
39 40         refundorderrepository.create(refundorder);
41 42         return refundorderrepository.selectbykey(refundorder.getid());
43     }
44 }

這裡例舉了建立訂單、付款、退款的應用層**。

這裡，訂單建立有2個步驟：

（1）使用factory建立新的業務物件；

（2）使用repository將業務物件持久化到資料庫。

付款3個步驟：

（1）使用repository載入訂單業務物件到記憶體；

（2）呼叫訂單業務物件的付款方法更改業務物件狀態；

（3）使用repository將業務物件持久化到資料庫。

退款有3個步驟：

（1）使用repository載入訂單業務物件到記憶體；

（2）呼叫設計師訂單業務物件的退款方法改變業務物件的狀態，然後生成乙個退款訂單業務物件；

（3）使用repository持久化設計師訂單和退款訂單業務物件。

此外，應用層還額外處理了資料持久化的事務。

2 領域層

領域層是實現所有業務規則的領域物件，它是整個軟體的核心，並且與領域模型保持一致。

1 @data
2 @equalsandhashcode(of = )
3 public class designerorder implements entity
30 31         if (math.abs(amount - this.expectedamount) > 0.01) 
34 35         this.state = designerorderworkflowservice.changestate(this.id, state, designerorderstate.paid);
36         this.actualpaidamount = amount;
37 38         // 付款完成後，自動啟動進度跟蹤
39         this.progressreport.startup();
40     }
41 42     public refundorder refund(string cause) 
49 50     private void assertcanrefund() 
56     }
57 58     @override
59     public boolean sameidentityas(designerorder other) 
62 }

你可以發現業務物件的**有：

關於領域層的編碼模式，在下文會詳細介紹。

3 基礎設施層

基礎設施層為上層提供通用的技術能力，包括訊息傳遞、快取、遠端呼叫、分布式事務、持久化、ui繪製等。以下是持久化實現的一段**。它以整個實體作為儲存單元（注意：準確的說，是以聚合根為儲存單元，後續詳細介紹）。

1 @repository
2 public class designerorderrepositoryimpl implements designerorderrepository 
13     }
14 15     @override
16     public designerorder selectbykey(int id) 
21 22     @override
23     public designerorder selectonebyspecification(designerorder example) 
28 29     @override
30     public listselectbyspecification(designerorder example) 
35 36     @override
37     public void update(designerorder order) 
41     }
42 }

4 結論

一定要牢記：ddd分層架構乙個核心任務，就是將軟體最重要的資產——業務規則分離出來，抽象在領域層，確保這些**是領域模型的正確實現。

通過以上的分層示例，我們可以總結出來領域驅動設計的**基本模式：

上層應用層通過factory、repository、領域物件協同來完成使用者任務。

通過factory、repository來處理領域物件生命週期管理，包括領域物件建立、載入、持久化。

領域物件由狀態和對狀態變更的操作組成，它是業務規則的實現。在這裡，字段代表狀態，方法代表狀態變更。領域物件狀態變更後，由repository進行持久化。如何涉及多個領域物件狀態變更的一致性，則這幾個領域物件的狀態變更將組合在一起，由repository進行一致性變更。

基本模式：新建——通過factory建立領域物件，呼叫領域物件方法更改狀態，使用repository將領域物件持久化；變更——通過repository載入領域物件，呼叫領域物件方法更改狀態，使用repository將領域物件持久化。

解構領域驅動設計（二）分層架構

解構領域驅動設計（二）分層架構

領域驅動設計學習筆記分層架構

領域驅動設計學習筆記分層架構

解構領域驅動設計（二） 分層架構

解構領域驅動設計（二） 分層架構

領域驅動設計 學習筆記 分層架構

領域驅動設計 學習筆記 分層架構

相關推薦

解構領域驅動設計（二）分層架構

解構領域驅動設計（二）分層架構

領域驅動設計學習筆記分層架構

領域驅動設計學習筆記分層架構