Let's say we have an
Order entity that will be modeled in 2 diff. BCs in a e-commerce application.
The first BC is
Order Placement. This BC takes care of collecting all orders placed by our customers from our different websites, validates them and populates its corresponding database by Orders with state either
The 2nd BC is
Shipment. This allows the employees in the warehouses to mark an Order as
Shipped in its database once it leaves the warehouse.
Now since both BCs use different databases which are empty at first, there will be a need to inform the
Shipment BC of the orders that were
Placed, so that when a scanner wants to
Order it will be there in the
My initial approach was to create a domain event once an
Order is placed in the
Order placement BC and have the
Shipment BC subscribe to that event and create a corresponding
Order entity in its database for every order placed.
However, I can't stop that feeling that I'm duplicating data across different databases.
My second approach is to ask the
Order Placement each time an order is being
Shipped for an
Order entity, but I still need to maintain the state of the Order in case a failure of a failure in the shipment.
Is there a better approach to all this from a DDD POV?
Your first approach is perfectly fine in my opinion. You are not duplicating data, because as you already noticed, that data is from another context. Same data in different contexts means different things.
As Vernon Vaughn pointed out in his book «Implementing Domain Driven Design»: "A greater degree of autonomy can be achieved when dependent state is already in place in our local system. Some may think of this as a cache of whole dependent objects, but that’s not usually the case when using DDD. Instead we create local domain objects translated from the foreign model, maintaining only the minimal amount of state needed by the local model.” So copying data is okay as long as it is the only data other BCs need. But he also mentions that if you use exact copies, it might be a sign of a modeling problem.