领域驱动设计理论



　　对DDD（领域驱动设计）最初的了解，始于这一篇博文：http://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html，当时花了四五个小时阅读完，但只是初步对DDD有个了解，有点颠覆自己对编程思想的看法。2004年 Eric Evans 发表 Domain-Driven Design –Tackling Complexity in the Heart of Software （领域驱动设计- 软件核心复杂性应对之道），简称Evans DDD，这本书网上一直没有买到，很遗憾，如果有的朋友有珍藏，可以高价收购。

　　什么是DDD（领域驱动设计）？DDD中最核心的是Domain Model（领域模型），和领域模型相对的是事务脚本，领域模型和事务脚本说到底就是面向对象和面向过程的区别。

• 事务脚本：围绕功能，以功能为中心。将所有逻辑组织在一个单一过程，进行数据库直接调用，每笔交易（业务请求）都有自己的事务脚本，并且是一个类的公开方法。
• 领域模型：描述领域类，以类之间的协作完成所需功能。所谓领域模型，是一系列相互关联的对象，每个对象代表一定意义的独立体，既可以一起以一种大规模方式协作；也可以小到以单线方式运行。

　　好像有个报告统计，大约80%的程序员使用事务脚本编程，三层架构（UI、BLL、DAL）对于我们来说太熟悉了，编程的时候代码一般会集中在DAL层，致使数据访问层充斥着大量的业务逻辑，而且很难复用，每个DAL中的类就像一个单元，只为某一功能实现，也就是上面所说的“单一过程”，因为业务逻辑都实现在数据访问层了，这样业务逻辑层就成了一个空架子，有的人就会觉得BLL-业务逻辑层没有存在的必要，然后设计的时候就把业务逻辑层去掉了，就只剩UI和DAL层了，外加一些HelpClass，然后的然后。。。

　　领域驱动设计的概念从提出到现在十年了，现在很少的公司能真正的去应用，而还是采用事务脚本的方式，为什么？其实就是一种思想，或者说方式的转变，就好比你以前习惯用手直接吃饭，现在让你拿筷子吃饭，肯定会不习惯。当然还有一部分原因是领域驱动设计的推行，或者说国内有关这领域的大牛们很少，但我觉得不管怎样，这是个趋势，就像黑夜过后，一定会是清晨一样。

　　上面说到三层架构（UI、BLL、DAL），我们再看一下领域驱动设计的分层：

　　　　　　　　　　来自：dax.net

主要分为四层（表现层、应用层、领域层和基础层）：

• Presentation Layer：表现层，负责显示和接受输入；
• Application Layer(Service)：应用层，很薄的一层，只包含工作流控制逻辑，不包含业务逻辑；
• Domain Layer(Domain)：领域层，包含整个应用的所有业务逻辑；
• Infrastructure Layer：基础层，提供整个应用的基础服务；

　　领域驱动设计主张充血模型，也就是富模型的意思，大多业务逻辑都应该被放在Domain Object里面（包括持久化业务逻辑），而Service层应该是很薄的一层，仅仅封装事务和少量逻辑，不和Dao层打交道。 

　　优点：

1. 更加符合OO的原则。
2. Service层很薄，只充当Facade的角色，不和Dao打交道。

　　缺点：

1. Dao和Domain Object形成了双向依赖，复杂的双向依赖会导致很多潜在的问题。 
2. 如何划分Service层逻辑和Domain层逻辑是非常含混的，在实际项目中，由于设计和开发人员的水平差异，可能导致整个结构的混乱无序。 （这个问题在项目实际运作的时候会出现，划分很重要。）
3. 考虑到Service层的事务封装特性，Service层必须对所有的Domain Object的逻辑提供相应的事务封装方法，其结果就是Service完全重定义一遍所有的Domain Logic，非常烦琐，而且Service的事务化封装其意义就等于把OO的Domain Logic转换为过程的Service TransactionScript。该充血模型辛辛苦苦在Domain层实现的OO在Service层又变成了过程式，对于Web层程序员的角度来看，和贫血模型没有什么区别了。 （和第二点类似，如何做到Application层不包含业务逻辑，协调领域层和基础层很重要。）

　　领域模型概念参照：http://www.oschina.net/question/12_21641

　　领域驱动设计系列：http://www.cnblogs.com/daxnet/archive/2010/11/02/1867392.html