I am relatively new to the concept of DDD and have found there are plenty of examples which explain how a bounded context should be defined for relatively simple scenarios, but one area that doesn't seem to be covered is master data and reference data.
The types of reference data I'm referring to would currency codes, country codes, and units of measurement, which would be used to ensure only valid values are used.
The types of master data I'm referring to would be entities such as customers and products where there is no requirement for different bounded contexts to have their own perspective of the entity. I understand that in some scenarios the customer entity in an invoicing bounded context would be different the customer entity in a shipping bounded context, but for the purpose of this question we can assume that both invoicing and shipping need exactly the same customer data.
My questions is in an application that has multiple bounded contexts (such as an ERP system) should master data and reference data be defined in a common bounded context or should these entities be duplicated in each bounded context even when they would contain exactly the same data?
In the various DDD books, having this shared subset of the domain model is called a Shared Kernel. The main problems of sharing the domain model is that if 2 or more software teams, each working on a different bounded context, want to update anything in the shared kernel, they must agree the side-effects of the changes with the other teams. It also pollutes other bounded contexts with terminology and artefacts from the other bounded contexts.
For example, if the invoicing team wish to add a LoyaltyDiscountPercentage property to their Customer entity, the other teams sharing this domain entity will have to accept this property that has no relevance to their own bounded context. The Customer entity will soon pick up artefacts from many separate bounded contexts and will fail to describe a customer in any single context.