領域驅動設計的個人理解
接觸領域驅動設計有一年多了，領域驅動的開發方式是需要一個團隊來執行，而不是個人，因此對於一個新的開發方式，你不僅是一個開發者，更是一個佈道者，也算是實施領域驅動設計的一個重要難點。
領域驅動開發的好處
關於領域驅動設計的基本理論知識，比如實體，值對象，工廠，倉儲，聚合和聚合根等概念，園子已有多位園友進行過介紹，在這裏不再贅述。我重點談一談對比經典三層的開發方式，爲什麼要使用領域驅動開發？
三層架構雖然使用了分層架構的思想，卻忽視了我們手中最重要的武器，面向對象編程語言（C#或者Java），我們拿着它卻幹着面向過程的開發。我們都知道三層的架構，中間一層是所謂的業務邏輯層，其實很多時候這一層的編碼更像是功能的定義，有時甚至可以叫做數據訪問層的門面（facade）。當需要一個新功能，就在該層添加相應的功能代碼，調用該功能所關聯到的表進行各種CRUD操作，固然這種方式理解和操作起來簡單直接，在初期開發順利而高效，但隨着項目業務複雜度增加和需求不斷變更，後期的維護變得非常痛苦，原因就是業務代碼沒有邊界，所有的修改就很有可能遍佈整個業務邏輯層，甚至延伸到界面及數據訪問層。
爲什麼領域驅動設計比面向過程設計更能適應業務邏輯的變化，有人會說是對業務領域邏輯進行了很好的理解和建模，當然這是領域驅動設計的核心，還有一個核心概念聚合，它將整個業務邏輯進行了細緻的劃分，不僅是在實體的操作和性能等方面考慮而提出的設計，同時具有模塊化的帶來的好處：內聚。在一個比較完整的業務模型被建立之後，面對需求的變更，一般僅會牽扯到一個或少數幾個業務模塊的修改，並且代碼描述了業務邏輯，很容易理解並進行修改。（如果修改了很多地方，那麼就不是一個項目了或者業務模型在最初就出現了嚴重錯誤的設計，這也是爲什麼要有領域專家要參與到項目的各個階段）
貧血模型還是充血模型
領域驅動設計的權威著作（主要指Eric Evans的經典著作）從來沒有提到所謂貧血或充血的模型選擇（貌似Eric Evans寫書時可能還沒有這些名詞），原因很簡單，領域驅動設計遵循OOP的特性，一個實體作爲對象，本身就有其屬性和方法，因此必定是“充血”的，有方法的，除非該對象沒有行爲。因此，採用DDD開發時，無需再爭辯這個問題。
自然的設計模式應用
領域驅動設計是面向對象的，那麼就遵循面向對象的設計原則，因此在設計時設計模式的應用也是很自然的事情。OOP三大特性，在我們從接觸面嚮對象語言時就被一直唸叨（各種面試題中也會出現），但是貧血的設計，使得模型沒有方法的“封裝”，更別談“多態”了。
小結
本文重點描述了我對領域驅動設計的一些個人觀點，還有許多想法沒有表述出來，歡迎交流，如有不當，敬請拍磚。
——————————————————————————————
擴展閱讀
1.領域驅動設計精簡版：http://www.infoq.com/cn/minibooks/domain-driven-design-quickly
2.領域驅動設計和開發實戰：http://www.infoq.com/cn/articles/ddd-in-practice