领域驱动设计之设计分层架构

以前的设计

首先我们回顾下以前我们设计系统的做法。在过去，我们的应用程序架构一直以数据为中心。我们的核心是围绕数据库展开的，首先我们会建立数据库，建立一系列的数据表，数据库表之间的主外键关系表述整个系统中的对象之间的关系。数据表中的一行数据来表述一个对象。然后我们会依次建立数据访问层、业务逻辑层、表现层。如下图所示

注：此图来源 http://www.cnblogs.com/daxnet/archive/2010/07/07/1772584.html

注意图中打虚线的“基础结构层”，从实践的表现上来看，这部分内容可能就是一些帮助类，比如 SQLHelper之类的，也可能是一些工具类，比如TextUtility之类。这些东西可以被其它各层所访问。

表现层、业务逻辑层、数据访问层是一种自上而下的调用关系。表现层只能与业务逻辑层打交道，而业务逻辑层在数据持久化方面的操作，则依赖于数据访问层。表现层对数据访问层的内容一无所知。

1.基础结构层可能包含业务逻辑处理，会使业务逻辑层和基础结构层之间的职责重合

2.过分强调数据的状态，忽略对象之间的关系（或者说是数据库不能很好地表现对象与对象之间的关系）及约束，领域驱动设计中聚合能更好的处理这一点。

3.业务逻辑层不能很好地表现业务逻辑，很多时候我们的业务逻辑层只是对数据访问层的包装（增删改查），模型是失血模型，很多时候模型和dto是一体的。模型扮演了多个角色。

此种设计的典型是微软的petshop，不过微软的petshop业务比较简单，应用此种设计比较合适

领域驱动设计的分层

从此图可以看出 领域驱动设计的层次结构也是4层：基础结构层、表现层、应用层、领域层。与上面相比，数据访问层已经不在了，它被转移到了基础结构层。注意领域层中的Repository是仓储的接口，并非真正的仓储实现。

基础结构层：该层专为其它各层提供技术框架支持。这部分内容不会涉及任何业务知识。数据访问的内容也被放在了该层当中，因为数据的读写是业务无关的，只是对象状态的持久化与重建。

领域层：包含了业务所涉及的领域对象（实体、值对象）、领域服务以及它们之间的关系。这部分内容的具体表现形式就是领域模型（Domain Model）。领域驱动设计提倡富领域模型，即尽量将业务逻辑归属到领域对象上，实在无法归属的部分则以领域服务的形式进行定义。

应用层：该层不包含任何领域逻辑，但它会对任务进行协调，并可以维护应用程序的状态，因此，它更注重流程性的东西。在某些领域驱动设计的实践中，也会将其称为“工作流层”。应用层是领域驱动中最有争议的一个层次，也会有很多人对其职责感到模糊不清。

表现层：这个好理解，跟三层里的表现层意思差不多，但请注意，表现层中的“Web服务”虽然是服务，但它是表现层的东西

从上图还可以看到，表现层与应用层之间是通过数据传输对象（DTO）进行交互的，它的目的只是为了对领域对象进行数据封装，实现层与层之间的数据传递。

因为领域对象更注重领域，而DTO更注重数据。不仅如此，由于“富领域模型”的特点，这样做会直接将领域对象的行为暴露给表现层。

文章引用：http://www.cnblogs.com/daxnet/archive/2010/07/07/1772584.html