解构领域驱动设计
2022-09-21 16:11:02 32 举报AI智能生成
张逸老师绘制的《解构领域驱动设计》的思维导图
作者其他创作
大纲/内容
全局分析阶段
价值需求
利益相关者(who)
受益者：受益的利益相关者
支持者：解决问题的利益相关者
系统愿景(why)
系统范围(where)
当前状态
未来状态
业务需求
业务流程(when)
区别线上流程和线下流程
不要受到当前业务流程的影响----对流程的优化
注意识别可自动化的环节
要使用上帝视角
业务场景(what)
业务服务
组成要素
角色
用户
策略
伴生系统
目标系统作为黑盒子
服务请求
服务价值
业务服务规约
名称（动词短语）
描述：作为（角色） 我想要（服务功能） 以便于（服务价值）
触发事件：可用于判断是业务服务，还是执行步骤
基本流程（成功场景）：流程的第一步一定是BC收到了服务请求后执行的第一步
替代流程（失败场景）
验收标准：包含了领域规则
子领域
核心子领域
通用子领域
支撑子领域
领域建模阶段
领域分析建模
参与人
领域专家(主导)
开发团队
输入
业务服务规约
输出
领域分析模型
快速建模法
1. 名词建模
识别业务服务规约中表达领域概念的名词
2. 动词建模
识别业务服务规约中基本流程中的动词
1. 确定领域行为
2. 判断该领域行为是否产生过程数据(凭证)
时标型对象
什么事(what)
什么时间发生(when)
有没有留存的价值(why)
3. 将该过程数据表达的领域概念放入领域分析模型
3. 归纳抽象
遵循统一语言原则，对相似的领域概念给出清晰定义，确定是否相同含义；或者是否可以进一步归纳
4. 确定关系
确定领域概念之间的关系，重点关注多对多与一对多，关系也可能是一个领域概念
5. 分配限界上下文
根据领域知识的相关性，并明确知识语境的边界，将领域分析模型的各个领域概念分配到各个限界上下文
领域设计建模
输入
领域分析模型
业务服务规约的基本流程
输出
静态的领域设计模型：由聚合组成的类图
动态的领域设计模型：序列图脚本或序列图
模式
实体
体现了领域概念，具有ID
值对象
体现了领域概念，只关注值
聚合
聚合的定义
聚合是边界，边界内为实体与值对象组成的对象树，根为实体
聚合用于维护领域概念的完整性
聚合之间只能通过聚合根实体建立关系
根实体是聚合唯一的入口和出口
聚合的自治特征
向心力
不变量
对聚合内各个领域概念之间关系的一种约束
完整性
约束概念关系的一种特殊不变量
一致性
约束数据关系的一种特殊不变量
离心力
独立性
如果某个实体具有独立管理生命周期的需求，则独立为单独的聚合
领域服务
管理多个聚合之间的协作
管理聚合与端口之间的协作
封装无状态的领域行为
分离独立变化的领域行为
领域事件
封装状态的变化
资源库
负责聚合生命周期的管理：添加、加载、变更、移除
工厂
负责聚合生命周期的管理：从无到有的创建
设计聚合
1. 梳理对象图：梳理领域分析模型，分辨实体和值对象
相等性：判断值相等为值对象，判断ID相等为实体
不变性：属性值可以修改为实体，若修改时创建一个新对象，则为值对象
独立性：若需要单独管理生命周期，则为实体
优先级：无法判断时，优先建模为值对象
2. 分解关系薄弱处
根据实体关系耦合强度划分聚合
1. 泛化(Generalization)：耦合强度为5
2. 合成(Composition)：耦合强度为4
3. 聚合(Aggregation)：耦合强度为3
4. 关联(Association)：耦合强度为2
5. 依赖(Dependency)：耦合强度为1
3. 调整聚合边界
根据聚合的自治特性调整聚合边界
服务驱动设计
角色构造型
结合菱形对称架构：远程服务、本地服务(应用服务)、领域服务、聚合、端口
服务驱动设计过程
1. 分解任务
0. 形成任务树，业务服务为任务树的根，组合任务为枝，原子任务为叶
1. 流程转任务：将业务服务规约中的基本流程转换为任务
2. 向上归纳：将不可分割的相邻任务归纳为更高的组合任务
3. 向下分解：判断目前未分解的任务是否是原子任务，如果不是，则继续分解
1. 如果当前任务需要的领域知识是一个聚合拥有的，则识别为原子任务
2. 如果当前任务访问了外部资源，则识别为原子任务
2. 分配职责
1. 业务服务分配给远程服务与应用服务
2. 组合任务分配给领域服务
3a. 如果没有访问外部资源，原子任务分配给聚合
3b. 否则分配给端口
领域实现建模
输入
领域设计模型
业务服务规约的验收标准
输出
领域实现模型
领域层的产品代码
领域层的测试代码
菱形对称架构与测试金字塔
聚合的单元测试
领域服务的单元测试(mock端口)
应用服务的集成测试
远程服务的契约测试
服务驱动设计与测试驱动开发
服务驱动设计的方向是由外向内
测试驱动开发的方向是由内向外
服务驱动设计输出的序列图脚本可以作为测试驱动开发的输入
测试驱动开发
流程
红：编写一个测试，测试失败
绿：为测试提供实现，让测试刚好通过
黄：识别产品代码和测试代码是否有坏味道，如果有，重构
简单设计
通过所有的测试：可测试性
尽可能消除重复：可重用性
尽可能清晰表达：可读性
更少代码元素：简单性
三定律
在编写不能通过的单元测试前，不可编写生产代码
只可编写刚好无法通过的单元测试，不能编译也算不通过
只可编写刚好足以通过当前失败测试的生产代码
架构映射阶段
系统上下文
系统分层架构
1. 基础层(对应通用或支撑限界上下文)
2. 业务价值层(对应核心限界上下文)
3. 边缘层(可选)
API网关
UI适配
服务聚合
4. 客户端层
限界上下文
六要素
领域知识
领域对象
知识语境
角色
活动
业务能力
两本质
领域模型的知识语境
业务能力的纵向切分
四特征
最小完备
自我履行
稳定空间
独立进化
菱形对称架构
内外分离
领域层(内)
网关层(外)
南北对称
南向网关
端口
Repository(面向数据库)
Client(面向上游限界上下文或伴生系统)
Publisher(面向事件总线)
适配器
消息契约(针对Client端口)
北向网关
远程服务
Resource(RESTful服务)
Controller(面向UI)
Provider(RPC)
Subscriber(面向事件总线)
本地服务
消息契约
识别限界上下文
业务维度
1. 根据业务相关性(语义相关性、功能相关性)对业务服务进行归类
2. 对归类的业务服务提炼其共同特征，归纳为业务主体
3. 调整业务主体的边界
根据亲密度调整业务服务
根据限界上下文的本质调整业务服务
4. 根据验证原则进一步验证限界上下文
单一抽象层次原则
奥卡姆剃刀原则
正交原则
最小惊讶原则
团队维度
领域特性团队
康威定律
两个披萨法则
特性团队
技术维度
根据质量属性如高并发、性能、安全等因素，要求资源隔离，从而独立定义限界上下文
上下文映射
模式
通信协作模式
防腐层(菱形对称架构的南向网关)
开放主机服务(菱形对称架构的北向网关)
发布语言(菱形对称架构的消息契约)
共享内核(去掉网关层)
团队协作模式
合作伙伴(反模式)
遵奉者(反模式)
分离关系(NO)
客户方供应方(CS)
发布者订阅者(PS)
服务序列图
确定限界上下文的上下文映射模式
驱动出限界上下文的服务契约
领域驱动架构风格
以领域为核心驱动力
以业务能力为核心关注点
系统上下文层次：系统分层架构模式
限界上下文层次：菱形对称架构模式
0 条评论
下一页
