.NET应用架构设计—面向查询的领域驱动设计实践（调整传统三层架构，外加维护型的业务开关）

阅读目录：

• 1.背景介绍
• 2.在业务层中加入核心领域模型（引入DomainModel，让逻辑、数据有家可归，变成一个完整的业务对象）
• 3.统一协调层Application Layer（加入协调层来转换DomianModel）
• 4.从数据扁平结构转换成OO体系结构（使用OO丰富代码结构）
• 5.DomainModel中的内容（带开关的Specification、SOA化的Specification）
• 6.模式、重构、单元测试在领域模型中的运用

1.背景介绍

因为时间关系废话很少扯了，直奔主题，对领域驱动设计不是太了解的朋友请先熟悉相关主题或参考本人如下两篇文章：

.NET领域驱动设计—初尝(疑问、模式、原则、工具、过程、框架、实践)，这篇文章对领域驱动设计的基本精神详细分析；

.NET领域驱动设计—实践(穿过迷雾走向光明) ，这篇文章对领域驱动设计的一个基本实践，记录下了实践过程、建模的技巧等内容；

DomainModel是由不少细粒度的Object组成，按照以往的教训（将Object行为、数据肢解，获得一个残缺的Object），如今咱们将逻辑行为和数据绑定在一块儿，造成了一个丰富的领域模型，这也是面向对象设计原则之一；想了解更多关于实现面向对象的技巧请参考【《实现模式》做者：Kent Beck】一书；

可是这样又带来了因为充血型DDD模型会给面向大规模查询的业务模块带来必定的性能开销，试想一个OrderManager对象，若是咱们须要获取在某个条件范围类的全部Order会给OrderManager带来不少性能、逻辑上的复杂度；根据DDD.CQRS架构，得知将DomainModel中的查询逻辑单独剥离出去，让Command端很干净的处理聚合的写逻辑，在Query端也很直接的处理查询逻辑；

这样设计以后会有一个很尴尬的状况，在Query端的DomainModel不被关注了，由于Query的逻辑有简单有复杂，大型站点会有不少复杂的查询逻辑还会有不少的业务开关，作过维护的朋友应该知道新功能上线须要有switch的控制，这是为了安全起见吧；可是简单的业务逻辑就会被咱们下意识的认为不须要使用完整的DomainModel结构，仍是使用传统的分层架构上层依赖下层，Business Layer直接依赖DataAccess Layer，其实这个时候Business Object已经不在是遵循“单一职责”原则了，这样时间一长又慢慢的回到了之前肢解Object的困境；

这篇文章是讲解如何在Query端实践DDD，如何运用DDD的强项来解决复杂业务逻辑的实现，尤为是复杂的业务逻辑须要开关控制的时候其实更须要DomainModel来完成；

2.在业务层中加入核心领域模型（引入DomainModel，让逻辑、数据有家可归，变成一个完整的业务对象）

因为咱们缺少领域模型，因此致使咱们的业务逻辑、规则随波逐流，无家可归，时间久了就搞不清到底这块业务逻辑是哪里的；咱们现有的Domain Model是一个数据映射对象用来传递数据用的，严格意义是一个DTO对象，大部分的项目都将DTO命名为DomainModel可是其实里面没有任何的行为、方法，只是一个纯粹的数据传输用的容器，因此称不上DomainModel；

因此咱们首先要作的就是加入DomainModel，而后逐渐将逻辑搬移到DomainModel中来，在进行逐步的重构、单元测试，让其成为一个能够测试的具备必定核心价值的可重用的DomainModel；

3.统一协调层Application Layer（加入协调层来转换DomainModel）

咱们的Service没有Application Layer  也称协调层，专门用来组装业务处理环节的统一调度中心，它并不是只是一个简单的静态类；传统三层中没有应用层的概念或者说应用层的概念没扭曲了，或者并无发挥其的核心做用；咱们须要加入应用层来协调DomainModel的工做；

4.从数据扁平结构转换成OO体系结构（使用OO丰富代码结构）

当咱们使用DTO对象成功将数据从数据源获取以后，就须要一个对象化的过程，将扁平化的数据实体转换成丰满的领域模型，这个时候全部的领域规则将起做用；

5.DomainModel中的内容（带开关的Specification、SOA化的Specification）

1.实体:

简单理解为OO对象，能够独立存在也能够聚合在某个领域实体下，若是聚合在某个实体下那么只能经过父级实体进行一系列的访问；

2.工厂:

对实体进行有相关约定的建立，这其中包括各类验证、约束、开关等等前提条件。注意：建立实体不像建立数据DTO那么简单；

3.规约、规约工厂:

对业务规则进行对象化，将本来淹没在杂乱无章代码中的核心业务规则提取出来统一管理；这能够很好的像规则配置化（专业称：规则外挂）；注意：这能够和咱们的业务开关进行合并；最值得惊喜的是能够经过规约工厂来实现面向SOA的规约；

4.领域事件（扩展）:

监控、观察等等非侵入式的获取实体在业务处理当中的状态数据，如：发送一封邮件、记录一条LOG，可是这种代码严禁写入业务逻辑层包括分层架构中的任何一个层面，它必须是在一个可有可无的宿主中进行，相似管道模型的Module；

5.面向特定业务开关:

因为咱们每次添加或修改业务逻辑都会加入相应的开关控制，若是这个开关是和业务逻辑相关的那么就能够很巧妙的和规约合并设计；

6.模式、重构、单元测试在领域模型中的运用

设计模式的运用：经过运用DDD就能够方便的对Domain Model进行设计模式的强粒度运用；

重构的运用：对领域模型进行重构就不须要考虑业务逻辑会影响到其余层面；

单元测试的运用：能够独立对领域模型进行测试，包括细粒度的接口抽取都会很方便；

 

总结：因为时间关系文中都是精简的介绍，具体的理解能够参考我上传的代码示例:http://files.cnblogs.com/wangiqngpei557/3WDDDDemo.zip

 

做者：王清培

出处：http://www.cnblogs.com/wangiqngpei557/

本文版权归做者和博客园共有，欢迎转载，但未经做者赞成必须保留此段声明，且在文章页面