演進領域驅動架構的着手點：
1 避免領域模型出現貧血模型
2 保證領域模型的純粹性
避免貧血的領域模型
經典三層架構中
1 領域邏輯 在 業務邏輯層的service對象中
2 反映了領域概念的 領域對象 被定義爲Java Bean 此 Java Bean未包含任何領域邏輯 被放在 數據訪問層
3 DAO 對象僅負責與數據庫的交互，並實現領域對象到數據表的 CRUD（增刪改查）操作
面向對象的設計原則：
數據與行爲應該封裝在一起
貧血對象：
Java Bean 由於僅包含了訪問私有字段的 get 和 set 方法。
貧血對象導致的問題：
不具備對象的豐富表達能力，當業務邏輯變得複雜時，在表達領域模型方面就會變得“力不從心”，無法有效應對重用與變化，且可能導致臃腫的“上帝類”。
貧血模型帶來的問題在戰術設計中深入解釋
結論：
在面向對象設計背景下，當我們面對相對複雜的業務邏輯時，應避免設計出貧血模型
如何避免 貧血模型：
合理地將操作數據的行爲分配給這些領域模型對象（Domain Model）
領域模型對象包含了領域邏輯，就需要從數據訪問層轉移到業務邏輯層。
DAOs 對象需要操作這些領域模型對象，使得處於數據訪問層的 DAOs 對象 必須依賴 領域層的領域模型對象
避免貧血的領域模型，就不可能避免底層的數據訪問層對業務邏輯層的依賴。
保證領域模型的純粹性
加粗的兩條依賴線可以清晰地看到領域層與基礎設施層之間產生了“雙向依賴”
兩個層次的緊耦合
領域模型變得不再純粹
根因：
高層直接依賴了低層，去掉右側 Services 指向 DAOs 的依賴
實現邏輯是容易變化 抽象不易改變
解決：
改進設計的方式是對 DAOs 進行抽象，然後利用依賴注入對數據訪問的實現邏輯進行注入
抽象層應該放在哪？
抽象的資源庫接口代表了領域行爲，應該放在領域層
實現資源庫接口的數據庫持久化，需要調用諸如 MyBatis 這樣的第三方框架，屬於技術實現，應該放在基礎設施層
抽象的 Repositories 被搬遷至領域層，圖中的領域層就不再依賴任何其他層次的組件或類，成爲一個純粹的領域模型。我們的演進正逐步邁向整潔架構！
用戶展現層的變遷
前後端分離的架構思想，將用戶展現層徹底分離出去，形成一個完全松耦合的前端層。
缺點：
基礎設施層在這裏出現了兩次，但同時也充分說明了基礎設施層的命名存在不足
架構也凸顯了分層架構在表現力方面的缺陷。
引入應用層
領域驅動設計要求應用層“不包含業務邏輯”，但對外它卻提供了一個一致的體現業務用例的接口。
取代 接口層（Controller 以及 Iface） 與封裝了 Entity 與 Value Object 的 Aggregate、Services 以及抽象的 Repositories 接口協作。
基礎設施層（controller Iface）的本質：
基礎設施層要做的事情不正是封裝對外部系統或資源的訪問
對業務的支撐，提供了與業務邏輯無關的基礎功能實現。