DDD领域驱动设计笔记

摘自：dax.net陈晴阳博客

1.NLayerApp是经典的DDD架构

2.基础结构层：包括两方面内容，处理数据访问的基础结构层组件主要包含了仓储的具体实现、Unit Of Work（PoEAA，Martin Fowler）的实现、NLayerApp的实体模型定义，以及为单体测试作准备的Service Stubs（PoEAA，Martin Fowler）；Cross-Cutting的基础结构层组件则主要包含了IoC（Inversion of Control）容器以及跟踪应用程序执行过程的Trace工具。虽然这些都是基础结构层的组件，但也包含了不少技术细节甚至是设计要点，就让咱们一块儿对这些内容作一个详细的解读。

3.关注点分离：分离关注点使得解决特定领域问题的代码从业务逻辑中独立出来，业务逻辑的代码中再也不含有针对特定领域问题代码的调用。

4.仓储不是Data Object，也不单单是进行数据库CRUD操做的Data Manager，它承担了解耦领域模型和技术架构的重要职责。

5.依赖注入是维持领域模型纯净度的一大利器；另外一大利器是领域事件..net中微软有一个轻量级的IoC框架Unity，支持构造器注入，属性注入.IOC做用:将各层的对象以松耦合的方式组织在一块儿，解耦，各层对象的调用彻底面向接口。当系统重构的时候，代码的改写量将大大减小。一般有调用者来建立被调用者的实例。建立被调用者的实例的工做由IOC容器来完成，而后注入调用者，所以也称为依赖注入。

6.领域层：包含了业务所涉及的领域对象（实体、值对象）、领域服务以及它们之间的关系。这部份内容的具体表现形式就是领域模型（Domain Model）。领域驱动设计提倡富领域模型，即尽可能将业务逻辑归属到领域对象上，实在没法归属的部分则以领域服务的形式进行定义。表现层与应用层之间是经过DTO进行交互的，DTO是没有行为的POCO对象，目的只是为了对领域对象进行数据封装，实现层与层之间的数据传递。为什么不能直接将领域对象用于数据传递？由于领域对象更注重领域，而DTO更注重数据。不只如此，因为“富领域模型”的特色，这样作会直接将领域对象的行为暴露给表现层

7.应用层：

数据传输对象DTO须要说明的几点

　　1）DTO的设计须要面向客户端（包括客户端应用程序、与外部系统集成的Web Services等），客户端的View Model须要什么样的数据，就设计什么样的DTO。应用层负责收发DTO数据，并根据DTO数据访问领域模型中的实体，根据实体组装DTO。ORM解决的是Domain Model与关系型数据库之间的阻抗失衡，而DTO解决的是View Model与Domain Model之间的阻抗失衡
　　2）DTO应该是POCO，它不能依赖于任何技术框架
　　3）对于中小型系统，能够考虑使用相似NLayerApp的Serialized Domain Entities方式，这能够提升开发效率；但若是是大型系统，仍是建议使用DTO，有朋友会以为每次根据View Model去设计DTO很耗时，但我以为若是应用程序规模较大的时候，仍是作足功夫比较好，磨刀不误砍柴工，这样在从此作系统集成的时候也会方便一些。能够考虑使用DSL与自动化代码生成技术来解决DTO的设计问题
　　4）WCF产生的代理类Data Contracts就是一种DTO，若是专用微软的技术，那么也就与上述第二点不矛盾，Serialized Domain Entities能够以Data Contracts的形式出如今客户端程序中，必定程度上屏蔽了直接将Serialized Domain Entities用做DTO的负面影响

8.Specification是值对象，它是领域层的一部分，一样也不会去关心持久化技术实现细节。规约是一种布尔断言，它表述了给定的对象是否知足当前约定的语义。

 

 DDD领域驱动设计qq群：463810724