DDD
1 数据字典
- 质量：当用户提出一个需求变更时，为了实现这个变更而修改软件成本越低，那么软件设计质量越高
- 策略模式：
- 优点：可动态改变对象的行为
- 缺点：客户端必须知道所有策略，并自行决定使用那一个策略；产生很多策略类
- 适配器模式：一个类的接口转换成客户希望的另一个类的接口，使原本不能在一起的类能在一起工作
- 面向对象的软件设计：
- 需求分析：用例模型设计，分析整个系统要实现的功能
- 领域模型：分析系统的业务实体，通过类属性表述数据结构，通过添加方法描述对数据结构的处理
- DDD：
- 从DDD开始需求分析，领域建模，琢渐建立起多个问题子域
- 将问题子域落实到限界上下文，它们之间的关联形成上下文地图
- 各子域落实到微服务中贫血模型或充血模型的设计 ，从而在微服务之间依据上下文地图开成接口
2 领域模型指导程序设计
- 服务：标识领域对象之外的操作与行为，职责 1接收用户请求 2执行某些操作
- 实体：唯一标识字段区分真实世界每一个个体的领域对象
- 值对象：真实世界中一成不变的，本质性的事物
- 充血模型：将领域模型原貌直接转换为程序领域对象的设计，业务操作不在“服务”中实现，而在领域对象中实现。
- 优点：
- 保持了领域模型原貌
- 保持了对象的封装性，在面临多态、继承等复杂结构时，易于变更
- 昂贵而优雅
- 缺点：
- 充血模型根据原貌直接映射，需要增加组件，对设计与架构能力提出更高的要求
- 充血模型需要更强的设计与协作能力
- 能力：（ OOA/D（面向对象分析/设计） 能力、分析业务、业务建模与设计能力）
- 协作：
- 应对复杂的业务处理场景
- 贫血模型：业务逻辑在service层实现
- 优点：简单易行，不需要仓库不需要工厂，不需要缓存
- 更容易应对复杂业务处理场景
- 比较：取长补短，合理利用
- 继承、多态情况：将继承与多态的部分以充血模型形式在领域对象中实现
- 类型、编码的转换部分封装在领域对象中
- 希望更好的表现领域对象之间的关系
- 聚合：真实世界中代表整体与部分的事物，重要组件：仓库与工厂。可按照充血模型进行设计
- 聚合根：外部访问的唯一入口，聚合内部逻辑变更，只需要内部进行更新，降低变更维护成本
- 问题域：真实世界的业务与问题
- 业务领域知识：业务规则与知识
- 问题子域：将整个系统划分成许多相对独立的业务场景
- 限界上下文：以子域为中心的领域建模，绘制出的领域模型设计。
- 上下文地图：
- 限界上下文内的高内聚：每个限界上下文内实现的功能，都是软件变化的同一个原因的代码
- 微服务如何拆分：每个限界上下文对应一个微服务
- 领域事件：已经发生并且需要保存的重要事实
- 需要分析触发的命令，与之相关的人与事，以及发生的时间