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

知识点掌握了，还需要不断练习才能熟练运用。下面golang学习网给大家带来一个数据库开发实战，手把手教大家学习《从三层架构迈向领域驱动设计(转载)》，在实现功能的过程中也带大家重新温习相关知识点，温故而知新，回头看看说不定又有不一样的感悟！

三层架构

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

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. 如果三层架构不采用业务实体与数据表一致的做法，这层也是一样。由于内存结构与数据表结构之间存在阻抗失配，存取领域对象没那么简单。

参考资料

《领域驱动设计精简版》

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于数据库的相关知识，也可关注golang学习网公众号。