DDD领域驱动设计方法论
2021-10-31 23:43:17 71 举报AI智能生成
登录查看完整内容
DDD领域驱动设计方法论；
作者其他创作
大纲/内容
DDD 到底是银弹还是垃圾
推荐文章
被界限在指定的也无需求之中
有清楚的范围边界
问题域
本质
与传统开发过程的区别在于DDD注重领域建模
区别
业务系统核心价值所在
核心域
子域
支撑子域
通用子域
分级
领域 Domain
简单易学
使用率高
国际通用
三个特点
通过团队交流达成共识的能够准确传递业务规则的简单语言
概念
解决了交流障碍问题，使领域专家和开发人员协同合作
价值
统一语言（通用语言）
一个界限，某个具体的范围
限界
语境
上下文
在销售子域和商品子域中就是商品
在物流子域中特指货物，只关注部分属性
商品
例子
领域名+上下文
命名
限界上下文 bounded context
划分领域
描述正在解决的问题及提出的解决方案
综合了系统分析和设计
语言、模型、代码三者紧密绑定
可以通过UML类图来展示
特征
领域模型
防腐层：Anti-Corruption-Layer
值对象=值+对象 => 将一个值用对象的方式进行表述，表达一个具体的固定不变的概念
表示一个具体的概念
通过值的属性对其识别
属性判等
固定不变
值的特征
购物网站的客户收货地址信息
案例
符合通用语言，更简单明了的表达简单业务概念
值对象不会孤立存在，可作为所属实体的数据列
多个值对象序可以列化到单个列
简化设计，减少不必要的数据库表设计
作用
结合通用语言的表述检查其是否具有值得的含义和特征
建模
值对象
实体=唯一身份标识 + 可变性【状态（属性） + 行为（方法或领域事件或领域服务）】
为了迎合ORM而创建，和领域实体标识无关系
委派标识
eg.支付宝交易流水号
基于领域实体概念分析确定的唯一身份标识
领域标识
即时生成
延迟生成
生成时机
唯一标识
eg.订单状态：未支付、正常、已发货、关闭
实体的状态
eg.订单行为：支付、发货、关闭
实体的行为
可变性
实体
eg.车和轮胎=>可以独立存在
UML类图概念，整体与部分的关系
来源
封装业务
保证聚合内领域对象的数据一致性
事务粒度的 entity，领域对象的显示分组
DDD中的概念
基于业务用例而非现实生活建立必要关联
减少不必要的关联
将双向关联转换为单项关联
领域对象间的关联关系
领域内需要关注的业务规则
领域不变性
关键
聚合内实现事务一致性
聚合外实现最终一致性
一致性的维护
难点
无法一口吃个胖子
持续改进聚合的设计
一个持续性的活动
设计
聚合根
对领域模型进行分解的产物，相对独立的功能单元
由一系列高内聚的领域对象组成
抽象
根据领域来组织模块
模块命名规范
基于通用语言
模块内高内聚
模块间低耦合
高内聚低耦合
通过命名空间进行分离
使用单独项目进行分离
实现
模块
隐藏对象的复杂创建逻辑
表达对象实例化的意图
目标
简单工厂
工厂方法
抽象工厂
反射工厂
将领域对象的使用和创建分离
隐藏创建复杂领域对象的业务逻辑
根据调用者的需要创建相应的领域对象
封装聚合的内部状态
好处
工厂
存储集合
删除集合
一个聚合的集合
特性
通过聚合根来持久化和检索领域对象
隐藏聚合持久化和检索的底层技术实现
定义数据模型与领域模型的边界
要点
仓储使用ORM持久化领域对象的状态
ORM
映射
领域模型与持久化存储之间的明确契约
定义
简化代码
明确意图
泛型仓储
UnitOfWork (UOW)
事务管理
仓储 Repo Pattern
六边形架构
eg.\"订单支付成功\"=>一个领域事件
捕获领域中发生的具有业务价值的一些事情
基本概念
封装不变，应对万变
核心
事件源
事件处理
事件总线 (EventBus)
发布-订阅模式
建模领域事件
订单系统发布\"订单成功支付\"事件
库存系统订阅并处理库存扣减逻辑
通知系统订阅并处理拣货通知
事件发布可用于重新发布
通过消息中间件去分发事件
事件溯源
事件存储
用于恢复到某个状态
最终一致性
领域事件
eg.购物车结算=>应用行为
表述应用行为
隐藏领域层的复杂性及其内部实现
应用服务
eg.金额计算、支付、生成订单=>领域行为
表述领域行为
领域服务
应用服务&领域服务
战略设计|战术设计
0 条评论
回复 删除
下一页
