DDD领域驱动设计学习笔记

好奇这个概念是怎么来的，就来学习一下，并记录一下笔记。

DDD是Domain Driven Design的缩写，翻译过来就是领域驱动设计，这个概念最早来源于Evans E . Domain Driven Design: Tackling Complexity in the Heart of Business Software. Domain Driven Design Tackling Complexity in the Heart of Software, 2002.

为什么要写这个呢？解决软件核心复杂性的问题？到底是什么样的解决方案/解决思路？还是什么思想？分而治之？这些问题先放在这？

了解过后，首先要确定几个概念：

1、领域模型（Domain Model）：它是软件的核心，是对某个边界领域的抽象，反应了领域内用户业务需求。建立正确的领域模型并不简单，需要领域专家、设计、开发人员共同努力。

看完这个概念，我们应该会想到开发过程中的Model层里的Domain包。但Domain里如果存放大量的业务对象模型的话看起来会比较乱或者臃肿，Domain最好就只存放单纯的ORM数据对象实体，业务对象放在bo包下。

2、实体（Entity）：一个由它的标识定义的对象叫做实体，通常实体具备唯一Id且能够被持久化，具有业务逻辑，对应现实业务对象。举个简单栗子：

package domain;
    
import com.baomidou.mybatisplus.enums.IdType;
import java.math.BigDecimal;
import java.util.Date;
import com.baomidou.mybatisplus.annotations.TableId;
import lombok.*;

import java.io.Serializable;

@Data
@Builder
@ToString
@NoArgsConstructor
@AllArgsConstructor
public class OrderInfo implements Serializable {

    private static final long serialVersionUID = 1L;

    /**
     * 主键
     */
	@TableId(value="id", type= IdType.AUTO)
	private Long id;
    /**
     * 订单编号
     */
	private String code;
    /**
	 *
     * 城市编号
     */
	private String cityCode;
}

3、值对象（Value Object）：用于描述领域的某个方面而本身没有概念的对象称为值对象。

对比一下值对象和实体：

• 实体：具有声明周期；有唯一标识；通过Id判断相等性；增删改查/持久化；可变
• 值对象：起描述性作用；无唯一标识；通过属性判断相等性；实现Equals方法；即使创建/用完即扔；不可变（Immutable）

举个栗子：电商里用户可以配置的收货地址，同时可以对一个或多个收货地址进行删除修改，这个就是实体；而用户下单后从收货地址选取其中的一个地址后，这个订单的收货地址就是值对象。

4、聚合及聚合根（Aggregate And Aggregate Root）：聚合是用来定义领域对象所有权和边界的领域模式。一个聚合是一组相关的被视为整体的对象。每个聚合都有一个根对象（聚合根实体），从外部只能通过根对象访问。根实体对象有组成聚合所有对象的引用，但是外部对象只能引用根对象实体。

5、工厂（Factory）： 它用来封装创建一个复杂对象尤其是聚合时所需的知识，作用是将创建对象的细节隐藏起来。

6、仓库（Repositories）：用来管理实体的集合。它本身是一种领域组件，但repositories的实现却不是领域层中的。

7、服务（Service）：服务提供的操作是它提供给使用它的客户端，并突出领域对象的关系。

8、领域事件（Domain Event）：领域事件的触发点在领域模型（Domain Model）中。它的作用是将领域对象从对Repository或Service的依赖中解脱出来，避免让领域对象对这些设施产生直接依赖。

9、数据传输对象（Data Transfer Object）：其主要作用是以粗粒度的数据结构减少网络通信并简化调用接口。

 

失血模型：Domain Object里只有getter/setter方法的纯数据类，所有业务逻辑完全由Business Object（也叫TransactionScript）来完成。

胀血模型：没有Service层，只剩Domain Object和Data Access Object两层，在Domain Object的Domain Logic上面封装事物。

贫血模型：领域对象包含了不依赖于持久化的领域逻辑，而那些依赖于持久化的领域逻辑被分离到Service层。层次结构为：Client->BusinessFacade->BusinessLogic->Data Access Object。

充血模型：绝大多数业务逻辑放在了Domain Object里，BusinessLogic只是简单封装部分业务逻辑以及控制事物、权限等。层次结构为：Client->BusinessFacade->BusinessLogic->Domain Object->Data Access Object。

失血模型和胀血模型是不被提倡的，而贫血和充血模型从技术上讲都是可行的。

 

领域模型设计的具体流程如下：

其实在做业务开发时，也是按照这样的流程来的，不过有些步骤是产品来完成的，如分析出实体以及实体之间的关系。有些时候刚开始听需求评审的时候觉得没啥问题，但有时候做起来发现产品理解的某些方面还是有问题的，最后拉一起又去讨论解决方案，所以在重构模型的时候需要多check一下，多去深入的了解产品的业务需求才能更好的进行开发。

模型化是为了更好的完善开发，但更重要的还是我们自身的基础扎实，一起加油吧！

 

参考链接：https://blog.csdn.net/wwd0501/article/details/95062535/