Shared Kernel and contracts
Which elements are worth sharing between repositories and services, and how to keep what you share from becoming a source of coupling.
What is a Shared Kernel?
It is a small set of concepts shared across several parts of the system.
It may include:
- very stable value objects
- minimal technical contracts
- genuinely cross-cutting utilities
- common types
What is worth sharing
UUIDEmailMoney- Very stable technical interfaces
- Certain well-governed events or contracts
What is not worth sharing too much
- Full domain models
- DTOs that change frequently
- Business logic
- Structures that force everyone to version at the same time
The main risk
If the shared kernel grows unchecked, it turns into a global dependency that:
- couples teams
- forces releases to be coordinated
- hinders independent evolution
Explicit contracts
Beyond the shared kernel, what really matters is having clear contracts between components:
- APIs
- events
- interfaces
- schemas
Sharing should not mean mixing contexts.
Summary
A small shared kernel can help. A large one tends to recreate the very problem you were trying to avoid: coupling.