小研究 - 领域驱动设计DDD在IT企业内部网站开发中的运用（二）

在企业内部网站的建设过程中，网站后端最初采用传统的表模式的开发方式。这种方式极易导致站点的核心业务逻辑和业务规则分布在架构的各个层和对象中，这使得系统业务逻辑的复用性不高。为了解决这个问题，作者在后期的开发过程中引入了领域驱动设计的开发方式，把系统的业务逻辑独立建模、充分地复用，并基于这些模型打造易于扩展的开发框架，提高了整个团队开发业务逻辑的效率，最终网站如期上线，稳定运行至今。

目录

2 开发模式的应用

2.1 初期采用表模式开发模式

2.2 后期采用DDD开发模式来聚焦业务逻辑

3 结束语

---

2 开发模式的应用

2.1 初期采用表模式开发模式

在最初的开发过程中，作者带领团队采用表模式开发系统，也就是每个业务功能的开发都遵循如下的流程：
1) 根据业务的需求分析得到数据表的字段，把数据库表建好。
2) 通过ORM将数据库中的表映射成代码中的实体对象。
3) 在业务逻辑层根据功能的需要补充业务逻辑和规则，操作实体对象进行数据的读取和持久化。

这种开发方式简单易行，但是随着网站的功能逐渐增多，逻辑越发地复杂，如下问题逐渐显现出来：
1) 通过ORM得到的实体对象都是贫血模型，它们只有数据库映射的属性和字段，并不具有具体的业务行为。
2) 因为没有明确的约束，核心业务逻辑和业务规则非常容易从业务逻辑层扩散到其他层和对象中。有的跑到了帮助类中、有的跑到了存储过程里，这导致了业务逻辑的复用性不高。

为了解决上述问题，作者再次深入研究了上述的软件开发模式并决定引入DDD来开发和管理项目。

2.2 后期采用DDD开发模式来聚焦业务逻辑

使用DDD开发模式来开发和管理项目，作者带领团队实践了如下的过程。

1) DDD战略设计
①将整个应用程序域进行划分，剥离各个子域在该项目中，经过分析，作者共拆分出账号管理、任务管理、积分管理、图书管理等子域。
②对每个子域进行限界上下文的设计在每个限界上下文中，保证任何一个对象模型的语义是确定的、无歧义的。

虽然两个User对象具有相同的名字，但是它们是完整的用户对象在不同上下文中的投影，是两个不同的对象。

在项目实施的过程中，作者选择将子域和限界上下文一一对应，独立部署在每个AppService中。

2) DDD战术设计
DDD战术设计的核心就是把核心业务逻辑集中放到一起，组成领域层。其他层设计为依赖于该层。领域层中包含所有重要的领域模型，包括聚合根、实体、值对象、领域事件、仓储、领域服务等。

①设计聚合根、实体和领域服务在该项目的领域层中，最重要的对象就是聚合根和实体。它们完成了主要的业务逻辑。

使用聚合根还是实体，在实践中一般都可以，但是如果完成一个业务操作，就一个主要的实体就可以了，不需要其他相关实体的配合，那么暴露这个实体给其他层就可以了。

比如Book这个实体，不仅包含了所有图书的所有信息，还包括增加封面、修改作者、增加点评等各种业务行为。

但是如果完成一个业务操作，需要一个主要的实体，配合上其他一些相关的实体才能完成，那么就将主要的实体暴露成聚合根给其他层使用，把相关的其他实体全部隐藏起来，这些相关的实体的操作统统通过聚合根来暴露。

比如Task这个实体，不仅包含了所有Task自身的信息和操作，还包括其包含的子对象TaskItem实体的信息和各种操作，所以 Task 实体就暴露为聚合根，向外提供所有 Task 和TaskItem的相关操作，其他层无法直接操作TaskItem对象以及其方法。如图6所示。

②设计领域事件
该项目中，非常常见的一个需求就是一个实体改变了，需要通知其他的一些实体就行一些对应的变化。这种需求就需要通过事件模式来实现。

在项目中，作者实现了一个EventBus作为通用的领域事件模型，任何实体都可以挂接这个对象，发布消息，或关注感兴趣的消息并做出响应，这个部分与通用的事件模型并没有太大的不同，示意图如图7所示。

③设计仓储
使用仓储模式可以很好地隔离数据库的操作和领域对象。

在领域层，作者定义了各个仓储接口，仓储与聚合根或实体一一对应，包含对应的增删改查等操作，它们是数据库操作的接口。

需要注意的是，在领域层中，只是定义了接口，并没有具体的持久化的实现。具体的持久化工作放在了基础设施层中。

3) 其他层的一些细节
①基础设施层
这里重点说明一下的是数据库持久化的选型。针对领域层提供的仓储接口，作者实现时选择了使用Enti⁃ty Framework Core(以下简称EF Core) 作为基础框架。使用此类ORM框架大大简化了数据库的操作，使用对象而不是SQL语句的方式可以避免很多语法上的错误，有效地提升了代码的健壮性。

而且使用了EF Core的Code First的方式后，项目只要使用EF Core的包命令就可以非常简单地根据实体对象的变更来创建和维护数据库。

②应用服务层
在该项目中，应用服务层比较简单，它实现了一个公用的AppService，封装了公用的分页的逻辑。其他各项服务比如BookAppService都继承自该基类，实现了自己的逻辑。

在各个服务中，为了调用领域层的业务逻辑，首先需要把前端传过来的输入数据传输对象(Data Transfer Object，以下简称DTO) 转换成领域层的数据模型，然后调用领域层的领域模型和基础设施层的对象完成功能，最后再将结果转换成输出DTO返回给前端。

③后端接口层和前端表现层
接口层使用Restful Api去提供服务，前端表现层使用Vue3.0实现展示，不管是否使用DDD，这些部分都是一样的，不去多解释。
经过上述的分析、设计与重构，最终得到如下新的架构，如图8所示。

3 结束语

采用了DDD来开发和管理项目以后，项目的业务逻辑沉淀到了领域层的领域对象中，领域对象变成了包含业务逻辑的充血模型，这样业务逻辑得到了复用，程序的扩展性得到了保证。

此外，由于存在清晰明确的分层和职责，团队日常的开发效率得到了显著的提升。目前该站点已经上线并稳定地运行至今。