DDD - When a single physical entity in the problem space is represented as different concepts in code, how to link them together?

When a single physical entity means different things in different contexts, DDD principles recommend creating different entities in each bounded context. This is an example taken from the book "Patterns, principles and practices of Domain-Driven Design": A "Product" is a concept that must be acquired with a profitable margin and an acceptable lead time to the Procurement team. Yet to the Sales team a product is a concept with images, size, guides, and belongs to a selling category—none of which are relevant to the Procurement team, even though it is the same physical entity in the problem domain. My question is, how does the Sales bounded context and the Procurement bounded context know they are dealing with the same product? How do you find the same entity in the Sales context and Procurement context for reporting purposes? How do you store the identity in the database? I expect each Product class to have it's own table. Normally identity is autogenerated by the database. We can't guarantee Sales database and Procurement database would generate the same Id for the same physical entity. How do you link these two concepts in software?

May 26, 2025 - 00:50

When a single physical entity means different things in different contexts, DDD principles recommend creating different entities in each bounded context.

This is an example taken from the book "Patterns, principles and practices of Domain-Driven Design": A "Product" is a concept that must be acquired with a profitable margin and an acceptable lead time to the Procurement team. Yet to the Sales team a product is a concept with images, size, guides, and belongs to a selling category—none of which are relevant to the Procurement team, even though it is the same physical entity in the problem domain.

My question is, how does the Sales bounded context and the Procurement bounded context know they are dealing with the same product? How do you find the same entity in the Sales context and Procurement context for reporting purposes?

How do you store the identity in the database? I expect each Product class to have it's own table. Normally identity is autogenerated by the database. We can't guarantee Sales database and Procurement database would generate the same Id for the same physical entity. How do you link these two concepts in software?