反映業務規則的**是整個軟體的核心，但是它一般只佔很小的一部分，在傳統的基於貧血模型的分層軟體架構中，業務規則可能分散到各個層、各個**段，從而使得通過**來還原業務規則或者保證**與業務規則一致將變得非常困難。ddd分層架構的核心思想就是將所有業務規則的**抽取到領域層，保證領域層的編碼與領域模型是完全一致的。
接下來，我將通過**來演示這個新的分層架構。
1 應用層
應用層在這裡非常的簡單清晰，它僅僅是將基礎設施層、領域層提供的功能裝配起來完成任務，這一層的**邏輯非常簡單。
下面是建立設計師訂單的裝配任務。
@service
@transactional(rollbackfor = exception.class)
public class designerorderserviceimpl implements designerorderservice
@override
public void pay(int orderid, float amount)
order.pay(amount);
designerorderrepository.update(order);
}@override
public refundorder refund(int orderid, string cause)
refundorder refundorder = order.refund(cause);
designerorderrepository.update(order);
refundorderrepository.create(refundorder);
return refundorderrepository.selectbykey(refundorder.getid());
}}
這裡，訂單建立有2個步驟：
（1）使用factory建立新的業務物件；
（2）使用repository將業務物件持久化到資料庫。
付款3個步驟：
（1）使用repository載入訂單業務物件到記憶體；
（2）呼叫訂單業務物件的付款方法更改業務物件狀態；
（3）使用repository將業務物件持久化到資料庫。
退款有3個步驟：
（1）使用repository載入訂單業務物件到記憶體；
（2）呼叫設計師訂單業務物件的退款方法改變業務物件的狀態，然後生成乙個退款訂單業務物件；
（3）使用repository持久化設計師訂單和退款訂單業務物件。
此外，應用層還額外處理了資料持久化的事務。
2 領域層
領域層是實現所有業務規則的領域物件，它是整個軟體的核心，並且與領域模型保持一致。
@data
@equalsandhashcode(of = )
public class designerorder implements entity
if (math.abs(amount - this.expectedamount) > 0.01)
this.state = designerorderworkflowservice.changestate(this.id, state, designerorderstate.paid);
this.actualpaidamount = amount;
// 付款完成後，自動啟動進度跟蹤
this.progressreport.startup();
}public refundorder refund(string cause)
private void assertcanrefund()
}@override
public boolean sameidentityas(designerorder other)
}
關於領域層的編碼模式，在下文會詳細介紹。
3 基礎設施層
基礎設施層為上層提供通用的技術能力，包括訊息傳遞、快取、遠端呼叫、分布式事務、持久化、ui繪製等。以下是持久化實現的一段**。它以整個實體作為儲存單元（注意：準確的說，是以聚合根為儲存單元，後續詳細介紹）。
@repository
public class designerorderrepositoryimpl implements designerorderrepository
}@override
public designerorder selectbykey(int id)
@override
public designerorder selectonebyspecification(designerorder example)
@override
public listselectbyspecification(designerorder example)
@override
public void update(designerorder order)
}}
一定要牢記：ddd分層架構乙個核心任務，就是將軟體最重要的資產——業務規則分離出來，抽象在領域層，確保這些**是領域模型的正確實現。
通過以上的分層示例，我們可以總結出來領域驅動設計的**基本模式：
上層應用層通過factory、repository、領域物件協同來完成使用者任務。
通過factory、repository來處理領域物件生命週期管理，包括領域物件建立、載入、持久化。
領域物件由狀態和對狀態變更的操作組成，它是業務規則的實現。在這裡，字段代表狀態，方法代表狀態變更。領域物件狀態變更後，由repository進行持久化。如何涉及多個領域物件狀態變更的一致性，則這幾個領域物件的狀態變更將組合在一起，由repository進行一致性變更。
基本模式：新建——通過factory建立領域物件，呼叫領域物件方法更改狀態，使用repository將領域物件持久化；變更——通過repository載入領域物件，呼叫領域物件方法更改狀態，使用repository將領域物件持久化。
解構領域驅動設計（二） 分層架構
反映業務規則的 是整個軟體的核心，但是它一般只佔很小的一部分，在傳統的基於貧血模型的分層軟體架構中，業務規則可能分散到各個層 各個 段，從而使得通過 來還原業務規則或者保證 與業務規則一致將變得非常困難。ddd分層架構的核心思想就是將所有業務規則的 抽取到領域層，保證領域層的編碼與領域模型是完全一致...
領域驅動設計 學習筆記 分層架構
在物件導向的程式中，使用者介面 ui 資料庫和其他支援 經常被直接寫到業務物件中去。在ui和資料庫指令碼的行為中嵌入額外的業務邏輯。出現這種情況是因為層短期的觀點看，它是使系統執行起來的最容易的方式。當與領域相關的 和大量的其他 混在一起時，就很難閱讀並理解了。對ui的簡單改動就會改變業務邏輯。改變...
領域驅動設計 學習筆記 分層架構
在物件導向的程式中，使用者介面 ui 資料庫和其他支援 經常被直接寫到業務物件中去。在ui和資料庫指令碼的行為中嵌入額外的業務邏輯。出現這種情況是因為層短期的觀點看，它是使系統執行起來的最容易的方式。當與領域相關的 和大量的其他 混在一起時，就很難閱讀並理解了。對ui的簡單改動就會改變業務邏輯。改變...