面向领域驱动设计（DDD）的并发更新问题解决方案探索

我们的开发团队正在探索有效模式，解决并发更新可能引发的数据不一致问题，同时遵循领域驱动设计（DDD）原则，在代码中集成不变量检查。

典型并发冲突场景 #

为说明这类挑战，以下是几个实际场景示例：

示例1：唯一用户名要求 #

• 问题：两名用户同时尝试注册相同用户名
• 结果：两次用户名唯一性校验查询均返回“可用”，最终系统中出现两个相同用户名的用户

示例2：批处理作业执行约束 #

• 问题：两名用户同时启动同一批处理作业，违反“仅允许一个实例运行”的规则
• 结果：两个作业实例同时启动，与预期的单实例执行逻辑不符

示例3：购物车预算限制 #

• 问题：用户利用并发操作同时添加两件商品，触发竞态条件
• 结果：两次添加操作均通过校验，最终购物车总金额超出预算上限

已调研的潜在解决方案模式 #

经过研究，我们梳理出以下几种可行的解决方案模式：

1. Database Unique Constraint（数据库唯一约束）

   • 优势：可直接解决示例1的用户名重复问题
   • 劣势：无法覆盖示例2和示例3的场景

2. DDD聚合根技术

   • 优势：通过聚合根定义新的事务边界，强化领域规则的一致性
   • 劣势：不是示例1的直接解决方案；对示例2、3的解决效果因场景而异

3. Cluster-Aware Command Handler（集群感知命令处理器）

   • 优势：对命令进行全局顺序化处理，理论上可解决所有三个场景的问题
   • 劣势：会显著增加系统架构复杂度

4. Lock Table（锁表）

   • 优势：可解决示例2的批处理作业并发启动问题
   • 劣势：增加系统实现复杂度；无法覆盖所有场景

5. Database Locks（悲观锁）

   • 优势：可作为示例2的解决方案
   • 劣势：实现难度较高，容易引发性能问题或死锁

6. No Action（权衡决策）

   • 优势：基于实现成本、并发问题发生概率及影响范围做权衡，快速落地业务
   • 劣势：需承担一定的并发冲突风险

7. 方案6扩展：重复数据检测与质量报告

   • 优势：提供事后监控手段，及时发现并发导致的数据问题
   • 劣势：属于响应式方案，无法提前预防冲突

向社区请教的问题 #

我们希望向社区同仁请教以下问题：

• 是否存在其他可应对并发更新挑战的模式？
• 有没有知名的模式目录，能系统解释这些模式的适用场景、优缺点？
• 能否提供基于Java、JPA和/或Spring Data的上述模式代码示例？

感谢您的见解与协助！

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