Factory
Eine Factory bündelt komplexe oder fachlich bedeutsame Erzeugung, ohne Zustandsänderungen nach der Erzeugung zu übernehmen.
- EingabenKunde, Positionen und Adresse.
- FactoryPrüft Vorbedingungen und erzeugt.
- AggregateStartet in gültigem Zustand.
Einordnung
Warum das wichtig ist
Gültige Domänenobjekte mit expliziten Erzeugungsbedingungen herstellen.
Erzeugung neuer Entities oder Aggregate und Prüfung ihrer Startbedingungen.
Factory und direkte Konstruktion
Die Bestellfactory erstellt das Aggregat; das Repository speichert es. Beide gehören zum Bestellmodul.
So liest du das Bild
- Eingaben Bestelldaten
- Factory Konstruktion
- Aggregate gültiger Anfang
| Kriterium | Situation | Geeignete Form |
|---|---|---|
| Einfache Werte | Konstruktor | Wenige Regeln |
| Aggregate mit Regeln | Factory | Geprüfte Startbedingungen |
Nutzen & Grenzen
Hilft, wenn
- Die Erzeugung bündelt mehrere fachliche Vorbedingungen oder setzt ein Aggregat aus mehreren gültigen Bestandteilen zusammen.
- Aufrufer sollen ein vollständig gültiges Objekt erhalten, ohne interne Konstruktionsschritte oder konkrete Implementierung kennen zu müssen.
Grenzen
- Bei einem Objekt mit wenigen klaren Pflichtwerten bleibt ein Konstruktor leichter verständlich und wartbar.
- Eine Factory entscheidet über den gültigen Anfangszustand; Persistenz, Wiederauffinden und spätere Änderungen gehören zu anderen Bausteinen.
In der Praxis
- Bestimme, welche Vorbedingungen ein neues Objekt beim Entstehen erfüllen muss, und formuliere diese als fachliche Erzeugungsregel statt als Sammlung technischer Setter.
- Nutze eine Factory, wenn ein Aggregat aus mehreren Objekten entsteht oder die konkrete Implementierung für Aufrufer verborgen bleiben soll. Bei einfacher, eindeutiger Erzeugung genügt ein Konstruktor.
- Gib ein vollständig gültiges Objekt zurück und teste ungültige Eingaben, Grenzwerte sowie jede fachliche Startbedingung. Halte Speicherzugriff und spätere Zustandsänderungen außerhalb des Erzeugungsvertrags.
Ausführliche Erklärung lesen
Die Factory kann ein einzelnes Objekt oder ein zusammengesetztes Aggregat erzeugen. Ihre Aufgabe endet nach der gültigen Konstruktion; Persistenz und spätere Zustandsänderungen liegen bei anderen Bausteinen.
Eine Factory ist sinnvoll, wenn Vorbedingungen oder Zusammensetzung erklärungsbedürftig sind. Ein einfacher Konstruktor bleibt die bessere Wahl, wenn er dieselbe Gültigkeit direkt und lesbar sicherstellt.
Die Factory erzeugt das Aggregate mit gültigem Anfangszustand; ein Repository übernimmt anschließend den Speicherzugriff.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welche Eingangsdaten nutzt die Bestellfactory?
Lösung mit Begründung ansehen
Kunde, Positionen und bestätigte Lieferadresse.
AnwendenAuf eine neue Lage übertragen
Ein einfacher unveränderlicher Wert braucht keine Vorbedingungen. Welche Erzeugung reicht?
Lösung mit Begründung ansehen
Ein direkter Konstruktor.
BewertenEine Alternative abwägen
Wann schafft eine Factory einen klaren fachlichen Nutzen?
Lösung mit Begründung ansehen
Wenn sie mehrere gültige Startbedingungen bündelt oder eine komplexe Erzeugung verständlich benennt.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Eric Evans · DDD Reference (öffnet in neuem Tab)Primärreferenz zu Repository- und Factory-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 taktischen DDD-Bausteinen und Beispielen.