DDD

如何进行软件设计

拿到需求的时候，先设计领域模型

每次变更的时候，先回到领域模型，基于业务对领域模型进行变更，然后基于领域模型进行代码变更

如何应对软件退化

how

接收用户请求

执行某些操作

领域对象之外的操作与行为

服务

通过一个唯一标识字段来区分真实世界中的每一个个体的领域对象

实体

代表的是真实世界中那些一成不变的、本质性的事物

值对象

区分服务、实体、值对象

区别在于实体是可变的，值对象是不可变的

业务逻辑在service中实现

贫血模型

继承、多态的部分在领域对象实现

类型或者编码的转换逻辑

希望更好的表现领域对象之间的关系

聚合---(订单明细和订单)

业务逻辑在领域对象中实现

充血模型

业务领域模型转换为程序设计

描述：体现整体与部分的关系

判断：如果整体不存在，部分是否存在。如果不存在，那么是聚合关系。反之，则不是。

外部访问的唯一入口

好处：当聚合内部的业务逻辑发生变更时，只需要对内部逻辑进行更新，与外部程序无关，降低变更的维护成本，提高设计质量。

局限：领域驱动设计通常适用于增删改的业务操作，但不适用于分析统计。

聚合根

指导：领域驱动设计通常适用于增删改的业务操作，但不适用于分析统计。在一个系统中，增删改的业务可以采用领域驱动的设计，但在非增删改的分析汇总场景中，则不必采用领域驱动的设计，直接 SQL 查询就好了，也就不必再遵循聚合的约束了。

设计实现：仓库与工厂

聚合

仓库

这时订单仓库会将这个任务交给订单工厂，订单工厂就会分别调用订单 DAO、订单明细 DAO 和用户 DAO 去进行查询；然后将得到的订单对象、订单明细对象、用户对象进行装配，即将订单明细对象与用户对象，分别 set 到订单对象的“订单明细”与“用户”属性中；最后，订单工厂将装配好的订单对象返回给订单仓库。

通过id装载一个订单

通过装配，创建领域对象

工厂

聚合、仓库、工厂

将整个系统划分成许多相对独立的业务场景，在一个个场景中进行领域分析和建模

问题子域

一个复杂系统的领域驱动设计，就是以子域为中心进行领域建模，绘制出一张一张的领域模型设计，然后以此作为基础指导程序设计。这一张一张的领域模型设计，称为“限界上下文”（Context Bounds，CB）。

定义

限界上下文之间的关系

上下文地图

很好的实现了单一职责原则：每个限界上下文中实现的都是软件变化同一个原因的业务

运用限界上下文作为拆分微服务的原则，即一个限界上下文对应一个微服务。

限界上下文内的高内聚

限界上下文之间通过上下文地图调用时，通过接口进行调用。

限界上下文之间的低耦合

限界上下文

注意：领域应该是“过去式”，‘查询套餐’这种不属于DDD中的领域，DDD往往应用于系统增删改的业务场景中

产品经理引导下，与业务专家开始梳理当前的业务中有哪些领域事件

针对每一个领域事件，项目组成员围绕它进行业务分析，增加各种命令与事件，进而思考与之相关的资源、外部系统与时间

识别模型中可能存在的聚合及聚合根

事件风暴

从DDD开始需求分析、领域建模，逐渐建立起多个问题子域

将问题子域落实到限界上下文，他们之间的关联形成上下文地图

各子域落实到微服务中贫血模型或充血模型的设计，从而在微服务之间根据上下文地图形成接口

需求变更

“小而专”，即服务内高内聚，服务间低耦合

原则

拆分

微服务

DDD