各种域驱动设计系统之间的集成

Question

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

例如，采用以下系统：

仓库/库存系统 实体将包括“产品”，其中包含“数量”，“位置”等属性

在线订购系统 实体将包括'Order'，'OrderLine'和'Basket'。它是否也有自己的产品实体，它具有“价格”等属性？

订购系统的一个明确的业务规则是，无法为缺货的产品下订单，但此信息在库存保管系统中。据我所知，这些是实现这一目标的一些可行方法：

1. 验证订单时，Order对象会调用Stock Keeping System中的服务，以检查每个所需产品是否有足够的库存。但是，对于调用另一个系统的应用程序服务的域而言，某些事情并不合适，并且如果所有系统都这样做，则会导致所有内容紧密耦合在一起。

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

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

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

Answer 1

这一切都取决于基础设施。如果您在一个网络中运行了2个系统，因此通信中断的可能性很小，我没有看到解决方案1的问题。您可以将对Stock ieping System的调用包装到适配器中，以便将来轻松交换，以防您决定更改股票保管系统的API或系统完全如此。同时也避免将其细节泄漏到订购系统中。

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

但同样可以实现与1）相同的方式 - 使用适配器分离。从DDD的角度来看恕我直言没有区别。