DDD Flashcards
Was ist Domain Driven Design?
Domain-driven Design (DDD) ist ein Ansatz in der Softwareentwicklung, der die Definition von Systemobjekten und -komponenten und deren Verhalten betont, damit sie die Realität getreu widerspiegeln. Erst nach der Erstellung eines solchen Modells sollten die Fragen der technischen Umsetzung berücksichtigt werden.
Wofür ist DDD gut geeignet? Für welche Arten von Software weniger?
• DDD ist eine Betrachtungsweise (mindset)
• Man kann mit dem Mindset an jedes Projekt rangehen
• DDD Scoreboard, je mehr es nur auf „Daten zentriert ist“ also bsp. CRUD operationenen und je weniger Logik, desto niedriger ist der Score auf Scoreboard
• Wenn Projekt viel Logik, Domänenwissen und Flexibiliät verlagt, desto höher ist Score auf Scoreboard
+ vereinfacht die Kommunikation: Alle Projekte bei denen es sehr wichtig ist, dass Verständnis und Kommunikation gut abläuft und es gemeinsames Verständnis jedes einzelne Teilnehmers gibt
+Flexibilität: Ist Modular und kann ausgetauscht werden
- Benötigt jemanden mit sehr gutem Domänenwissen
- Es funktioniert möglicherweise nicht am besten für hochtechnische Projekte. Domänengesteuertes Design eignet sich perfekt für Anwendungen mit komplexer Geschäftslogik. Es ist jedoch möglicherweise nicht die beste Lösung für Anwendungen mit geringer Domänenkomplexität, aber hoher technischer Komplexität.
Worum geht es beim „Tactical Design“ und wobei beim „Strategic Design“?
- Tactical DDD ist eine Reihe von Entwurfsmustern und Bausteinen, die Sie verwenden können, um domänengesteuerte Systeme zu entwerfen
- Im Vergleich zum strategischen domänengesteuerten Design ist das taktische Design viel praktischer und näher am eigentlichen Code.
- Strategisches Design befasst sich mit abstrakten Ganzheiten, während taktisches Design sich mit Klassen und Modulen befasst. Der Zweck des taktischen Designs besteht darin, das Domänenmodell so weit zu verfeinern, dass es in funktionierenden Code umgewandelt werden kann.
- Es wird auch als strategische Modellierung bezeichnet und ist eine Säule des DDD, dessen Hauptziel es ist, gemeinsam mit dem gesamten Projektteam die Bounded Contexts, die Ubiquitous Language und die Context Maps zu definieren
- Das taktische Design ist eine Reihe von technischen Ressourcen, die beim Aufbau Ihres Domänenmodells verwendet werden. Diese Ressourcen müssen angewendet werden, um in einem einzigen begrenzten Kontext zu funktionieren (enteties, value objects etc)
Entity -DDD
- Eine Entität ist ein potenziell veränderbares Objekt, das eine eindeutige Kennung hat. Entitäten haben ein Eigenleben innerhalb ihres Domänenmodells, was es Ihnen ermöglicht, die gesamte Übergangshistorie dieser Entität zu erhalten.
- Eine Entität ist ein Objekt, dessen Identität von Bedeutung ist. Um die Identität einer Entität bestimmen zu können, hat jede Entität eine eindeutige ID, die bei der Erstellung der Entität vergeben wird und während der gesamten Lebensdauer der Entität unverändert bleibt.
„Service“ -DDD
Services sind zustandslose Objekte, die eine Logik ausführen, die nicht zu einer Operation an einem Entitäts- oder Wertobjekt passt.
Sie führen domänenspezifische Operationen durch, an denen mehrere Domänenobjekte beteiligt sein können.
eg. Verleih Service eines Buches aus der Bib
„Aggregate“ -DDD
Es ist eines der wichtigsten und komplexesten Muster des taktischen Designs. Aggregate basieren auf zwei anderen taktischen Standards, nämlich Entitäten und Value Objects. Ein Aggregat ist ein Cluster aus einer oder mehreren Entitäten und kann auch Value Objects enthalten. Die übergeordnete Entität dieses Clusters erhält den Namen Aggregate Root.
Aufgabe: Erstelle ein taktisches Design (also: Modell(e)) für ein kleines
Anmeldesystem für Prüfungen (wie es StiSys bei uns ist).
Beschreibe 1 Building-Blocks Deiner Wahl aus dem Strategic Design
- Die Ubiquitous Language wird in einem begrenzten Kontext modelliert, in dem die Begriffe und Konzepte der Geschäftsdomäne identifiziert werden, in dem es keine Zweideutigkeit geben sollte. Um eine effiziente allgegenwärtige Sprache zu entwickeln, müssen Sie das Geschäft verstehen.
Einer der großen Vorteile der Ubiquitous Language besteht darin, die Domänenexperten, das technische Team und die anderen am Projekt Beteiligten zusammenzubringen. Ubiquitous Language sollte niemals eine Reihe von Begriffen und Fachjargons sein, die von Domänenexperten aufgezwungen werden, im Gegenteil, Ubiquitous Language wird im Einvernehmen des gesamten Teams entwickelt. Die allgegenwärtige Sprache muss jederzeit zwischen den Teammitgliedern gesprochen und im Softwaremodell ausgedrückt werden.
2.
Beschreiben einen weiteren Building Block aus Strategic Design
Context Maps:
Context Maps helfen beim Verständnis des gesamten Projekts, da sie die Beziehungen zwischen den verschiedenen Bounded Contexts zeigen können.
Es ist äußerst wichtig, die Beziehung zwischen Bounded Contexts zu verstehen, damit Sie ein Domänenmodell korrekt erstellen können.
Bsp: Shared Kernel,Customer / Supplier etc.
Core Domain
Eine Kerndomäne macht eine Organisation besonders und unterscheidet sie von anderen Organisationen. Eine Organisation kann nicht erfolgreich sein (oder überhaupt existieren), ohne in ihrem Kernbereich außergewöhnlich gut zu sein. Weil die Kerndomäne so wichtig ist, sollte sie die höchste Priorität, den größten Aufwand und die besten Entwickler erhalten. Bei kleineren Domänen können Sie nur eine Kerndomäne angeben, größere Domänen können mehr als eine haben. Sie sollten bereit sein, die Funktionen der Kerndomäne von Grund auf neu zu implementieren.
Supporting Domain
Eine unterstützende Subdomain ist eine Subdomain, die für den Erfolg der Organisation notwendig ist, aber nicht in die Kategorie der Kerndomains fällt. Es ist auch nicht generisch, da es immer noch ein gewisses Maß an Spezialisierung für die betreffende Organisation erfordert. Möglicherweise können Sie mit einer vorhandenen Lösung beginnen und diese optimieren oder auf Ihre spezifischen Anforderungen erweitern.
Generic Subdomain
Eine generische Subdomain ist eine Subdomain, die nichts Besonderes für die Organisation enthält, aber dennoch benötigt wird, damit die Gesamtlösung funktioniert. Sie können viel Zeit und Arbeit sparen, indem Sie versuchen, Standardsoftware für Ihre generischen Subdomains zu verwenden. Ein typisches Beispiel wäre die Benutzeridentitätsverwaltung.
DDD- Bounded Context
Der Bounded Context definiert den Einsatzbereich eines Domänenmodells. Es umfasst die Geschäftslogik für eine bestimmte Fachlichkeit. Als Beispiel beschreibt ein Domänenmodell die Buchung von S-Bahn-Fahrkarten und ein weiteres die Suche nach S-Bahn-Verbindungen. Da die beiden Fachlichkeiten wenig miteinander zu tun haben, sind es zwei getrennte Modelle. Für die Fahrkarten sind die Tarife relevant und für die Verbindung die Zeit, das Fahrziel und der Startpunkt der Reise.
Außerdem soll der Bounded Context den Gültigkeitsbereich einer sogenannten Ubiquitous Language festlegen. Die Bezeichnung lässt sich mit allgegenwärtige Sprache übersetzen und beschreibt eine Menge von Begriffen, die Domänenexperten verwenden und die für Softwareartefakte wie Code oder Datenbank-Schemata genutzt werden sollen. Beispielsweise erschließt sich die Bedeutung des Begriffs „Taktverstärker“ nicht sofort, den die Münchener Verkehrsbetriebe für zusätzliche S-Bahn-Züge zu den Stoßzeiten verwenden. Ein System für die Münchner S-Bahn sollte daher einen Taktverstärker als Klassennamen im Code und als Name einer Tabelle im Datenbank-Schema verwenden. Das Beispiel zeigt, dass die Ubiquitous Language ohne Wissen über den fachlichen Kontext nicht zu verstehen ist.
Ein Bounded Context sollte in den Zuständigkeitsbereichs genau eines Teams fallen. Ein Team kann für mehr als ein Bounded Context zuständig sein, aber umgekehrt sollten nicht mehrere Teams an einem Bounded Context arbeiten, da das Vorgehen zu viel Abstimmung erfordert.
Somit ist ein Bounded Context ein Gültigkeitsbereich eines Domänenmodells, einer Ubiquitous Language und die Basis für die Organisation des Projekts.
Wozu dient eine Context-Map?
• Mit Hilfe von Context Mapping soll im Diagramm, also der Context Map, visualisiert werden, welche Beziehungen zwischen den vorhandenen Bounded Contexts besteht
Finde Beispiele dazu im Kontext deines Hochschul IT Programms? (context map)
Welche Beziehungen gibt es in einer Context-Map? Finde Beispiele im Kontext Deines
Hochschul-IT-Projekts.
- Shared Kernel
Ein gemeinsamer Kontext zwischen zwei oder mehr Teams, der die Duplizierung von Code reduziert, jedoch müssen alle Änderungen kombiniert und zwischen den Teams benachrichtigt werden. - Customer / Supplier
Es ist eine Beziehung zwischen Client (Downstream) und Server (Upstream), in der die Teams kontinuierlich integriert sind. - Conformist
Es ist das Szenario, das die Upstream- und Downstream-Teams einbezieht, aber in diesem Modell hat das Upstream-Team keine Motivation, die Bedürfnisse des Downstream-Teams zu erfüllen. (e.g. APIs) - Partner
Es ist das Szenario, in dem Teams abhängig sind und eine kooperative Beziehung haben müssen, damit sie die Entwicklungsanforderungen beider Systeme erfüllen können. - Anti Corruption Layer
Wie im Fall des konformistischen Musters sind die Machtverhältnisse in diesem Verhältnis immer noch in Richtung des vorgelagerten Dienstes verzerrt. In diesem Fall ist der nachgeschaltete begrenzte Kontext jedoch nicht bereit, sich anzupassen. Stattdessen kann er das Modell des vorgelagerten Bounded Context in ein Modell übersetzen, das auf seine eigenen Bedürfnisse zugeschnitten ist, und zwar über eine Antikorruptionsschicht. - Open-Host Service
Dieses Muster spricht den Fall an, in dem die Leistung auf die Verbraucher gerichtet ist. Der Lieferant ist daran interessiert, seine Verbraucher zu schützen und den bestmöglichen Service zu bieten.
Um die Verbraucher vor Änderungen in seiner Implementierung zu schützen, entkoppelt der Upstream-Lieferant sein Implementierungsmodell von der öffentlichen Schnittstelle. Diese Entkopplung ermöglicht es dem Anbieter, seine Implementierung und öffentliche Modelle mit unterschiedlichen Raten weiterzuentwickeln
- Seperate Ways
Die letzte Kollaborationsoption ist natürlich, überhaupt nicht zu kollaborieren. Dieses Muster kann aus verschiedenen Gründen entstehen, wenn die Teams nicht bereit oder in der Lage sind, zusammenzuarbeiten. Wir werden uns hier einige davon ansehen.
Taktisches Design Beispiel
Mit enteties, value objects etc. –> Technischer
Bounded Contexts sowie eine Context-Map
Eine Kontextkarte ist die globale Ansicht der Anwendung als Ganzes. Jeder begrenzte Kontext passt in die Kontextkarte, um zu zeigen, wie sie miteinander kommunizieren und wie Daten geteilt werden sollten
Bounded Context ist ein sehr wichtiges Modellierungswerkzeug, wenn es um Domain Driven Development geht.
Mit Bounded Contexts können Sie ein großes Problem in viel kleinere Probleme aufteilen, sodass Sie sich auf bestimmte Aspekte der Anwendung konzentrieren und alles andere ignorieren können.
Auf diese Weise können Sie eine einheitliche Sprache für dieses spezifische Problem bilden, sodass jeder eine klare Definition aller wichtigen Begriffe hat.
Typischerweise gibt es bestimmte Objekte in einer Webanwendung, die in verschiedenen Kontexten der Anwendung unterschiedliche Definitionen haben. Indem Sie die Anwendung in Kontextgrenzen aufteilen, stellen Sie sicher, dass die Grenzen zwischen den einzelnen Kontexten klar definiert sind, sodass die Terminologie rund um Ideen und Konzepte der Anwendung klar verstanden wird.
Wenn Sie sich jedoch auf die Details konzentrieren, können Sie oft das Gesamtbild der Anwendung aus den Augen verlieren. Eine Kontextkarte sollte zeigen, wo sich jeder Bounded Context im Verhältnis zu den anderen befindet. In den Assoziationen von Bounded Contexts stecken oft viele wichtige Informationen und so sorgt eine Context Map dafür, dass Wissen nicht durch die Lücken fällt.
