领域驱动设计知识框架笔记
2022-10-27 10:12:08 0 举报AI智能生成
登录查看完整内容
领域驱动设计知识框架笔记
作者其他创作
大纲/内容
从业务中提炼出统一语言基于统一语言建立领域模型基于领域模型进行程序设计和编码实现通过重构发现隐式概念，运行设计模式改进设计和开发质量
设计地图
限界上下文
上下文映射
分解问题域
识别核心领域与子领域
确定领域边界及关系
问题域发掘
分层架构
隔离关注点
六边形架构
表达领域与技术基础设施边界
CQRS模式
分离查询和命令场景
架构设计
战略设计阶段
问题域内部的复杂性
解决对象
值对象（Value Object)实体 （Entity)领域服务 （Domain Service)领域事件 （Domain Event)资源库 (Repository)工厂 （Factory)聚合 （Aggregate)应用服务 （Application Service)
实体
值对象
领域服务
领域事件
领域模型对象
可以封装为一或多个实体与值对象
至少包含一个实体
只有实体才能作为聚合根
聚合
边界
负责领域对象的创建
工厂
数据库
内存
其他Web资源
从资源存放位置增删该查领域对象
不应暴露访问领域对象的技术实现细节
资源库
生命周期管理
要素分类
要素
解决方法：分治
战术设计阶段
设计步骤
设计过程
演进过程
演进足迹
从分层到领域驱动架构
需求变化
复杂度来源
安全
高性能
高并发
高可用等
质量属性
技术复杂度
业务扩张
业务复杂度
分支主题
复杂度分类
问题域过于庞大而复杂
表现
分治，控制规模
对策
规模
业务复杂度和技术复杂度混淆
保持结构的清晰与一致
结构
无法控制业务和技术复杂度
拥抱变化
变化
复杂度表现与对策
总旨：隔离业务复杂度和技术复杂度
拆业务：将一个庞大的软件系统切分为松耦合的多个小系统
用户角色
Who
业务功能
What
业务价值
Why
场景的边界
Where
When
如何实现业务价值
hoW
要争取领域专家知识输入的机会
用例的关注点就是领域
用例表达的领域概念必须使用统一语言
用例提取
As a 角色I would like 活动so that 业务价值
模板
支持对产品功能的细分，经常引出其他角色需要及相关活动的环境
角色
表述相关角色所需的系统需求
活动
传达为什么要进行相关活动，进场可以引领团队寻找能够提供相同价值且更少工作量的替代活动
价值
可测试，可验收
要求
来自于行为驱动开发
使用DSL编写用户故事
优秀实践
用户故事
先进性任务单元分解
来自意图导向编程
站在调用者角度去思考
被测试对象的创建，及它与其他对象的写作
Given
被测接口的方法明明及传入参数
命令式
查询式
考虑行为方式
分析被测接口的返回值
Then
Given-When-Then
遵循模式
测试驱动开发
分析方法
统一语言
分析基础
领域场景识别
垂直切割
隔离业务与技术：对小系统进行领域治理
示例
业务逻辑
领域层 （Domain Layer)
业务逻辑依赖的技术实现
基础设施层 （Infrastructure Layer)
业务逻辑和技术实现的粘合剂，实现两者之间的协作
应用层 （Application Layer)
关注点分离
领域层
应用层
六边形内部
基础设施层
六边形外部
本质还是分层架构
如果把表示层换成其他实现，而与原来的实现有重复内容，则这部分内容就应该防灾业务逻辑层
关注点
外部可替换
自动测试
依赖倒置
内涵
工具
水平切割
切割
领域驱动设计对策实现
使命：复杂度解决
上下文是动态的业务流程被边界静态切分的产物
是业务上的分割出的一个自治单元
定义
保护和隔离上下文边界，避免业务目标的不单一而带来的混乱与概念的不一致
目的不在于如何划分，而在于如何控制边界
目的意义
不通的限界上下文需要的领域知识不同
同一限界上下具有业务相关性
知识
上下文中的对象到底扮演了什么角色
角色和角色在上下文中是如何协作的
上下文按照不同的关注点进行分离
边界根据耦合关系强弱来确定
越是关系最弱的地方，越是要划定边界
关键点
自治单元履行的职责是完整的，无需针对自己的信息求助别的单元
完备
避免将不必要的职责添加到该自治单元
最小
最小完备
自治单元自身决定要做什么
要履行的职责一定是在掌握知识范畴之内
自我履行
减少外界变化对限界上下文内部的影响
对修改是封闭的
对扩展是开放的
符合开放封闭原则(OCP)
稳定空间
减少限界上下文变化对外界的影响
独立进化
高内聚低耦合
特征
根据角色、业务活动和业务价值确定用例
通过用例精确业务场景
从业务活动中提取出统一语言（从统一语言表中选择)
通常格式为动宾格式
利用领域场景分析的用例分析方法剖析场景
主要看业务活动的宾语是否相同
语义相关性
从功能角度分析业务活动是否彼此关联或依赖
功能相关性
通过相关性提炼出初步(粗糙)的限界上下文
也可作为限界上下文识别的一种检验手段
为业务边界命名
不应看成一蹴而就的事情
在适当的时候对限界上下文进行重构
从业务边界识别限界上下文
从工作量和团队规模角度去拆分限界上下文
从工作边界识别限界上下文
从技术复用角度去拆分限界上下文
从应用边界识别限界上下文
识别
共享内核
客户方-供应方开发
遵奉者
分离方式
要精确识别到到底依赖的是什么，可不可以转换为其他合作方式
如果出现双向依赖，则应考虑是否可以放在同一上下文中
极容易出现双向依赖
合作方式
上下文团队合作模式
对付遗留系统时的首选模式
下游限界上下文对抗上游变化的利器
防腐层 (Anticorruption Layer)
上游服务用来吸引更多下游调用者的诱饵
用于承诺开放的服务不会轻易做出变化
用途
RPC (Protocol Buffer)
WebService
RESTFul
常用开放方法
开放主机服务 (Open Host Service)
能够将上下文之间的解耦做到更好
作用
开发运行再同一个JVM中的事件总线来负责事件的发布和订阅
采用Actor模式支持事件的发布和订阅
常用方法
通常用于异步非实时的业务场景
往往用于实践驱动架构或者CQRS架构模式中（Command Query Responsibility Segregation 命令查询职责分离）
适用范围
发布-订阅事件
映射集成模式
通信边界的不同直接影响架构
单体架构
进程内
通过数据库连接
数据库共享架构
通过协议和数据格式连接
零共享架构
进程间
边界分类
通信边界
上下文协作关系（映射）
限界上下文（Bounded Context）
提炼领域知识的产物
获取统一语言就是需求分析的过程，也是团队角色就系统目标、范围和具体功能达成一致的过程
在沟通需求时，团队中的每个人都应使用同一语言进行交流
意义
所有的领域术语必须输出一张领域术语表，给出明确的概念解释，这是领域沟通的基础
在维护领域术语表时，一定要给出对应的英文术语，否则可能影响代码实现
统一的领域术语: 对应属性
从领域的角度而非实现角度描述领域行为
若设计领域术语，必须遵循术语表的规范
强调动词的精确性，符合业务动作在该领域的合理性
要突出与领域行为有关的领域概念
领域行为是对业务过程的描述
体现了更加完成的业务需求及复杂的业务规则
在特定上下文中有角色触发的动作，并由此产生的业务流程和操作结果
明确前置条件
明确执行主语和宾语
明确执行结果
同时是一种契约
领域行为描述 ：对应方法
体现
领域知识
核心概念
对应应用层
限界上下文中所有的应用服务
目的是使调用者了解的知识越少越好，调变得约越简单越好
传统上的controller属于这一层
application
对应领域层
完全业务逻辑
domain
对应资源库，如果不复杂可以集成在domain中
是gateways中的一种
repositories
对应基础设施层
网关组件自身会参与到业务中，但只是对业务的支撑，提供了与业务逻辑无关的基础功能实现
gateways
对gateways中除persistence之外的抽象，包括访问数据库之外其他外部资源的抽象接口，以及访问第三方服务或其他限界上下文服务的抽象接口
interfaces与gateways从逻辑上来说可以为一对一的关系
interfaces
层级
图示
代码结构
领域驱动设计知识框架笔记
0 条评论
回复 删除
下一页
