从三层架构迈向领域驱动设计(转载)

三层架构

严格分层架构模式的特色是上层只能访问相邻的下层，其余层次间的调用都不容许。三层架构就是一种严格分层模式，它把职责划分为界面展现、业务逻辑、数据访问三层，还有一个业务实体，前面三层都要依赖它，因此它并不构成一个层。

三层架构的特色是一种面向过程的编程思想，特色以下：

a. 业务实体类中基本上只有属性没有方法。

b. 业务逻辑层的类基本上只有方法没有属性。

c. 将数据表结构映射为业务实体类是一个惯用作法，以致于有人将其称之为“传统”。这样的好处是只须要理解一套模型，可以经过自动化工具从数据表直接生成业务实体，还可以天然而然的经过自动化机制存储与检索业务实体。但对于复杂点的业务，这样作就是绝大部分问题的根源。

d. 当业务膨胀起来，须要划分模块的时候，咱们有个经常使用的变形：提取一个服务层出来，用来组合模块间的交互，还为业务逻辑层提供了一个防腐层，能够把记录日志、验证权限、处理异常等职责分配给服务层。

因为采用了严格分层模式，用户界面层是绝对不能跨过业务逻辑层调用数据访问层的，同理服务层也是不能调用数据访问层。可是图2都有四层了。

其实三层架构还有个更准确的名字----分层贫血领域模型架构，前面名字中的领域模型指的是业务实体，贫血意思业务实体中没有或不多方法。

三层架构的反思

三层架构的最大问题在于：实际应用中人们喜欢把内存模型和数据库模型保持一致。三层架构的大部分问题都是从这里衍生出来的。

数据库模型的粒度若是很小，那么大量的表链接很快就会让数据库跑不动了。

若是数据库模型的粒度若是很大（这是大部分项目的选择），代码的质量（重用性、稳定性、扩展性）就不好。因为没有从业务的角度去仔细定义每个对象，每一个人会根据本身的须要创建各类QueryModel或ViewModel，慢慢地类会多到想哭。

还有一些三层开发人员最终患上了数据库痴迷症，他坚信程序就应该作个搬运工，其余的事情都应该交给数据库来完成，业务逻辑也应该写进存储过程里面去。

三层分层到DDD分层的转变过程

优化三层结构&重构到面向对象的设计

因为目前的服务层职责是很是轻的，甚至有不少空壳的调用，因此平衡一下职责，把调用数据访问层的职责从业务逻辑层提高到服务层，须要的数据经过参数传递给业务逻辑层。这样，对于那些简单到无业务逻辑的CRUD就不须要去访问业务层了，直接调用数据访问层。

结构如图3，咱们看到业务逻辑与数据访问层已经没有依赖关系了。

而后咱们就能够把业务逻辑与业务实体移到一块。

而后把属于业务实体的逻辑迁移到实体类中。

图4基本上就是图3的各个层换了名字，而且UI能够访问基础设施层。而图4与图5的区别在于，图4是基础设施依赖领域层，图5是领域层依赖基础设施层。

用户界面层：

原版----负责向用户展示信息以及解释用户命令。

补充---- MVC中V和C都属于UI层，V展示信息，C解析用户命令。UI像地图同样把各个控制器关联了起来。

应用层

原版----很薄的一层，用来协调应用的活动。它不包含业务逻辑。它不保留业务对象的状态，但它保有应用任务的进度状态。

补充----协调应用的活动这句话太抽象了，我充实一下它：从数据访问中获取领域对象，调用领域对象的方法完成任务，而后再调用数据访问代码把领域对象的改变持久化。事务、权限检查、记录日志、处理异常的职责也归它管。这点和前面三层的服务层的职责实际上是同样的。

领域层

原版----本层包含关于领域的信息。这是业务软件的核心所在。在这里保留业务对象的状态，对业务对象和它们状态的持久化被委托给了基础设施层。

补充----业务对象的持久化工做咱们已经提高到应用层了，通常状况下，这层最好不要涉及资源库的调用，可是并不绝对。资源库的抽象要么在领域层中，要么提高到了“应用程序框架”，领域层是不会依赖基础设施的。

基础设施层

原版----本层做为其余层的支撑库存在。它提供了层间的通讯，实现对业务对象的持久化，包含对用户界面层的支撑库等做用。

对比三层分层与DDD分层

a. UI层技术基本同样，一些比较智能的绑定可能没法进行了。

b. 服务层基本同样。

d. 业务实体+业务逻辑 = 领域层

e. 若是三层架构不采用业务实体与数据表一致的作法，这层也是同样。因为内存结构与数据表结构之间存在阻抗失配，存取领域对象没那么简单。

参考资料

《领域驱动设计精简版》