从三层架构迈向领域驱动设计(转载)
三层架构
严格分层架构模式的特点是上层只能访问相邻的下层，其他层次间的调用都不允许。三层架构就是一种严格分层模式，它把职责划分为界面展示、业务逻辑、数据访问三层，还有一个业务实体，前面三层都要依赖它，所以它并不构成一个层。
三层架构的特点是一种面向过程的编程思想，特点如下：
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. 如果三层架构不采用业务实体与数据表一致的做法，这层也是一样。由于内存结构与数据表结构之间存在阻抗失配，存取领域对象没那么简单。
参考资料
《领域驱动设计精简版》
