问题
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?
回答1:
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.
来源：https://stackoverflow.com/questions/6523282/integration-between-various-domain-driven-design-systems