Shared Kernel

A small, explicitly shared part of the domain model that two or more bounded contexts own together.

A shared kernel is a small piece of domain model that two or more bounded contexts deliberately share. Instead of each context having its own version of a concept, they agree to co-own a specific, well-defined part.

The classic example is something like tax rate calculation or a common address format. Both contexts need the exact same logic, and having two independent implementations would drift apart and cause bugs. So the teams agree: this part is shared, changes go through both teams, and everyone keeps it in sync.

The key word is "small." A shared kernel should be the exception, not the rule. If you start sharing large parts of the model between contexts, you're eroding the boundaries that bounded contexts are supposed to give you. At that point, you don't have separate contexts. You have a single model pretending to be two.

In practice, a shared kernel often takes the form of a small library or package that both contexts import. Changes to it require agreement from all teams involved, which means code reviews, coordinated releases, and careful versioning. This overhead is the cost of sharing, and it's worth it only when the alternative (duplicating and maintaining two copies) is worse.

Before reaching for a shared kernel, consider whether the contexts truly need the same model. Often, what looks like duplication is actually two contexts that need different views of the same concept. A "user" in billing and a "user" in authentication serve different purposes and should evolve independently. Only share when the concept is genuinely identical across contexts and keeping separate copies would cause real problems.