当前位置：首页 > news >正文

领域驱动设计 2

news 2025/12/31 15:17:28

1.幂等设计

1.1.定义

无论进行多少次相同的操作，结果都保持一致的设计。

1.2.写操作的幂等性

1.2.1.Insert

指定唯一标识写，是具有幂等性的。
不指定唯一标识写，不具备幂等性。

1.2.2.Update

如果更新操作依赖于与历史状态，则不是幂等的，反之则幂等。
例：

//无论执行多少次 count的值都为1
Update test_table set count = 1 where id = 1;
//count的最终值，取决于执行次数，所以是非幂等的
Update test_table set count = count+1 where id = 1;

1.2.3.Delete

删除操作天然幂等，因为删除之后数据就没了，再删一次，数据仍旧没了。

1.3.幂等性设计

1.3.1.唯一索引

通过给每一个操作一个requestId，并将其记录到操作记录表中，保证操作只会执行一次。如：某个操作的requestId为1，当其执行完了，则将其插入操作记录表中。当再次执行该操作时，其requestId在操作记录表中已经存在，则不应再执行该操作。流程如下：
在这里插入图片描述

1.3.2.有限状态机

有限状态机（简称状态机），表示有限个状态以及在这些状态之间的转移和动作等行为的模型。
在这里插入图片描述

2.领域事件

领域事件是聚合内已经发生的事实，代表聚合内已经发生了业务操作或状态变化。领域事件通常由聚合根产生，且因该是值对象或贫血对象。
领域事件可解耦领域对象之间的耦合度，通过发布事件通知其他对象自身发生了某个事件，代替直接调用。可实现夸聚合的数据一致性。

3.领域事件发布

例子：

public class ApplicationSevice{@AutoWiredDoMainService dms；@AutoWiredDoMainEventPublisher publisher；public void handleSomeThing(SomeCommand command){//领域服务完成某项业务,并返回领域事件List<DomainEvent> eventList = dms.doSomeThing(command);//推送领域事件publisher.publish(eventList);}
}

在上述例子中，领域服务执行完事务后，如果推送领域时间这一步执行失败，会导致完整的业务流程没有执行成功。
为了解决这个问题，可以将领域事件持久化并可靠地发布事件。

3.1.领域事件持久化

例：

public class DomainRepository{@ResourceEventRepository eventRepository;@ResourceDataRepository dataRepository;@Transactionalpublic void save(Entity entity){//获取领域事件List<DomainEvent> events = entity.getEvents();//将领域事件转换为持久化存储事件List<Event> eventList = events.stream().map(s->{......}).collect(Collectors.toList());//持久化领域事件eventRepository.saveAll(eventList);//将实体转换为是数据库对应的数据模型DataModel d = toDataModel(entity);//持久化数据模型dataRepository.save(DataModel);}
}

3.2.可靠发布领域事件

3.2.1.直接发布并补偿机制

在这里插入图片描述

1）领域服务在实现具体的业务时，应持久化保存领域事件，并将领域事件的状态设置为未完成发布。
2）当应用层调用领域服务完成业务逻辑处理之后，将领域服务返回的事件直接发布。
3）事件发布成功后，将数据库中事件状态更新为发布成功。
4）定时任务定时扫描最近一段时间范围内的状态为未发布成功的领域事件，并将这些事件进行发布，发布成功之后，修改其状态为发布成功。

3.2.2.事物日志拖尾

频繁地轮训数据库可能会对数据库造成压力。此时可以考虑采用事务日志拖尾的方案。事务日志拖尾，指监听数据库的事务日志，以获取增量的新数据，可通过CDC中间件来实现。常见的CDC中间件包括Debezium、Canal、Flink CDC等。
在这里插入图片描述

1)领域服务执行完业务逻辑之后，持久化存储领域事件。
2)CDC中间件通过监听事务日志，读取到增量的新数据。CDC中间件从数据中解析出事件，发布到消息队列中。

4.领域事件订阅

领域事件订阅需要考虑幂等性设计。事件的发布和订阅可通过消息中间件kafka实现。

5.CQRS的概念

CQRS(Command Query Responsibility Segregation）命令查询职责分离架构模式。通过不同的模型实现Command（数据修改）与Query（数据查询）分离。

6.为什么要引入CQRS？

聚合根事是务一致性的边界。开发者在处理业务时为了保证业务的准确性，需要完整的加载整个聚合根。而Query操作不一定需要完整的聚合根，可能只需要聚合根的一部分状态，且不会对状态进行修改，此时将完整的聚合根加载到内存中，可能因为读取的数据过多影响性能。所以需要将Query操作与Command操作分离开来。
在领域驱动设计的架构中，可以直接在应用层调用基础设施层服务进行查询并返回查询条件，而不用调用领域模型进行查询。

7.CQRS实现方式

7.1.方法级

一个方法要么执行Command，要么执行Query，不应在Command方法中返回View对象。

7.2.相同数据源CQRS

在这里插入图片描述
Command操作处于DDD应用中，Query操作处于三层贫血应用中。

7.3.异构数据源CQRS

数据的Command操作和Query操作可能使用不同的数据源。此时Command的应用仍采用DDD模型，Query操作可采用三层贫血模型。但两个数据源之间应存在同步机制，保证数据的一致性。可通过事件发布+补偿机制或者事务日志拖尾的形式实现。