如何在DDD中对此情况进行建模？

Question

我面临的问题要么无法应用DDD，要么不能重新重新制定案件以适合DDD规则。

要求：

1. 我们有产品和位置。
2. 更改位置应反映在 product 然后看到的。因此，产品参考位置。
3. 相同的位置可以在几个产品中使用。
4. 产品可以在任何时间点创建和删除。
5. 位置可以在任何时间点创建。
6. 位置只有在没有产品引用此位置的情况下才能删除。
7. product 的删除不会导致位置删除。

该模型中还有两个实体，具有与位置相同的规则，但是解决方案应与 location 案例相同。

澄清1 ：

product 在不在任何位置的情况下，也不能与任何 location> location ，它必须有一个位置。您可以在任何时间点创建两个聚合物，但是创建 product 的条件已经存在位置。

我的想法：

因此，我看到的问题是，这种要求会产生循环依赖性 product 和位置。因为他们都有自己的无限生命周期，所以他们应该是单独的聚合根源，但是这违反了一致性边界，因为基本上一个AR试图控制另一个AR。因此，这个不变的人不能放在这两个中的任何一个中。试图将其提取到顶部AR上的第三个也不清楚这将如何工作。

问题：

如何满足DDD中的此类要求？删除约束6不是一个选择。我已经尝试与业务方面谈判这一点。

Answer 1

聚合是一致性边界。因此，如果您绝对需要对任何位置的更改才能立即反映在产品中，反之亦然，那么您基本上需要将所有位置和所有产品用于一个汇总，然后具有某种形式的并发控制形式，这有效地限制了该巨型 - 汇总变化（并将大大限制该大型聚集可以改变的速率）。

请注意，您可以使用基础架构（例如具有外国密钥要求的关系DB交易）来假装真正的一个大型聚集物是多个较小的聚集体。这样做不会改变基本的性能（它的上限可能比简单的DDD实现将使用的钥匙值乐观的并发控制方法更高，因为它将允许并发更新以散射大型杂物的部分）并且有一个缺点，而不是您的域逻辑居住在代码中的一个位置，现在已在您的DB模式中部分编码（无论它是否在代码中的其他位置重复）。

说不能应用DDD（特别是聚集体）或案例不符合骨料周围的规则，这并不是真正准确的，不止一个人可以说不能应用物理定律。只是您在应用要求时获得的解决方案不是您喜欢的。

或者，需求可能是互不兼容的（例如，要求能够在某个时期内执行X更新并具有很强的一致性）。在这里，炼油要求可能会有所帮助，特别是涉及松动一致性要求。比域实际要求更强大的一致性要求确实很普遍（询问“如果发生这种情况……实际发生的事情……”是有帮助的）。

Answer 2

这一切看起来都很简单。您的“产品”数据模型包括一个链接（名称，标识符等）到“位置”。

唯一棘手的位是：

只有在没有产品参考此位置的情况下才能删除位置。

您可能应该查看Udi Dahan：不要删除 - 只删除 - t 。

---

重要问题：这里失败的业务成本是多少？

如果拥有具有删除位置的产品很昂贵，那么您必须考虑到该限制的数据模型。这可能意味着您在删除位置时必须锁定产品数据，并且在更新产品时也可能锁定位置。

猜测，您可能会考虑将所有产品和位置存储在同一数据库中，并设置外键约束以确保遵守规则。是的，由于这种设计，可能会受到绩效罚款，但这是因为它解决了昂贵的问题而证明了这一点。

另一方面，如果业务更加宽容，那么可能还有其他思考域模型的方法。一种可能性是，位置具有“状态” - 处于活动状态或弃用，如果不允许产品处理产品为弃用的位置分配产品（弃用的位置将在下拉列表中隐藏），但是弃用的位置仍然出现在报告中。

（实际上，我们在这里谈论的一种软删除形式，但是在我们的实际业务流程层面上，而不是在管道中。）

---

这可能有助于扩展您对业务中“位置”的理解 - IS位置一个概念，该领域模型是真理的来源？还是位置是参考数据的形式？位置是由一些数据导入 /数据输入过程引起的，还是您的域模型产生的。

在原始DDD书中的示例，位置确实是参考数据；国际端口和终端的实际清单是由UN/ECE管理，更新两次。一年。

因此，在对运输域进行建模时，我们期望位置代码通过数据导入过程出现。请注意，这里的“删除”内置了很多延迟 - 国家当局决定应将地点划清位置，并且需要由联合国/ECE处理，这意味着下一个出现的问题报告说明了代码。 标记为删除;并制定了各种流程，以确保“删除”后，相关代码在一段时间内不会重复使用。

鉴于信息在系统中移动需要几个月的时间，这里的任何“直接一致性”要求都是荒谬的。域模型中必须有空间，以便在不等待其他地方做出的决定的情况下做出本地决策。

另一方面，如果您要为联合国/ECE创建一个位置模型，这本身就是代码分配的真实来源，那么更严格的一致性要求可能是合适的。

马课程。

Answer 3

在您的点2中，您说

位置更改应反映在用户然后看到的产品中。 因此，产品参考位置。

我认为这个结论是不正确的。我的看法是，该产品不需要了解位置，或者至少您没有提到任何需要的规则。用户需要查看产品位置的事实意味着您需要一种基于产品ID查询位置的方法，但这是一个查询问题，而不是汇总问题。如果您遵循CQRS，则汇总与查询区别将显而易见。

您可以设计一个可以保留产品集合的位置聚合。这些产品在该位置汇总的产品不是实际的产品聚集体，而是具有生产力以及潜在其他属性的实体。

让我们看一下您的规则：

在几种产品中可以使用相同的位置。

通过在该位置集合中拥有一系列产品来解决这一问题

可以在任何时间点创建和删除产品。

产品可以不在任何位置而存在。

删除产品后，您需要发布一个事件，以便所有包含该产品的位置都可以将其删除（这也需要一种查找引用Productids的位置骨料的方法）

可以在任何时间点创建位置。

没问题。可以在不引用任何产品的情况下存在一个位置。

只有在没有产品参考此位置的情况下才能删除位置。

现在，这很容易实现，因为删除位置在集合可以检查其产品集合中的操作。

删除产品不会导致位置删除。

这不是问题，因为产品甚至都不知道

该设计的问题是，从技术上讲，可以将相同的产品添加到多个位置。我不知道这是否是一个问题。一种可能的解决方案是，当产品被添加到一个位置时，位置汇总发布了一个已经包含该产品的位置将处理并自动从集合中删除该产品的事件。

您还可以使用技术解决方案避免这种情况，例如 locationproducts 表中的DB中的唯一密钥约束。

Answer 4

正如您正确说明的那样，产品和位置是两个不同的聚合。他们不能互相控制，并且拥有 product 保留对单个位置的引用没有问题。在位置中，持有 products 的列表（甚至简单的计数器）也是如此。

现在，假设您担心演示层（例如A UI甚至API），例如，由于可能更改位置 ，或删除产品。在这种情况下，您可能需要考虑派遣域事件并编写适当的处理程序来处理它们。您可能还需要考虑使用CQR，并创建/刷新查询模型将被演示层消费。