Vorlesung 4: Methoden für den Architekturentwurf/design Flashcards
Erkläre: Bereichsorientiertes Design (Domain-Driven Design): Der Unternehmensbereich.
▪ Der Entwurf eines Systems sollte mit dem Entwurf der Geschäftsdomäne beginnen
▪ Domain-Driven Design (DDD), vorgeschlagen von Eric Evans, ist ein weit verbreiteter Standard
▪ DDD konzentriert die Entwicklung auf das Domänenmodell, das ein umfassendes Verständnis der
Geschäftsprozesse und Regeln einer Domäne widerspiegelt
▪ DDD bietet:
- Eine Mustersprache, die verwendet werden kann, um die Domäne auszudrücken
- Konzeptionelle Elemente, die über reine Modellierungsnotationen hinausgehen
▪ DDD betont die Schaffung einer allgegenwärtigen Sprache für eine Domäne, die sich im Code widerspiegeln sollte
- Erleichterung der Kommunikation zwischen Fachleuten und Technikern
- Unterstützung der Fachexperten bei der Formulierung ihrer Anforderungen
- Erleichtert die Testbarkeit (direkte Verbindung zwischen Domäne und Code)
▪ DDD unterscheidet zwischen strategischem und taktischem Design
Erkläre: Bereichsorientiertes Design (Domain-Driven Design): strategisches Design
▪ Der Kern von DDD ist die Aufteilung der gesamten Geschäftsdomäne in verschiedene begrenzte Kontexte
▪ Die Aufteilung der Domäne ist aus mehreren Gründen ratsam:
- Größere Domänen lassen sich nur schwer in einem einheitlichen Modell abbilden
- Unterschiedliche Personengruppen werden unterschiedliche Vokabularien verwenden, um identische Dinge auszudrücken (insbesondere Polyseme sind problematisch)
▪ Verschiedene begrenzte Kontexte haben…
- gemeinsame Konzepte (z.B. Kunden, Produkte) und
- nicht verwandte Konzepte (z. B. Support-Tickets, die nur in einem
einem Support-Kontext).
▪ Die Namen der gemeinsamen Konzepte können zwischen den
Kontexten variieren
▪ Kontextgrenzen werden in erster Linie durch menschliche /
Organisationskultur (d.h. ihre Sprache)
Sieh dir die Abbildung zu: Domain-Driven Design: Strategic Design Patterns an.
Bitte erkläre die Domain-Driven Design: Integration Strategies
Shared Kernel:
Beide Kontexte teilen eine gemeinsame Codebasis (Kernel).
Änderungen im Kernel müssen zwischen den betreuenden Teams koordiniert werden.
Führt zu organisatorischen Abhängigkeiten zwischen den Teams.
Customer-Supplier:
Abgegrenzte Kontexte haben eine Upstream-Downstream-Beziehung.
Das Upstream-Team ist der Lieferant und das Downstream-Team der Kunde.
Das Upstream-Team muss die Anforderungen des Downstream-Teams berücksichtigen.
Conformist:
Abgegrenzte Kontexte haben ebenfalls eine Upstream-Downstream-Beziehung.
Das Upstream-Team kümmert sich nicht um die Anforderungen des Downstream-Teams.
Das Downstream-Team nutzt das Modell des Upstream-Teams.
Open Host Service:
Das System stellt klar definierte Service-Schnittstellen bereit.
Die Schnittstellen sind offen, sodass jedes andere System sie nutzen kann.
Separate Ways:
Die Kosten für die Integration zweier abgegrenzter Kontexte sind höher als der Nutzen.
Es wird keine Integration durchgeführt.
Anticorruption Layer:
Abgegrenzte Kontexte haben eine Upstream-Downstream-Beziehung.
Das Upstream-Team kümmert sich nicht um die Anforderungen des Downstream-Teams.
Das Downstream-Team erstellt eine Schicht, die das Domänenmodell übersetzt.
erkläre: Domain-Driven Design: Tactical Design
▪ Taktisches Design ist die Konkretisierung / Differenzierung eines begrenzten Kontextes
▪ Taktisches Design ist eher “hands-on” / “low-level”
▪ Taktisches Design kann sich direkt im Code widerspiegeln (ist sehr nah am tatsächlichen Code)
▪ Muster des taktischen Entwurfs erlauben die Verwendung von allgegenwärtiger Sprache im Code
▪ DDD betont die Isolierung von begrenzten Kontexten auf Architekturebene und
begünstigt eine schichtweise Architektur
Sieh dir diese Abbildung an
Entities:
Kernobjekte der Geschäftsdomain.
Haben eine eindeutige Identität und einen Lebenszyklus.
Value Objects:
Haben keine eigene Identität, sondern beschreiben den Zustand anderer Objekte.
Können aus anderen Value Objects bestehen, jedoch niemals aus Entities.
Domain Events:
Repräsentieren (vergangene) Ereignisse in der Domain.
Implizieren Zustandsänderungen der zugehörigen Entities.
Aggregates:
Gruppe von Entities und Value Objects mit konsistentem Zustand.
Ein Aggregate wird immer von einer Entity, dem sogenannten Aggregate Root, besessen (nur das Root kann von außen referenziert werden).
DDD Taktische Designmuster: Objektmanagement
Services:
Enthalten die Geschäftslogik (z.B. Regeln, Prozesse) der Domain.
Haben keinen eigenen Zustand.
Verarbeiten Domain-Objekte (Entities, Value Objects, Events oder Aggregates).
Repositories:
Verantwortlich für das Speichern (d.h. Zustand persistieren), Abrufen oder Löschen von Aggregates.
Bieten eine Abstraktion zur Datenspeicherung.
Factories:
Bieten eine Abstraktion bei der Erstellung eines Domain-Objekts.
Können Aggregate Roots, Entities oder Value Objects erstellen.
Layered Architecture:
Presentation Layer
Application Layer
Domain Layer
Infrastructure Layer
