AggregateRoot A 验证需要来自 AggregateRoot B 的信息

Question

我是 DDD 领域的新手，我想知道如何处理我有一个聚合根 (AggregateRootA) 需要来自其他聚合根 (AggregareRootB) 的一些信息才能做某事的情况（例如更改 AggregateRootA 的状态）。

如果我尝试使用更真实的场景，这可能会更清楚......让我们考虑一个预订系统。在系统中，我们有 Reservation 聚合根和 Resource 聚合根。资源具有可用/不可用状态。系统允许创建预留并向其添加资源（在代码中，它当然是通过 Id 引用完成的）。下一步是接受预订，在这一步中，预订必须检查其所有资源是否处于可用状态。假设它不能在添加步骤中完成，或者只是该资源在它已经处于保留状态时改变了它的状态。如何进行这样的验证？

我想出了一个解决方案，让 Reservation 可以访问 ResourceRepository，但我发现不应允许 AggregateRoot 在 DDD 中拥有此类访问权限。

我的第二个想法是将验证移至 ApplicationService，但对我而言，此类验证看起来像域逻辑，因此应将其放置在域模型中。

我最后的想法是，也许我应该编写专门的 DomainService 来处理这种情况，但再次...... DomainService 是否应该有权访问存储库？

Answer 1

我认为您在最后一段中已经接近了这一点，但问题不是 应该 DomainService 可以访问存储库，更多的是关于可以 它有（在您的技术实施中）？在技​​术基础上评估该方法的优缺点，如果没有出现真正的坏事，那就去做。对我来说，这似乎是你的大脑一直在告诉你要做的事情。

然后随着时间的推移，你对周围领域、限界上下文、语言等的理解会变得更好（而且会），你总是可以进行重构和重构。没有什么是一成不变的。

Answer 2

这是一个非常常见且很容易解决的问题，但您需要退后一步。

您基本上应该有两个有界上下文 - 保留和资源。 保留不能访问任何其他有界上下文的任何类/服务/对象，因为它违反了封装规则。

您应该改为在 resources 有界上下文中创建查询处理程序。 resources 应该共享查询和响应类，它们将提供您需要的信息 - 公共 API，它是您的域之间的合同。最重要的是，reservations bounded context 不应该知道 resources 的任何实现细节。

PHP 中的示例：

资源域：

请求信息：

class IsResourceAvaiableQuery
{
    private int $resourceId;

    __construct(int $resourceId)
    {
        $this->resourceId = $resourceId;
    }

    public function getResourceId(): int 
    {
        return $this->resourceId;
    }
}

要获得一个不应该是简单类型，而是由类表示的响应：

class IsResourceAvaiableDTO
{
    private bool $isAvailable;

   __construct(bool $isAvailable)
   {
       $this->isAvailable = $isAvailable;
   }

   public function isAvailable(): bool 
   {
       return $this->isAvailable;
   }
}

请注意，查询和响应 DTO 都是不可变对象 - 您不能改变它们的状态。

现在在 reservation 域中：

class ReservationValidator
{
    
   public function validate(Reservation $reservation): ViolationsList 
   {
       $isResourceAvailableQuery = new IsResourceAvaiableQuery($reservation->getResourceId());
       $isResourceAvailableDTO = $this->messageBus->query($isResourceAvailableQuery);


      if (false === $isResourceAvailableDTO->isAvailable()) {
          // mark $reservation as invalid  
      }
   }
}

总结

这样您就有了一个单一的事实来源，并且 reservation 域不需要知道您如何确定资源是否可用。此外，您可以随时更改实现，只要您不更改合同（IsResourceAvaiableQuery & IsResourceAvaiableDTO），它就不会影响 reservations 域。

请注意，资源可能在两个域中以不同的方式可用，您也需要进行拆分：

• 资源 - 可供预订 - 存在并标记为可操作的项目
• reservations - 项目尚未预订。而且您需要合并来自两个域的决策才能全面了解情况。