domain-driven-design - 各种领域驱动设计系统之间的集成

Question

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

例如，采取以下系统:

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

在线订购系统
实体将包括“Order”、“OrderLine”和“Basket”。它是否也有自己的 Product 实体，该实体将具有诸如“Price”之类的属性？

订购系统的一项明确业务规则是，不能为缺货的产品下订单，但此信息在库存管理系统内。据我了解，这些是实现这一点的一些可能方法:

当订单被验证时，Order 对象调用 Stock Keeping System 中的服务来检查每种所需产品是否有足够的库存。但是，调用另一个系统的应用程序服务的域感觉有些不对劲，而且如果所有系统都这样做，这将导致一切都紧密耦合在一起，相互交织。

Ordering System 从 Stock Keeping System 的数据库中读取:Ordering System 中的 Product 实体映射到 Ordering System 中的 Product 表和 Stock Keeping System 中的 Product 表的 join，或者 Ordering System Product 实体包含另一个名为 StockKeepingProduct 的实体具有来自 StockKeeping System 的值。这将很容易执行验证，但必须确保订购系统永远不会写入库存系统的数据库。

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

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

Answer 1

这也完全取决于基础设施。如果您有 2 个系统在一个网络中运行，因此通信中断的可能性很小，我认为解决方案 1 没有问题。您可以将调用 Stock Keeping System 封装到适配器中，并在 future 轻松交换，以防您决定更改库存系统的API或系统完全如此。还避免将其详细信息泄露到订购系统中。

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

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