Domain driven design 不同领域驱动设计系统之间的集成

我最近采用了领域驱动的设计原则，但在实现有界上下文以及上下文和/或其他系统之间的集成时遇到了一些问题

例如，以以下系统为例：

仓库/存货管理系统 实体将包括具有诸如“数量”、“位置”等属性的“产品”

网上订购系统 实体包括“订单”、“订单行”和“篮子”。它是否也有自己的产品实体，具有诸如“价格”之类的属性

订购系统的一个明确的业务规则是，不能为缺货的产品下订单，但此信息在库存管理系统中。据我所知，以下是一些可能的实施方法：

订单验证后，订单对象调用库存管理系统中的服务，检查每个所需产品是否有足够的库存。然而，域调用另一个系统的应用程序服务时感觉有些不对劲，而且如果所有系统都这样做，则会导致所有系统紧密耦合在一起

订购系统从库存系统的数据库中读取：订购系统中的产品实体映射到订购系统中的产品表和库存系统中的产品表的联接，或者，订购系统产品实体包含另一个名为StockKeepingProduct的实体，该实体具有来自库存系统的值。这将很容易执行验证，但必须确保订购系统不会写入库存系统的数据库

库存量被反规范化到订购系统的数据库中，每当库存管理系统的库存发生变化时，它就会向订购系统发送一条消息以更新其库存

---

也许在内心深处我知道我应该做3，但我不确定我们是否已经准备好处理如此多的冗余dat和可能的不一致性。你对1和2有什么看法？或者您还有其他建议吗？

这也取决于基础设施。如果在一个网络中运行两个系统，那么通信中断的可能性最小，我认为解决方案1没有问题。您可以将对Stock Keeping System的调用封装到适配器中，并在将来决定完全更改Stock Keeping System的API或系统时方便地进行交换。In还避免了将其细节泄露到订购系统中

解决方案3更先进，需要更多的资源来实施和维护，但允许完全分离这两个系统。更好地处理网络中断或性能瓶颈，如订购系统需要处理比库存管理系统所能处理的请求更多的情况

---

但同样地，它可以使用适配器以与1分离的方式实现。IMHO从DDD的角度看没有区别。

事实上，是否应该有一个使用库存系统上的服务的协调流程，如果该商品有库存，则使用订购系统上的服务下订单？谢谢您的输入。一般来说，我认为我正朝着第三个目标迈进，但这需要在我的工作场所进行一点文化变革。你们不认为解决方案1可能真的很危险和/或昂贵吗？如果在本例中我处理的是实体订单的一个实例，并且我正在调用一个方法，那么从消费者的角度来看，调用另一个服务甚至数据库将是完全出乎意料的事情。