5

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?

Paul H
  • 2,104
  • 7
  • 39
  • 53

2 Answers2

3

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.

Adrian Thompson Phillips
  • 6,893
  • 6
  • 38
  • 69
0

The reference data could be persisted/accessed through a REST API. This API is responsible for securing and persisting data. The api translates reference data into objects graphs (in both directions) that are used to hydrate domain models. One graph per client BC. A good policy of authentication should help. If a team needs something new, it is now just possible for it to add or modify its graph, without risk for other teams. A good policy of versioning should help. Updates pushed to the API should be synchronous and transactional. Read operations could not, if possible, to prevent to stress it if it can be avoided.

Rénald
  • 1,412
  • 12
  • 29
  • Be careful to expose business graphs, and not single properties. A graph still legitimates the use of the reference data in a given context and it is possible to validate it (in a DDD perspective). Single properties don't allow it. The REST API could also be responsible for validating it, in some way. – Rénald Mar 20 '17 at 07:53