各种领域驱动设计系统之间的集成
我最近一直在采用领域驱动设计原则，但在实现有界上下文以及上下文和/或其他系统之间的集成时遇到了一些麻烦。
以以下系统为例：
仓库/库存系统 实体将包括具有“数量”、“位置”等属性的“产品”
在线订购系统 实体将包括“Order”、“OrderLine”和“Basket”。它是否也有自己的产品实体，该实体具有“价格”等属性？
订购系统的一个明确的业务规则是不能为缺货的产品下订单，但此信息位于库存系统中。据我了解，以下是实现此目的的一些可能方法：
验证订单时，订单对象会调用库存系统中的服务来检查每种所需产品是否有足够的库存。但是，域调用另一个系统的应用程序服务感觉不太对劲，而且如果所有系统都这样做，则会导致所有内容都紧密耦合并交织在一起。
订购系统从库存系统的数据库中读取：订购系统中的产品实体映射到订购系统中的产品表和库存系统中的产品表或订购系统中的产品表的联接产品实体包含另一个名为 StockKeepingProduct 的实体，该实体具有来自库存系统的值。这很容易执行验证，但必须确保订购系统永远不会写入库存系统的数据库。
库存数量非规范化到订购系统的数据库中，每当库存系统的库存发生变化时，它都会向订购系统发送一条消息以更新其库存。
也许内心深处我知道我应该做 3，但我不确定我们是否已经准备好处理如此多的冗余数据和可能的不一致。您对1和2有何看法？或者您还有其他建议吗？
I have recently been adopting Domain Driven Design principles, but I'm having a bit of trouble implementing Bounded Contexts and the integration between the contexts and/or other systems.
For example, take the following systems:
Warehouse/Stock Keeping System
Entities would include 'Product' which would have properties such as 'Quantity', 'Location'
Online Ordering System
Entities would include 'Order', 'OrderLine', and 'Basket'. Would it also have its own Product entity which would have properties such as 'Price'?
One clear business rule for the Ordering System is that an order cannot be placed for a product that is out of stock, but this information is within the Stock Keeping System. From what I understand, these are some possible ways of implementing this:
When the order is validated, the Order object calls a service in the Stock Keeping System to check there is enough stock of each required product. However, something does not feel right about the domain calling an application service of another system, and also if all systems were doing this it would result in everything being closely coupled an intertwined.
The Ordering System reads from the database of the Stock Keeping System: The Product entity in the Ordering System is mapped to a join of the Product table in the Ordering System and the Product table in the Stock Keeping System, or the Ordering System Product entity contains another entity called StockKeepingProduct which has the values from the Stock Keeping System. This would be easy to perform the validation on but it would have to be ensured the Ordering System never writes to the Stock Keeping System's database.
The quantity of stock is denormalised into the Ordering System's database and whenever the Stock Keeping System's stock changes it sends out a message to the Ordering System to update its stock.
Probably deep down I know I should be doing 3, but I'm not sure we're quite ready to be handling so much redundant dat and possible inconsistencies. What are your opinions on 1 and 2? Or do you have any other suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这也完全取决于基础设施。如果您有 2 个系统在一个网络中运行，因此通信中断的可能性很小，我认为解决方案 1 没有问题。您可以将对库存系统的调用包装到适配器中，并在将来决定更改时轻松互换库存系统的 API 或完全如此的系统。还避免将其详细信息泄漏到订购系统中。
解决方案 3 更先进，需要更多资源来实施和维护，但允许完全分离这两个系统。更好地处理网络中断或性能瓶颈，例如订购系统需要处理的请求多于库存系统可以处理的请求。
但同样可以以与 1) 相同的方式实现 - 使用适配器分隔。恕我直言，从 DDD 的角度来看没有区别。
It also all depends on the infrastructure. If you have 2 systems running in one network hence there is minimal chance of communication disruptions, I don't see problem with solution 1. You can wrap the call to Stock Keeping System into adapters and easily interchange in future in case you decide to change the API of Stock Keeping System or the system completely as such. In also avoids leaking of its details into Ordering System.
Solution 3 is more advanced, requires more resources to implement and maintain, but allows for complete separation of those 2 systems. Better handles network disruption or performance bottlenecks such in case Ordering system needs to handle more requests than Stock Keeping System can handle.
But again it could be implemented same way as 1) - separated using Adapters. IMHO from DDD perspective no difference.