Zum Hauptinhalt springen

Shared Kernel

Einleitung​

Shared Kernel erlaubt zwei oder mehr Bounded Contexts, einen klar definierten, kleinen gemeinsamen Modellbereich explizit zu teilen.

Es ist ein bewusstes Kopplungsinstrument.

Das Muster reduziert Übersetzungskosten –
erhöht aber Koordinationsbedarf.

Shared Kernel ist nützlich, aber riskant.

Einordnung

Shared Kernel ist ein strategisches Context-Mapping-Pattern in DDD.

Es beschreibt:

  • bewusste Modellteilung
  • gemeinsame Ownership
  • abgestimmte Evolution

Es gehört zur Domänen- und Organisationsebene, nicht zur Infrastruktur.

Grundprinzip

Kernaussage:

  • Beide Kontexte teilen bewusst einen kleinen Kern
  • Änderungen am Kernel betreffen beide Seiten
  • Verantwortung ist geteilt

Charakteristika

1️⃣ Explizit begrenzter Scope​

Der Shared Kernel enthält:

  • stabile Begriffe
  • gemeinsame Value Objects
  • kleine, klar definierte Domänenkonzepte

Nicht:

  • komplette Subdomänen
  • komplexe Geschäftslogik
  • allgemeine Utility-Sammlungen

2️⃣ Gemeinsame Change-Kontrolle​

Änderungen erfordern:

  • Abstimmung
  • gemeinsame Versionierung
  • koordinierte Releases

3️⃣ Geteilte Verantwortung​

Beide Teams:

  • besitzen den Kernel
  • reviewen Änderungen
  • tragen Auswirkungen

4️⃣ Technische Isolation​

Best Practice:

  • eigener Artefakt / eigenes Repository
  • klare Paket-/Namespace-Grenzen
  • keine impliziten Seiteneffekte

Vorteile

  • Reduzierter Mapping-Aufwand
  • Konsistente Kernbegriffe
  • Schnellere Integration bei stabilen Konzepten
  • Vermeidung unnötiger Anti-Corruption Layer

Risiken / typische Fallstricke

1️⃣ Scope Creep​

Der Shared Kernel wächst langsam:

  • neue Utility-Klassen
  • Hilfsmethoden
  • zusätzliche Domänenlogik

Er wird zum „Common“-Monolith.

2️⃣ Release-Kopplung​

Jede Änderung:

  • erzeugt Synchronisationsaufwand
  • blockiert unabhängige Releases

3️⃣ Ownership-Konflikte​

Wer entscheidet?

  • Fachliche Richtung
  • Breaking Changes
  • Priorisierung

4️⃣ Versteckte Big Ball of Mud​

Ein übergroßer Shared Kernel zerstört die Vorteile von Bounded Contexts.

Wann sinnvoll?

  • Ein sehr stabiler fachlicher Kern existiert
  • Begriffe sind organisationsweit identisch
  • Teams arbeiten eng und vertrauensvoll
  • Änderungsfrequenz im Kernel ist niedrig

Wann problematisch?

  • Hohe Änderungsdynamik
  • Unterschiedliche fachliche Interpretationen
  • Starker Autonomie-Fokus
  • Fehlende Governance

In solchen Fällen ist ein Anti-Corruption Layer oft die bessere Wahl.

Vergleich zu anderen Patterns

PatternModellteilungÜbersetzungKopplung
Shared KernelJa (begrenzt)NeinMittel
ConformistJa (vollständig)NeinHoch
Anti-Corruption LayerNeinJaNiedrig
Customer–SupplierNeinNeinMittel

Strategische Perspektive

Shared Kernel ist:

  • schneller als vollständige Entkopplung
  • riskanter als explizite Übersetzung
  • stabilisierend bei reifen Domänen
  • gefährlich bei dynamischen Systemen

Er funktioniert nur, wenn:

  • der Scope klein bleibt
  • Governance klar ist
  • technische Isolation durchgesetzt wird

Fazit

Shared Kernel ist ein bewusstes Kopplungsinstrument.

Er sollte:

  • klein
  • stabil
  • explizit
  • streng kontrolliert

sein.

Wenn er wächst, ist das ein Architektursignal – kein Feature.