问题空间
定义：真实世界
利用核心子领域、通用子领域、支撑子领域来分解问题空间
问题空间：价值需求+业务需求（业务功能、业务实现）
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
模型驱动设计
网友评论