How to manage identifiers for entities between bounded contexts in DDD?

Question

I need some clarification about managing identifiers for entities in DDD.

Assume we have Product model. It can have different meaning in Sales context, Shipping context and Inventory context. So we can have different models for each context according to the DDD.

Assume I'm using Guid as identifiers for entities. When I create a product with a Guid, should It create instances in other two contexts with that same Guid? or should we use different Guid in each contexts?

If we gonna use different Ids in different contexts, how do we know which product in Shipping context relates to product in Sales context? Since we use different Ids in each context how the same product will be identified between different contexts?

Answer 1

You should share the ID within all your bounded contexts. Whether it's their PK or some tracking field. (better to use PK).

If we do so, then we introduce a coupling for bounded contexts. Isn't it?

Yes, but not all coupling is bad, on the contrary, some would be necessary. But you have to be aware of the product lifecycle. Who creates, modifies, and deletes it? Do any changes on the product affect every bounded context? Have a clear vision about the lifecycle, otherwise, you'll end up in a bad mess.

Note: If modifying the product has a side effect on the other bounded contexts, then we shared a state across all bounded contexts because:

• we didn't want to depend on other bounded context data (escaping from being a downstream bounded context). You should be aware that duplicating data will be good if those data don't change so frequently. So when it's changing too frequently, eventual consistency might be a challenge for validations.
• we didn't define the right boundary and ended up duplicating data in the wrong way.

To sum up, duplicating data lowers the coupling but makes the design more complex (keeping all data up-to-date) and brings more issues on validations (are we duplicating the source of truth or not?).