各种领域驱动设计系统之间的集成 [英] Integration between various Domain Driven Design systems

问题描述

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

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.

例如，使用以下系统：

仓库/存货系统
实体将包含产品，该产品具有数量等属性， 位置

Warehouse/Stock Keeping System Entities would include 'Product' which would have properties such as 'Quantity', 'Location'

在线订购系统
实体包括订购， OrderLine和购物篮。

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:

1. 当订单通过验证后，Order对象将调用a库存系统中的服务以检查每种必需产品的库存是否足够。但是，对于域调用另一个系统的应用程序服务而言，这并不正确，而且如果所有系统都在执行此操作，则将导致一切紧密耦合在一起。

1. 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.

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

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.

大概我知道我应该做3，但是我不确定我们是否已经准备好处理如此多的冗余数据和可能的不一致之处。您对1和2有何看法？还是您还有其他建议？

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?

推荐答案

这还取决于基础架构。如果您在一个网络中运行2个系统，因此通信中断的可能性很小，那么我认为解决方案1不会出现问题。您可以将对Stock Keeping System的调用包装到适配器中，以备将来决定更换时轻松互换库存管理系统的API或系统本身。

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.

解决方案3更先进，需要更多资源来实施和维护，但可以完全分离这两个系统。更好地处理网络中断或性能瓶颈，以防万一订购系统需要处理的数量超出库存管理系统的能力。

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.

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

But again it could be implemented same way as 1) - separated using Adapters. IMHO from DDD perspective no difference.

这篇关于各种领域驱动设计系统之间的集成的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！