我正在从事 DDD 项目，目前我专注于两个有界上下文，Orders和Warehouse。
让我困惑的是以下情况：订单跟踪所有已下订单，仓库跟踪所有可用库存。如果用户为某个产品项目下一个订单，那将意味着该产品在仓库中少一件。我过于简化了这个过程，所以请多多包涵。
由于两个域模型被放置在不同的 BC 中，我目前依赖于最终的一致性，即。一件商品售出后，最终会从仓库中取出。
不幸的是，这种情况会导致问题场景，即另一个用户可以同时对同一项目进行另一个订单，并且在最终一致性启动之前它会显示为可用。这是领域专家无法接受的。
所以IMO我有两个选择
哪个选项实际上遵循 DDD 模式？还有其他出路吗？
您可以使用带有超时的预订系统。
使用消息传递类比：使用代理式队列机制（例如 RabbitMQ），您可以从队列中获取消息并且可以控制它，直到您确认可以将其从队列中删除或将其释放回队列.
您可以在订购过程中做同样的事情。您保留订单上的任何物品。因此，当您添加它们时，它们的状态为，例如，reserving在发送一些消息以保留项目时。如果回复回来了，您可以决定如何继续。也许您可以将任何无法保留的项目添加到延期交货单中或稍后再试。
将有不同的方法来解决这个问题。根据您的业务案例，仅在有人真正接受订单时才检查可用性可能是可以接受的。
如果您的领域专家认为在流程结束时解决此问题是完全不可接受的，那么您可以将其移至开始。问题当然是用户 A 可以保留而不购买，从而失去用户 B 作为客户；而仅在流程结束时应用该项目的真正“获取”更接近于确保购买。但这是一个商业决定。
这个问题是一个很好的例子，说明现实实际上最终是一致的。如果仓库中目前没有库存——即使接下来的 20 分钟内有补货到期，拒绝订单真的是最好的事情吗？
如果物品实际上在货架上，但操作员尚未将其输入系统怎么办？
有时设计师和领域专家假设人们想要 100% 的一致性，而实际上，用户可能愿意接受延迟确认他们的订单，如果这增加了他们的订单被接受而不是被拒绝的机会。
在上述情况下，为什么要让用户在 N 分钟后重试订单呢？在最终一致的系统中，您可以通过在一段时间内重试完成订单的尝试来适应这种时间灵活性，然后再向客户确认这确实是不可能的。
有一些技术解决方案可以为您提供 100% 的一致性，但我认为这实际上不是技术挑战，而是文化/心态挑战，它改变了人们对什么是可能和可接受的想法，以实现实际上更好的结果。
IMO 您可以构建一个 PlaceOrderSaga，它会在下订单之前询问库存可用性。