DDD
2022-03-01 15:08:46 0 举报AI智能生成
DDD基础概念
作者其他创作
大纲/内容
how
如何进行软件设计
拿到需求的时候，先设计领域模型
如何应对软件退化
每次变更的时候，先回到领域模型，基于业务对领域模型进行变更，然后基于领域模型进行代码变更
区分服务、实体、值对象
服务
领域对象之外的操作与行为
接收用户请求
执行某些操作
实体
通过一个唯一标识字段来区分真实世界中的每一个个体的领域对象
值对象
代表的是真实世界中那些一成不变的、本质性的事物
业务领域模型转换为程序设计
贫血模型
业务逻辑在service中实现
充血模型
业务逻辑在领域对象中实现
继承、多态的部分在领域对象实现
类型或者编码的转换逻辑
希望更好的表现领域对象之间的关系
聚合---(订单明细和订单)
聚合、仓库、工厂
聚合
描述：体现整体与部分的关系
判断：如果整体不存在，部分是否存在。如果不存在，那么是聚合关系。反之，则不是。
聚合根
外部访问的唯一入口
好处：当聚合内部的业务逻辑发生变更时，只需要对内部逻辑进行更新，与外部程序无关，降低变更的维护成本，提高设计质量。
局限：领域驱动设计通常适用于增删改的业务操作，但不适用于分析统计。
指导：领域驱动设计通常适用于增删改的业务操作，但不适用于分析统计。在一个系统中，增删改的业务可以采用领域驱动的设计，但在非增删改的分析汇总场景中，则不必采用领域驱动的设计，直接 SQL 查询就好了，也就不必再遵循聚合的约束了。
设计实现：仓库与工厂
仓库
工厂
通过装配，创建领域对象
通过id装载一个订单
- 这时订单仓库会将这个任务交给订单工厂，订单工厂就会分别调用订单 DAO、订单明细 DAO 和用户 DAO 去进行查询；
- 然后将得到的订单对象、订单明细对象、用户对象进行装配，即将订单明细对象与用户对象，分别 set 到订单对象的“订单明细”与“用户”属性中；
- 最后，订单工厂将装配好的订单对象返回给订单仓库。
限界上下文
问题子域
将整个系统划分成许多相对独立的业务场景，在一个个场景中进行领域分析和建模
定义
一个复杂系统的领域驱动设计，就是以子域为中心进行领域建模，绘制出一张一张的领域模型设计，然后以此作为基础指导程序设计。这一张一张的领域模型设计，称为“限界上下文”（Context Bounds，CB）。
上下文地图
限界上下文之间的关系
很好的实现了单一职责原则：每个限界上下文中实现的都是软件变化同一个原因的业务
限界上下文内的高内聚
运用限界上下文作为拆分微服务的原则，即一个限界上下文对应一个微服务。
限界上下文之间的低耦合
限界上下文之间通过上下文地图调用时，通过接口进行调用。
需求变更
从DDD开始需求分析、领域建模，逐渐建立起多个问题子域
事件风暴
产品经理引导下，与业务专家开始梳理当前的业务中有哪些领域事件
注意：领域应该是“过去式”，‘查询套餐’这种不属于DDD中的领域，DDD往往应用于系统增删改的业务场景中
针对每一个领域事件，项目组成员围绕它进行业务分析，增加各种命令与事件，进而思考与之相关的资源、外部系统与时间
识别模型中可能存在的聚合及聚合根
将问题子域落实到限界上下文，他们之间的关联形成上下文地图
各子域落实到微服务中贫血模型或充血模型的设计，从而在微服务之间根据上下文地图形成接口
微服务
拆分
原则
“小而专”，即服务内高内聚，服务间低耦合
0 条评论
下一页
为你推荐
查看更多
