领域驱动设计的个人理解

　　接触领域驱动设计有一年多了，领域驱动的开发方式是需要一个团队来执行，而不是个人，因此对于一个新的开发方式，你不仅是一个开发者，更是一个布道者，也算是实施领域驱动设计的一个重要难点。

领域驱动开发的好处

　　关于领域驱动设计的基本理论知识，比如实体，值对象，工厂，仓储，聚合和聚合根等概念，园子已有多位园友进行过介绍，在这里不再赘述。我重点谈一谈对比经典三层的开发方式，为什么要使用领域驱动开发？

　　三层架构虽然使用了分层架构的思想，却忽视了我们手中最重要的武器，面向对象编程语言（C#或者Java），我们拿着它却干着面向过程的开发，在.NET中基本就是表驱动开发，即DataTable，DataSet等数据表概念。我们都知道三层的架构，中间一层是所谓的业务逻辑层，其实很多时候这一层的编码更像是功能的定义，有时甚至可以叫做数据访问层的门面（facade）。当需要一个新功能，就在该层添加相应的功能代码，调用该功能所关联到的表进行各种CRUD操作，固然这种方式理解和操作起来简单直接，在初期开发顺利而高效，但随着项目业务复杂度增加和需求不断变更，后期的维护变得非常痛苦，原因就是业务代码没有边界，所有的修改就很有可能遍布整个业务逻辑层，甚至延伸到界面及数据访问层。

　　为什么领域驱动设计比面向过程设计更能适应业务逻辑的变化，有人会说是对业务领域逻辑进行了很好的理解和建模，当然这是领域驱动设计的核心，还有一个核心概念聚合，它将整个业务逻辑进行了细致的划分，不仅是在实体的操作和性能等方面考虑而提出的设计，同时具有模块化的带来的好处：内聚。在一个比较完整的业务模型被建立之后，面对需求的变更，一般仅会牵扯到一个或少数几个业务模块的修改，并且代码描述了业务逻辑，很容易理解并进行修改。（如果修改了很多地方，那么就不是一个项目了或者业务模型在最初就出现了严重错误的设计，这也是为什么要有领域专家要参与到项目的各个阶段）

贫血模型还是充血模型

　　领域驱动设计的权威著作（主要指Eric Evans的经典著作）从来没有提到所谓贫血或充血的模型选择（貌似Eric Evans写书时可能还没有这些名词），原因很简单，领域驱动设计遵循OOP的特性，一个实体作为对象，本身就有其属性和方法，因此必定是“充血”的，有方法的，除非该对象没有行为。因此，采用DDD开发时，无需再争辩这个问题。

自然的设计模式应用

　　领域驱动设计是面向对象的，那么就遵循面向对象的设计原则，因此在设计时设计模式的应用也是很自然的事情。OOP三大特性，在我们从接触面向对象语言时就被一直念叨（各种面试题中也会出现），但是贫血的设计，使得模型没有方法的“封装”，更别谈“多态”了。

小结

　　本文重点描述了我对领域驱动设计的一些个人观点，还有许多想法没有表述出来，欢迎交流，如有不当，敬请拍砖。在此，要感谢刚获得MVP的晴洋兄的帮助，以及所写的一系列关于DDD的博文的启发。

——————————————————————————————

扩展阅读

1.领域驱动设计精简版：http://www.infoq.com/cn/minibooks/domain-driven-design-quickly

2.领域驱动设计和开发实战：http://www.infoq.com/cn/articles/ddd-in-practice