验证跨越多个聚合根的域规则

如何解决验证跨越多个聚合根的域规则

让我们假设我们拥有以下AR：

• 服务-负责服务配置。
• DaySchedule-负责定义一周中每一天（周一，周二，周三...周日）的时间表，并创建日历日的约会，例如2020年8月15日。

public class Service : Entity,IAggregateRoot
{
   public bool Available { get; private set; }
   public int TimeSlotDuration { get; private set; }
}

public class DaySchedule : Entity,IAggregateRoot
{
   public DayOfWeek DayOfWeek { get; }
   public List<Appointment> WorkingHours { get; private set; }
   public List<Appointment> Appointments { get; private set; }
}

public class Appointment : Entity
{
   public Guid ServiceId { get; }
   public int AppointmentStart { get; private set; }
   public int AppointmentEnd { get; private set; }
}

为了正确创建和定义约会，约会持续时间（介于AppointmentStart和AppointmentEnd之间的时间）不得超过服务AR上定义的TimeSlotDuration值，服务也必须可用。

现在，我面临的问题是-如何正确有效地执行此操作？

此刻我正在做的事情是

1. 读取服务AR，获取并提取必要的值。
2. 验证新约会中的属性是否有效，否则，抛出异常。

我猜这可行，但是还有更好的方法吗？如果我还需要检查其他 n 个AR，怎么办？

我想到的是最终的一致性，但是我看不到如何在自己的情况下应用它。也许某种Saga遍历了所有汇总，验证了所有域规则，并且仅在所有规则都经过验证后才插入约会？

解决方法

现在，我面临的问题是-如何正确有效地执行此操作？

集合101：如果您有两个必须始终保持一致的信息，则这两个信息应属于同一集合，因为任何可能改变其中一项的交易也必须考虑另一项

当系统处于平衡状态时（但不一定在事物发生变化时）必须达成共识的两条信息可以分布在两个不同的集合中。

这是您必须要做的第一步-您的约会是否需要始终与服务状态保持一致？或只是什么时候停止移动？

（在大多数涉及人的情况下，业务答案是“当事物停止移动时”。）

如果您需要即时协议，那么在任何时候需要更改约会时，都需要防止服务“同时”更改，并且每当您对服务进行更改时，还需要考虑所有受影响的约会。

这又意味着（a）您只有一个可以进行所有更改的锁，或者（b）服务且受影响的约会始终被锁定在一起。

我们将相关信息组织在一起以将其全部锁定在一起的模式的名称为“聚合”。

在这种情况下，数据必须始终是一致的，因此建议的过程是重新设计聚合，以便单个聚合可以保持不变。这通常会导致您以出乎意料的方式雕刻域模型-参见Mauro Servienti的演讲All Our Aggregates are Wrong。

最终一致性适用于在事物不断变化时数据不必保持一致的情况，只要事物不断变化直到数据一致即可。一个共同的出发点是发现可能的问题，将关注的问题上报给人类进行补救。

请参阅Rinat Abdullin在evolving process managers和Pat Helland的Memory,Guesses,and Apologies上的著作。

,

通常，我的处理方法是必须提供汇总不需要的任何数据。

集成/应用程序关注点是收集所有数据和域对象的地方。通常，您不会查询汇总，但是取决于您采用哪种方式获取数据。一旦确定您确实可以根据Appointment的可用性和持续时间预订Service，就可以继续进行。您可以选择在应用程序项目中创建一些类来封装处理过程以供重用。

可能存在的“问题”是在创建约会时服务持续时间和/或可用性发生变化。这有点比赛条件。但是，可以通过为服务设置一个未来的ExpiryDate来缓解这种情况，或者，如果服务属性发生更改，则为每个需要更改的Appointment引入某种补偿机制。在这里，流程管理器可能会有用。

您将遇到许多情况，其中您依赖于聚合之外甚至BC之外的数据。您需要根据需求设计每种方法。例如，可以通过以下方法处理航班预订：首先预订座位，然后在接受预订后应用预订，或者通过允许同一座位进行多次预订，并首先完成预订的人获胜。不过，这是一种设计选择。