DP : Domain Primitive 可以理解为 原生业务模型
是一个在特定领域里,拥有精准定义的、可自我验证的、拥有行为的值对象
三个原则:
让隐性的概念显性化
让隐性的上下文显性化
封装多对象行为
可维护性:调整内容修改的难易度 依赖程度(看别人脸色) 自己办事 省事
可扩展性:新增方法的难易度 继承程度 省事
可测试性:测试的困难度 封装抽象程度 多个重复实列-抽象 省事
可阅读性:代码的清晰度 循迹程度 一眼就明白 省事
DO: Data Object 数据库对应模型
Entity:业务实体 最好使用DP 来说明 行为 数据验证都搞定
DTO:数据传输对象 就是代表参数数据
VO:Value Object 值对象 值不变 变了就是另一个对象
DRY: 不重复原则
开闭原则Open-Closed Principle(OCP)
胶水代码:不纯粹的参数使用本身服务,需要依赖别的服务或数据源处理一下参数才能使用
TC:测试案例程度
DCI:data context interactive
Repository:领域仓 单一职责 SRP
贫血领域模型:对象只有属性 就跟数据表一样
充血领域模型:对象拥有行为,状态
总结:
- DDD是一种指导思想,一种架构模式不是一个具体细节的东西
- DDD 核心需要 聚焦于业务 然后在业务通用语言中 进行 战略和战术
- 战略就是业务逻辑的掌握层面,战术就是 项目的搭建代码层面
- 战术一般采用 四层架构 六边形架构 来 高内聚低耦合
- 具体的搭建类库 就需要对业务 拆分的领域 进行相应的 聚合,根,实体创建 充血模型
- 领域服务 各个领域 限界上下文 确定之后 领域服务通过领域仓 Repository来进行业务综合管理 领域层 只关注业务的处理,数据交互以及数据库实现属于基础设置层的操作,从而达到 低耦合 弱依赖 可维护性高的效果
- DDD的思想 对于微服务的发展提供了有效思路 因此在03年提出 到很多年后才广泛受用