Domain Driven Design
Grundwissen zum Thema Domain Driven Design im Kontext von Softwarearchitekturen
Grundwissen zum Thema Domain Driven Design im Kontext von Softwarearchitekturen
-
- 1 / 24
-
Lernkarten
Warum wird Software entwickelt?
In der Regel um ein fachlches, reales Problem zu lösen.
Warum wird Software entwickelt?
Warum ist es wichtig, ein Fachverständnis zu entwickeln, bevor man Software entwickelt?
Um Software zielgerichet entwickeln zu können, d.h. die Software so zu gestalten, dass die Software fachspezifische Probleme effektiv lösen kann.
Welches Problem löst Domain Driven Design?
Was versteht man unter einem "Command" im Domain Driven Design?
Der Auftrag eines Anwenders an ein System, auf den reagiert werde soll.
- Meist im Imperativ formuliert.
- Beinhaltet dazugehörige Daten (fachlich) und Metadaten (technisch)
Beispiel: Cancel Order #1
Folgende Aussagen sind wahr:
Ein Command...
Was ist ein "Domain Event"?
Die Reaktion des Systema auf einen Command.
Events informieren immer in der Vergangenheitsform über ein Ereignis.
Im englischen ist die Reihenfolge der Worte wichtig. Das Verb muss immer hinten stehen.
Ein Command muss immer ein Event nach sich ziehen.fal
Ein Command kann unterschiedliche Events nach sich ziehen.
Ein Command kann mehrere Events nach sich ziehen.
Welche Mengenbeziehung besteht zwischen Command und Event?
m:n
Nenne zwei Beispiele für Metadaten, die ein Event enthalten kann.
- Initiator
- Zeitpunkt des Events
An wen werden Events gesendet?
Was beschreiben Events?
Eine Tatsache, die geschehen ist und nicht mehr rückgängig gemacht werden kann, ohne einen weiteren Command zu senden.
Was sind die drei Grundbausteine von DDD?
Was stellt der State dar?
Den aktuallen Status aller funktionalen Objekte.
Welche Anforderungen gibt es an den State?
Was ist ein "Aggregate"?
Ein Hülle, die fachliche zusammengehörige Commands, Events und States zusammenfasst.
Eine transaktionale Grenze.
Welche Aufgabe haben "Aggregates"?
Wie groß sollten Aggregates sein?
So groß wie nötig und so klein wie möglich.
Was ist ein Bounded Context?
Eine Sprachgrenze um Missverständnisse in der Verwendung von Begriffen zu vermeiden, die in verschiedenen Kontexten unterschiedliche Bedeutungen haben können.
Beispiel: Im persönlichen Kontext verstehen wir unter Urlaub das erholsame Verweilen an einem Ort inklusive der Abwesenheit von Erwerbsarbeit. Im einer HR-Abteiltung verstehen wir unter Urlaub allerdings die Anzahl der Tage, die einem Arbeitnehmer zur Verfügung stehen und deren Status (genommen/verfügbar/verfallen etc.)
Sprache im Domain Driven Design ist immer kontextabhängig.
