9. April 2026
Die Sache mit den Entities: Braucht es ein explizites Mapping zwischen Domänen- und DB-Entities?
Die Frage, ob Domänen- und Persistenzmodelle strikt getrennt werden sollten, gehört zu den Dauerbrennern moderner Softwarearchitektur. Besonders im Kontext von domänenzentrierten Architekturen und Domain-Driven Design (DDD) wird häufig gefordert, ein explizites Mapping zwischen Domänen-Entities und Datenbank-Entities einzuführen. Doch ist dieser zusätzliche Aufwand immer gerechtfertigt?
Domänenzentrierte Architekturen
Domänenzentrierte Architekturen stellen die Fachlichkeit in den Mittelpunkt. Statt die Struktur der Anwendung von technischen Aspekten wie Datenbanken oder Frameworks bestimmen zu lassen, wird das Modell der Fachdomäne zum zentralen Orientierungspunkt. Architekturansätze wie Hexagonale Architektur, Onion Architecture oder Clean Architecture folgen diesem Prinzip: Der Domänenkern ist unabhängig von Infrastruktur und technischen Details.
Das Ziel ist klar: Fachliche Logik soll isoliert, verständlich und langfristig wartbar sein.
Taktisches DDD
Das taktische DDD liefert konkrete Bausteine für die Modellierung des Domänenkerns. Dazu gehören insbesondere:
- Entities mit Identität
- Value Objects ohne Identität
- Aggregate als Konsistenzgrenzen
- Repositories zur Abstraktion von Persistenz
Ein zentrales Prinzip ist, dass diese Konzepte rein fachlich motiviert sind und keine technischen Details enthalten sollten.
Java Persistence API
Java Persistence API (JPA) ist ein Standard zur Abbildung von Java-Objekten auf relationale Datenbanken (ORM). Entwickler annotieren Klassen mit Metadaten, die beschreiben, wie Objekte persistiert werden:
JPA übernimmt dann das Mapping zwischen Objekten und Datenbanktabellen.
Implementierung nach der reinen Lehre
Nach der „reinen“ DDD-Lehre sollte der Domänenkern vollständig frei von Infrastruktur sein. Das bedeutet konkret:
- Keine JPA-Annotationen in Domain-Klassen
- Separate Persistenz-Entities
- Explizites Mapping zwischen Domain- und DB-Modell
Beispiel:
Diese Trennung sorgt für maximale Unabhängigkeit – bringt aber auch erheblichen Boilerplate-Code mit sich.
Alternative ohne Mapping
Eine pragmatische Alternative besteht darin, Domain- und Persistenzmodell zu vereinen. Die Domänenklassen werden direkt mit JPA annotiert:
Das reduziert Komplexität und vermeidet Mapping-Code – erkauft sich aber eine stärkere Kopplung an JPA.
Auswirkungen auf Testbarkeit
Ein häufig unterschätzter Aspekt ist die Testbarkeit.
Unit-Tests können grundsätzlich ohne Server laufen – aber nur, wenn JPA-Annotationen rein additiv verwendet werden. Sobald sich Verhalten implizit durch JPA ergibt, wird es problematisch.
Ein klassisches Problem ist versteckte Logik durch JPA. Lazy Loading oder Lifecycle Callbacks führen dazu, dass sich Objekte im Test anders verhalten als zur Laufzeit:
Im Test ist items möglicherweise leer oder nicht initialisiert, während zur Laufzeit ein Proxy geladen wird. Ähnliches gilt für @PostLoad oder @PrePersist.
Die Konsequenz: Tests müssen entweder JPA verstehen oder simulieren – was dem Gedanken von schnellen, isolierten Unit-Tests widerspricht.
Eine robuste Alternative ist, das Domänenmodell so zu gestalten, dass es nicht von JPA-Verhalten abhängt:
- Alle Felder werden explizit initialisiert
- Kein Vertrauen auf Lazy Loading
- Kontrollierte Mutationen über Methoden wie addItem()
So bleibt das Verhalten deterministisch – unabhängig von der Persistenz.
Ein weiteres Problem: JPA beeinflusst das Code-Design.
JPA fordert beispielsweise No-Args-Konstruktoren:
Dadurch können Invarianten nicht mehr vollständig im Konstruktor abgesichert werden.
Zudem verlangt JPA oft veränderliche Felder, was insbesondere bei Value Objects problematisch ist. Immutable Objekte lassen sich nur eingeschränkt abbilden, was zu Kompromissen im Design führt.
Auswirkungen auf unabhängige Weiterentwicklung von Domänenkern und Infrastruktur
Wird JPA direkt im Domänenmodell verwendet, entsteht eine implizite Kopplung. Diese zeigt sich besonders dann, wenn provider-spezifische Features genutzt werden:
Solche Annotationen binden den Code an einen konkreten JPA-Provider und erschweren Migrationen oder Refactorings erheblich.
Ein strikt getrenntes Modell vermeidet diese Probleme – ist aber teurer in der Umsetzung.
Fazit und Empfehlung
Die Entscheidung für oder gegen ein explizites Mapping ist kein dogmatisches Entweder-oder.
Für viele Projekte ist es sinnvoll, pragmatisch zu starten und Domain- und Persistenzmodell zu kombinieren – solange man sich der Konsequenzen bewusst ist und Disziplin im Umgang mit JPA wahrt.
Steigt die Komplexität oder werden die Nachteile spürbar, kann ein Refactoring hin zu getrennten Modellen erfolgen.
Ein wichtiger Sicherheitsanker ist testgetriebene Entwicklung: Wenn der Code konsequent durch Tests getrieben ist, bleibt er zwangsläufig testbar – unabhängig von der gewählten Architektur.
jMolecules
Das Projekt jMolecules bietet einen interessanten Mittelweg. Es stellt Annotationen und Interfaces bereit, um DDD-Konzepte explizit im Code zu modellieren, ohne sich an eine konkrete Persistenztechnologie zu binden.
Beispiel:
Diese Annotationen sind rein semantisch und haben zunächst keinen technischen Effekt. Über Integrationen (z. B. mit JPA oder Spring Data) kann später eine konkrete Persistenz angebunden werden.
Damit ermöglicht jMolecules eine klare Trennung auf konzeptioneller Ebene – ohne sofort den vollen Aufwand eines separaten Persistenzmodells zu erzwingen.
Am Ende bleibt die Erkenntnis: Es gibt keine universell richtige Lösung. Entscheidend ist, die Trade-offs bewusst zu verstehen und die Architektur so zu wählen, dass sie zur Komplexität des Systems passt.