DDD架构及相关概念
2025-03-21 22:18:27 6
贫血模型和充血模型
贫血模型只有属性
public class RoleId {
private Long value;
}充血模型有属性也有行为(方法)
public class RoleId {
private final Long value;
public void print() {
System.out.println("getValue:" + value);
}
}贫血三层模型
Controller + Service (处理业务逻辑并调用DAO接口操作数据库) + DAO (包括贫血Model)
DDD经典四层架构
用户接口层
仅将应用层的方法向外暴露
应用层
协调领域模型和基础设施层完成完整业务逻辑
领域层
充血模型 实现具体业务逻辑
领域模型的查询和保存接口定义在领域层, 具体实现在基础设施层
基础设施层
操作db/cache/mq等基础设施
实体和值对象
实体
领域模型, 具有唯一标识
值对象
也是领域模型, 没有唯一标识
聚合和聚合根
聚合
领域模型的对象不会孤立的存在, 往往存在引用关系, 形成一颗对象树. 聚合内的对象是强一致的.
聚合根
这颗对象树的根, 聚合根必定是实体
领域服务
领域服务是领域模型的一种表现形式, 是领域模型的一部分
领域服务是无状态的
当领域中的操作涉及到多个聚合根, 或者不是实体和值对象的自然职责时, 应该定义一个独立的接口
比如导出用户列表的操作, 涉及到多个聚合根
不应该滥用领域服务, 否则将回到贫血模型0
防腐层
用于隔离外部上下文
比如领域模型中调用了第三方接口, 哪天第三方接口的方法签名/入参/出参都发生了改变, 那么该领域模型也需要进行改变.
领域事件
领域事件是聚合中已发生的事实, 代表聚合内以及发生的业务操作和状态变化
如果需要强一致性的事件通知, 可以把发布事件处理事件的逻辑抽出来做成领域服务, 而不是在聚合内处理
CQRS
Command Query Responsibility Segregation 命令和查询责任分离
通过使用不同的模型, 分别实现修改操作, 与查询操作, 达到命令和查询分离的目的
在ddd中的, 应用层根据职责被分为两部分: 命令应用服务和查询应用服务
查询操作可以绕过领域模型
事件溯源
是一种将所有的领域事件存储到事件存储中, 并通过重放历史事件来还原领域对象状态的模式
在一些数据变更非常重要的业务场景，如财务、金融领域，可能会使用这种数据持久化方式
可以用拉链法处理事件溯源
事件风暴
事件风暴建模方法: 通过收集所有相关方关注的领域事件, 逐步提取出状态变更的场景/对应的角色/操作, 以提取出对应的聚合, 再划分出限界上下文, 完成建模
ddd实战小项目
