DDD概念

问题空间
定义:真实世界
利用核心子领域、通用子领域、支撑子领域来分解问题空间
问题空间:价值需求+业务需求(业务功能、业务实现)
6w模型
业务价值
who(利益相关者)
why(业务愿景,业务价值)
where(业务范围)
业务需求
when(业务流程)
what(业务功能)
how(业务实现)
如何进行业务需求分析?
1.用例分析
用例是有层次的,不同粒度的用例体现了不同的业务价值
2.用户故事(invest原则)
invest原则
1.independent:独立的
2.negotiable: 可协商的
3.valuable:有价值的
4.estimable:可估算的
5.small:小的
6.Testtable:可测试的
3.业务服务
4.prd文档
业务服务
编号(标记业务服务的唯一编号)+名称(动词短语)+描述(角色+服务功能+服务价值)+触发事件(触发该业务服务的具体事件)+基本流程+基本流程+替代流程+验收标准(业务规则)
业务服务对标6w模型
why: 业务价值
what:业务功能
how:业务实现
who:角色
when:服务间的协作
where:限界上下文

解空间
定义:使用软件世界构建的解空间
围绕着领域这一核心开展业务系统的战略设计与战术设计

同构系统
定义:两个复杂结构可以相互映射,每个结构的每一部分在另一个结构都有一个相应的部分
分类
1.概念层次的同构系统
2.设计层次的同构系统
3.管理层次的同构系统

系统上下文
定义:定义目标系统解空间的边界,边界范围外的系统是伴生系统

限界上下文
定义:是知识语境的界定,是业务能力的纵向切分。
将领域知识封装成了领域对象,每个领域对象扮演了不同的角色,执行不同活动,共同对外公开内聚的业务能力
不同领域模型在不同语境下扮演不同的角色,执行不同的业务活动,提供完整的业务能力
限界上下文的四个特征
1.最小完备(完整性)
限界上下文需要的必备的领域知识,必须分配给它、
2.自我履行
基于边界内基础设施的基础,输出完整的业务能力
3.稳定空间
隔离外界变化对内部领域层的影响(解决:引入抽象)
4.独立进化
变化:领域模型的修改和更新
避免内部的变化影响外边(封装)
边界上下文的注意事项
1.跨BC(boundary content: 边界上下文)共用使用一个相同的领域概念(领域概念对应一个对象),但只使用了部分属性,各自BC关系的属性应放在各自的数据库中我,ID需要保持一致
业务流程 --》业务场景 ---》业务服务 --》业务主体 --》限界上下文
限界上下文的识别
1.正交原则
定义:多个事务中一个发生变化,不会影响到其他事务,那么这些事务就是正交的

上下文映射
上下文映射模式
1.通信集成模式
防腐层:ACL(anti corruption layer), 下游对抗上游的变化
开放主机服务: OHS(open host service), 上游给下游的不变承诺
发布语言: PL(published language), 两个限界上下文之间的模型转换的公共语言(消息契约模型)
共享内核:暴露领域模型
2.团队协作模式
尊奉者模式:对上游模型具有强依赖性

消息契约--》消息数据
定义:是服务契约向客户端传递的消息数据
服务契约:基于OpenAPI规范的微服务接口描述,是微服务运行和治理的基础
消息契约的类型
1.请求消息
2.响应消息
3.事件消息
消息契约定义于外部网关层
领域事件:领域模型发布的事件,用于聚合之间的协作
应用事件:应用服务发布的事件,穿越限界上下文边界
事件的定义
1.减少对领域模型的依赖,保证中立性
2.事件的内容主要包含聚合id+事件属性的最小集
3.支持版本管理
4.有事件id,有创建时间戳
5.事件是不变对象

六边形架构(端口与适配器)
ui层 --》业务逻辑层 --》数据层(部分业务逻辑层依赖UI层,所有业务逻辑依赖数据层)

系统分层架构

领域模型的设计实现
领域模型的特征
1.运用统一语言来表达概念
2.领域业务知识
3.对领域业务知识进行提炼和抽象

统一语言
DTO: 消息契约对象(贫血模型)
VO:视图对象,为ui提供数据,是消息契约模型中的一种
BO: 业务对象,在业务逻辑层封装业务逻辑
DO:领域对象,领域层的业务对象(领域模型对象、领域服务)
PO: 持久化对象
DAO:数据访问对象
领域模型对象:实体、值对象、领域服务、领域事件
领域模型必须是富领域模型
远程服务、应用服务接口返回参数和返回值遵循DTO的消息契约模型
实体、值对象为持久化对象PO
模型驱动设计

你可能感兴趣的:(DDD概念)