Shared Kernel

Also Known As

TL;DR

Explanation

A Shared Kernel is a deliberate coupling point: two contexts agree to share specific classes (value objects, domain events, DTOs) and coordinate on any changes. It is NOT accidentally shared code — it is a formal agreement. Best for: tightly related contexts owned by the same team, where the coordination cost is lower than maintaining two separate but nearly identical models. Anti-pattern when: teams are independent, the shared portion grows unchecked, or the shared code becomes a dumping ground for anything two contexts need.

Common Misconception

Why It Matters

Common Mistakes

• Shared Kernel that grows over time without governance — becomes a monolithic shared library.
• No team agreement on change process — one team changes the kernel, breaks the other.
• Sharing infrastructure code as a Shared Kernel — infrastructure utilities are not domain concepts.
• Using Shared Kernel to avoid duplicating convenience code — duplication is often better than coupling.

Code Examples

// Shared kernel used as a dumping ground:
namespace SharedKernel;
// Originally: just Money and CustomerId
// 2 years later: 200 classes, utilities, helpers, configs
// Every team change breaks others
// No clear ownership — everyone and nobody owns it

// Disciplined shared kernel — minimal, governed:
namespace SharedKernel;

// Only truly shared domain concepts:
final class Money { /* amount + currency */ }
final class CustomerId { /* UUID value object */ }
final class OrderId { /* UUID value object */ }

// Change process: both teams must review and approve
// Version controlled independently — SharedKernel v2.1
// Both contexts pin to the same version
// Size limit: if > 20 classes, something is wrong

References

• ↗ https://www.domainlanguage.com/ddd/reference/

Tags

Related Terms