如何解决Order和Warehouse有界上下文依赖关系？

Question

我正在致力于DDD项目，我目前主要关注两个受损的环境，订单和仓库。

令我困惑的是以下情况： 订单跟踪所有下订单，仓库跟踪所有可用库存。如果用户对某个产品项目下了一个订单，这意味着仓库中该产品的一个更少的项目。我简单地说明了这一过程，所以请耐心等待。

由于两个领域模型被放置在不同的BC内，我目前依靠最终的一致性即。在一件物品被出售之后，它最终会从仓库中移出。

不幸的是，这种情况导致了另一个用户可能同时进行同一项目的另一个订单的问题场景，并且它会显示为可用，直到最终的一致性踢球为止。这是领域专家无法接受的。

所以IMO我坚持两个选项

• 合并订单和库存（至少部分有关产品 库存，仓库可用单位）为BC一个
• 有秩序BC（或微服务，如果您希望）取决于仓库BC（微服务）以便拉动现有产品单元 可用

哪个选项确实跟随DDD模板？有另一种出路吗？

Answer 1

您可以使用超时预订系统。

使用消息的比喻：随着券商风格排队机制（如RabbitMQ的）你从队列中的消息，你拥有控制权，直到您承认，它可以从队列或者你被移除版本它回到队列。

您可以在订购过程中做同样的事情。您保留订单上的任何物品。所以当你添加他们时，他们的状态是reserving，并且发送一些消息来保留这些项目。如果回复返回，您可以决定如何继续。也许你可以添加任何不能保留的项目，或稍后再试。

将会有不同的方法来解决这个问题。根据您的业务案例，它可能是可以接受的只有当有人真的接受订单时检查可用性。

如果你的领域专家认为它是完全不能接受的是，在过程结束时解决这个问题，那么你可以将它移动到开始。问题当然是用户A可以保留并永不购买，从而使用户B失去作为客户;而在流程结束时仅应用该项目的“获取”项目更接近于确保购买。但这是一个商业决定。

Answer 2

这个问题是一个非常好的例子，其实际情况最终是一致的。如果仓库中没有库存 - 即使在接下来的20分钟内有补货，是否真的是拒绝订单的最佳选择？

如果物品实际在货架上，但操作员尚未将其键入系统中，该怎么办？

有时候，设计师和领域专家认为人们希望100％一致，当真的，用户可能愿意接受延迟确认他们的订单，如果它增加了他们的订单被接受而不是被拒绝的机会。

在上述情况下，为什么使用户的工作在N分钟后重试其订单？在最终一致的系统中，您可以通过包含超时重试尝试在一段时间内完成订单来适应这种时间灵活性，然后再确认客户端确实无法完成订单。

有技术解决方案可以让你百分百的一致性，但我认为这不是一个技术挑战，而是一种文化/思维方式的挑战，改变人们对于什么可能是可以接受的想法&实际上是一个更好的结果。