.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://wangqingpei557.blog.51cto.com/

本文版权归作者和51CTO共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。