我正在研究DDD项目，目前我专注于两个优秀的背景，订单和仓库。
令我困惑的是以下情况： 订单跟踪所有下订单，仓库跟踪所有可用库存。如果用户为某个产品项目下了一个订单，那么这意味着仓库中的产品少一个。我过度简化了这个过程，所以请耐心等待。
由于两个域模型被放置在不同的BC内，我目前依赖于最终的一致性，即。在一件商品售出后，它最终会从仓库中移除。
不幸的是，这种情况导致了另一个用户可以同时制作同一项目的另一个订单的问题场景，并且在最终的一致性启动之前它将显示为可用。这是领域专家无法接受的。
所以IMO我遇到了两个选择
DDD patern实际上遵循哪个选项？还有另一种出路吗？
答案 0 :(得分：1)
您可以使用超时的预订系统。
使用消息传递类比：使用代理样式的排队机制（例如RabbitMQ），您可以从队列中获取消息，并且您可以控制它，直到您确认它可以从队列中删除队列或你释放它回到队列。
您可以在订购过程中做同样的事情。您在订单上预订了任何物品。因此，当您添加它们时，它们的状态为reserving，并且在发送一些消息以保留项目时。如果响应回来，您可以决定如何继续。也许您可以添加任何无法保留在延期订单上的商品或稍后再试。
有不同的方法可以解决这个问题。根据您的业务案例，当真正接受订单时，可能只接受检查可用性。
如果你的领域专家认为，完全是不可接受的，那么在流程结束时解决了这个问题，那么你可以将它移到开头。问题当然是用户A可以保留并且从不购买从而失去用户B作为客户;而在流程结束时仅应用真实“获取”项目更接近于确保购买。但这是一个商业决策。
答案 1 :(得分：1)
这个问题是一个非常好的例子，说明现实实际上最终是一致的。如果仓库中目前没有库存，那么拒绝订单真的是最好的事情 - 即使在接下来的20分钟内有补货吗？
如果物品实际上在货架上，但操作员还没有将其键入系统怎么办？
有时候设计师和领域专家会认为人们希望100％保持一致性，而实际上，用户可能愿意接受延迟确认他们的订单，如果它增加了他们的订单被接受而不是被拒绝的机会。
在上面的案例中，为什么要让用户的工作在N分钟后重试他们的订单？在最终一致的系统中，您可以通过在确认客户确认无法完成之前在一段时间内重试尝试完成订单的超时来适应此类时间灵活性。
有技术解决方案可以让您100％保持一致性，但我认为这不是技术挑战，而是文化/思维方式，改变人们对可能性和可能性的看法。可以接受实现更好的结果。
答案 2 :(得分：0)
IMO，您可以构建一个 PlaceOrderSaga，它会在下订单之前询问库存可用性。