目前团队大多数项目都是基于DDD分层架构开发的,而不是传统的MVC模式,这就让很多之前没有接触过DDD思想的同学在刚开始接触项目的时候有点懵。那么什么DDD?这种DDD项目结构和之前的有哪些不同,我该如何开发我的代码,开发不同职责的代码该放在哪里?下面就我的理解,说一说DDD的分层架构。
传统的数据驱动开发模式,View、Service、dao这种三层分层模式,我们会很自然的写出过程式代码,这种开发方式中的对象只是数据载体,而没有行为,是一种贫血对象模型。以数据为中心,以数据库ER图为设计驱动,分层架构在这种开发模式下可以认为是数据处理和实现的过程。
image.png
DDD 全称是 Domain-Driven Design,中文叫领域驱动设计,是一套应对复杂软件系统分析和设计的面向对象建模方法论。
以前的系统分析和设计是分开的,导致需求和成品非常容易出现偏差,两者相对独立,还会导致沟通困难,DDD 则打破了这种隔阂,提出了领域模型概念,统一了分析和设计编程,使得软件能够更灵活快速跟随需求变化。
image.png
领域就是范围。范围的重点是边界。领域的核心思想是将问题逐级细分来减低业务和系统的复杂度,这也是 DDD 的核心。
2.子域:
领域可以进一步划分成子领域,即子域。这是处理高度复杂领域的设计思想,它试图分离技术实现的复杂性。
3.核心域:
在领域划分过程中,会不断划分子域,子域按重要程度会被划分成三类:核心域、通用域、支撑域。
4.通用域:
中间件服务或第三方服务。
5.支撑域:
企业公共服务。
6.统一语言:
映射概念:统一概念。
定义上下文的含义。它的价值是可以解决交流障碍,不管是 RD、PM、QA 等什么角色,让每个团队使用统一的语言(概念)来交流,甚至可读性更好的代码。
7.限界上下文:
定义上下文的边界。领域模型存在边界之内。对于同一个概念
8.聚合:
聚合概念类似于包的概念,每个包里包含一类实体或者行为,它有助于分散系统复杂性,也是一种高层次的抽象,可以简化对领域模型的理解。
在定义聚合的时候,应该遵守不变形约束法则:
9. 聚合根:
一个上下文内可能包含多个聚合,每个聚合都有一个根实体,叫做聚合根,一个聚合只有一个聚合根。
10. 实体:
Domain 或 entity。(有唯一ID)
11. 值对象:
Domain 或 entity。(没有唯一ID)
简单来说,就是 Domain Object 包含了不依赖于持久化的领域逻辑,而那些依赖持久化的领域逻辑被分离到 Service 层。
这种模式不在 Domain 层里依赖 DAO。持久化的工作还需要在 DAO 或者 Service 中进行。
缺点:
2. 充血模型
充血模型和第二种模型差不多,区别在于业务逻辑划分,将绝大多数业务逻辑放到 Domain 中,Service 是很薄的一层,封装少量业务逻辑,并且不和 DAO 打交道。即:Service (事务封装) —> Domain Object <—> DAO
目前我们团队项目分层主要是按照入下图DDD分层进行。
image.png