DDD中仓储操作多表获取或持久化领域模型时如何处理数据库事务

问题I 解答 #

• 针对仓储操作多表构造聚合的场景，查询侧不需要单独开启事务，只要使用支持快照读的数据库（如InnoDB的RR隔离级别），单连接下的多次查询天然可以拿到一致性快照，无需显式声明事务。若数据库隔离级别较低，可在仓储的查询方法内部开启只读事务保证多表查询的一致性，该逻辑不需要暴露给上层。
• 新增/更新聚合的场景同理：聚合本身是一致性边界，持久化整个Order聚合（涉及Order和OrderLines两张表）时，仓储内部可以自行处理事务，保证两张表的写入要么全部成功要么全部失败，完全符合仓储的封装原则——上层不需要感知聚合存储对应一张还是多张表。

问题II 解答 #

• 聚合内部的持久化一致性保障确实属于基础设施层的职责，应用服务仅需要管控跨聚合的业务事务一致性。举例来说：实现「订单支付+扣减库存」逻辑时，涉及Order和Inventory两个聚合，此时事务才需要在应用服务层开启，将两个仓储的操作纳入同一个事务。而单个聚合持久化需要操作多少张表、如何保证一致性，属于仓储自身的实现细节，应用服务无需关心。
• 可以将仓储接口设计为事务感知：若上层传入事务对象，仓储直接复用外部事务；若未传入，仓储自行开启内部事务保证单个聚合的操作一致性，即可同时覆盖两类场景。

问题III 解答 #

• 上述场景完全属于技术事务范畴。业务事务对应用户可见的完整业务操作（比如提交订单动作，可能包含多个聚合操作、甚至跨系统调用），而技术事务是为了保障数据库层面操作的原子性、一致性的技术手段。单个聚合内部多表操作的一致性保障，仅属于数据库层面的技术实现要求，不涉及业务逻辑，因此归为技术事务。

补充疑问解答 #

针对应用层自主选择是否开启事务时，仓储多表操作的一致性保障问题，可通过双层事务支持的实现方案解决：

1. 所有仓储公共方法新增可选事务入参，当入参为空（VB.Net中为Nothing）时，仓储自行开启本地事务完成当前聚合的读写操作，保障一致性；
2. 若应用服务需要操作多个聚合，自行提前开启事务，再将事务对象传入所有需要调用的仓储方法，所有仓储操作均加入该外层事务，由应用服务最终统一提交/回滚。

该实现方式既保证了单个聚合的一致性封装，又保留了应用层控制跨聚合事务的灵活性，是DDD实践中非常通用的处理方案。

内容的提问来源于stack exchange，提问作者Jaime