Lookup code tables in DDD

Question

I'm curious on the best way to handle lookup-type codes that can be shared across bounded contexts. For instance, state codes, or business-specific type codes that might be used in more than one bounded context. Does it make sense to have a single database for these, with an api in front to fetch the code lists, or duplicate them per each bounded context that needs them? Furthermore, this has me wondering what to do with referential integrity if the first option is desired. Many of the codes aren't using a natural key but instead a surrogate (auto-generated by the database) id.

Answer 1

DDD is great but it doesn't go as high as it could.  Above DDD we can imagine business roles that have business responsibilities.

One such business responsibility is managing records as the authority of reference — e.g. if we accept an order, we can give it an ID.  There is a certain department responsible for accepting or rejecting orders, keeping the list of orders as the authority of record for them, and no one else should be allowed to accept an order, issue an order id, or claim they are the authority for the list of accepted orders.

Thus, when we think about multiple bounded contexts we should try to realize that the intention is to bring (maintainable) automation to the jobs of various business roles and their business responsibilities — not merely to separate concerns in order to address monolithic automation designs.

---

...business-specific type codes that might be used in more than one bounded context.

Many of the codes aren't using a natural key but instead a surrogate (auto-generated by the database) id

Maintaining your business codes is probably a business function that some department will (ought to) have responsibility for.  You should to ask questions about what will happen if each bounded context maintains their own version of these codes?  One bounded context may add a code that other's haven't yet added.  Is that an issue?  Is there a department that is responsible for this (could be IT, I suppose), and how would they feel about maintaining codes centrally vs. across business contexts?

Does it make sense to have a single database for these, with an api in front to fetch the code lists, or duplicate them per each bounded context that needs them?

You're asking whether to provide a normalized implementation of the codes, or duplicate them in multiple bounded contexts.

Ideally, we would manage these codes in one place.  At minimum, I would say you might cache them across bounded contexts rather than merely duplicating them, and they should be managed (new ones added, old ones obsoleted) centrally.

Furthermore, this has me wondering what to do with referential integrity if the first option is desired.

Perhaps you should not delete business codes that are potentially used by other bounded contexts.  You can instead obsolete them, and even provide a forwarding or replacement code — this as part of the API around the management of the business codes.  So, the API would speak to what codes, the business intention, the definition of the code, the policies & rules associated with the codes, the status of each code (current or not), and when not current: the replacement(s) and/or clarifications (preferred subcodes).

Answer 2

Does it make sense to have a single database for these, with an api in front to fetch the code lists, or duplicate them per each bounded context that needs them?

For autonomous services, you are probably going to want to cache a copy of this data in each context that needs it.

After that, it's trade offs all the way down. Using the same schema everywhere is "easy", but potentially wastes space. Cache invalidation is one of the two hard problems, so you need to worry about how changes are going to be shared across your contexts.

Pay attention to the rate of change - US state codes have been stable since 1959; stockkeeping units can churn quite a bit.

what to do with referential integrity

Referential integrity can be a spook show when new codes enter the picture, especially if they can appear without advanced warning. It may make more sense to record the data that would otherwise violate the constraints, and notify a human being that there seems to be a conflict.

Again, horses for courses.