域驱动设计中共享资源的竞争条件

Question

问题描述

我试图按照领域驱动设计来实现应用程序，

对于这个问题，让我们假设我们有一个负责管理某些事件的保留的简单域。

每个活动都有参与者的限制，因此系统不应该允许过多的预订。

提出保留的程序如下：

1. 从存储库加载事件聚合。
2. 检查事件是否已满，如果是，则停止。
3. 为某一活动预订
4. 将事件保存在存储库中。

我的问题是如何解决以下竞赛条件：

很多使用者可能希望同时订位，所以我们可能会有两次并行的执行，在同一时间内载入事件集，两者都会看到该事件仍然有一个空位，而作出的预约可能会导致订位过多。

这是一个经典的并发问题，但我正在寻找一种在DDD世界中工作的方法。

我尝试过什么想法：

使用并发控制的数据库机制

该过程可以包装在数据库事务中，并用于检测在同一事件上发生的两次写入。然后，一个事务将失败，我们可以重试这个用户的过程。

我认为它不适合DDD，因为域层应该知道数据库事务，据我理解，应该避免数据库事务，所有与数据库相关的活动都应该在基础结构层(存储库)中占有一席之地。

应用层并发控制

可以在应用层上实现一些并发控制，例如锁定机制，以便对给定事件只执行一次过程。

这听起来更好，因为我们并不基于处理逻辑的数据库实现，而且我们的逻辑模型仍然很清楚。

困扰我的是，我们可能很少有机器来处理这样的程序，然后我们需要有一些共同的锁定机制来处理这种情况。

也许还有一种不同的方法来解决这种情况？我愿意接受任何建议。

Answer 1

我认为它不适合DDD，因为域层应该知道数据库事务，据我理解，应该避免数据库事务，所有与数据库相关的活动都应该在基础结构层(存储库)中占有一席之地。

我不知道为什么您认为在DB级别上执行的悲观锁定需要域污染？事务通常在应用层中管理(可能通过工作单位)，因此您可以很容易地应用一个事务隔离级别来序列化所有事务。

您还可以使用乐观并发(与重试)，或者对大多数ORMs支持的版本或完整数据进行比较。

您可能必须在模型中引入一个version属性(轻微的基础设施污染)，以支持基于版本的乐观并发，但是这种泄漏可以隐藏在层超型中。