Domain Service
Ein Domain Service macht eine domänensprachliche Operation sichtbar, die mehrere fachliche Werte verbindet.
- FaktenWerte der fachlichen Regel.
- OperationBenannte Entscheidung.
- ErgebnisFachlich verständliche Ausgabe.
Einordnung
Warum das wichtig ist
Fachliche Regeln ohne natürlichen Objektbesitzer präzise modellieren und unabhängig prüfen.
Fachliche Berechnung mit expliziten Eingaben; Infrastruktur und Prozesskoordination bleiben eigene Zuständigkeiten.
Objektverhalten oder Domain Service
Die Versandfähigkeitsregel prüft Werte aus Bestellung, Katalog und Versandoptionen innerhalb des Sieben-Modul-Shops.
So liest du das Bild
- Fakten Eingaben
- Operation Regel
- Ergebnis Antwort
| Kriterium | Regel | Geeigneter Ort |
|---|---|---|
| Direkte Invariante | Entity oder Value Object | Entity oder Value Object |
| Mehrere Fakten | Domain Service | Domain Service |
Nutzen & Grenzen
Hilft, wenn
- Eine Entscheidung verbindet Fakten mehrerer Objekte und gehört keinem davon allein.
- Eine fachliche Operation braucht einen klaren, unabhängig prüfbaren Vertrag.
Grenzen
- Ein Service pro Entity erzeugt prozedurale Schichten und verteilt zusammengehörige Regeln.
- Infrastrukturaufrufe und Prozesssteuerung gehören in passende Anwendungs- oder Integrationsbausteine.
In der Praxis
- Formuliere die Regel in der Sprache der Fachleute als Entscheidung mit klarer Eingabe und Ergebnis. Notiere außerdem, welche fehlenden oder widersprüchlichen Werte eine fachliche Antwort erfordern.
- Prüfe zunächst, ob eine Entity oder ein Value Object alle relevanten Fakten besitzt und die Regel als eigenes Verhalten ausdrücken kann. Erst wenn kein Objekt der natürliche Besitzer ist, ziehe einen Domain Service heran.
- Gib die übrigen Fakten über einen schmalen Vertrag hinein und liefere ein fachlich benanntes Ergebnis zurück. Teste Grenzfälle ohne Datenbank oder Netzwerk und halte Seiteneffekte in einer passenden Anwendungsschicht.
Ausführliche Erklärung lesen
Der Service beschreibt eine Operation wie „Versandfähigkeit bestimmen“. Er erhält die Fakten, die er für die Regel benötigt, und liefert ein fachliches Ergebnis zurück. Er trägt keinen langlebigen eigenen Zustand und versteckt keine Datenbank- oder Netzwerkzugriffe.
Gehört die Regel eindeutig zu einer Entity oder einem Value Object, bleibt sie dort. Regeln über mehrere Konsistenzgrenzen benötigen eine bewusst gestaltete Prozesskoordination. Ein Domain Service ist weder ein allgemeiner Anwendungsschritt noch automatisch ein verteilter Transaktionsmanager.
Prüfe zuerst, ob die Regel zu einer Entity oder einem Value Object gehört; die Konsistenzgrenze erklärt das Aggregate.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welche Fakten prüft die Shopregel?
Lösung mit Begründung ansehen
Gewicht, Lieferregion und Versandart.
AnwendenAuf eine neue Lage übertragen
Eine Regel gehört natürlich zum Warenkorb. Wo liegt sie?
Lösung mit Begründung ansehen
Als Verhalten des passenden Warenkorbobjekts.
BewertenEine Alternative abwägen
Wann ist eine separate Domain Service gerechtfertigt?
Lösung mit Begründung ansehen
Wenn kein Objekt die Operation natürlich besitzt und Eingaben sowie Ergebnis fachlich klar sind.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Eric Evans · DDD Reference (öffnet in neuem Tab)Primärreferenz zu taktischen DDD-Mustern.
- DDD Referenz · Übersetzung (öffnet in neuem Tab)Deutsche Fassung der Referenz von Eric Evans.
- Vaughn Vernon · Implementing Domain-Driven Design (öffnet in neuem Tab)Vertiefung zu Modellierung und Domänenverhalten.