Glossar

Begriff	Definition	Beispiel
ACID Properties	ACID steht für die vier grundlegenden Eigenschaften einer Transaktion: Atomicity (Atomarität), Consistency (Konsistenz), Isolation (Isolation) und Durability (Dauerhaftigkeit).	Ein Bankensystem stellt sicher, dass Überweisungen nach den ACID-Eigenschaften durchgeführt werden, sodass keine Gelder verloren gehen, selbst wenn das System abstürzt.
Aggregate	Ein Aggregate ist eine Gruppe von zusammenhängenden Entitäten und Werten, die als eine Einheit behandelt werden. Es stellt sicher, dass Geschäftsregeln innerhalb des Aggregates eingehalten werden.	Ein Order-Aggregate enthält Bestellpositionen und Zahlungsinformationen.
Aggregate Root	Die Aggregate Root ist die zentrale Entität innerhalb eines Aggregates, über die alle Operationen (z. B. Hinzufügen, Löschen) durchgeführt werden. Sie verwaltet die Konsistenz des Aggregates.	Order ist die Aggregate Root des Order-Aggregates.
Anti-Corruption Layer (ACL)	Ein Anti-Corruption Layer ist eine Schicht, die die Kommunikation zwischen verschiedenen Bounded Contexts erleichtert, ohne dass der Code in einem Kontext von einem anderen "korrumpiert" wird.	Ein PaymentAdapter könnte als Anti-Corruption Layer fungieren, um die Kommunikation zwischen dem SalesBoundedContext und einem externen Zahlungsanbieter zu ermöglichen.
Bounded Context	Ein Bounded Context ist ein klar definierter Bereich innerhalb einer Anwendung, in dem ein bestimmtes Modell und eine gemeinsame Sprache verwendet werden. Es hilft, verschiedene Teile eines Systems voneinander zu trennen.	Ein SalesBoundedContext, in dem die Verkaufslogik für Bestellungen und Kunden definiert ist, getrennt vom InventoryBoundedContext, der sich mit Lagerbeständen befasst.
Command	Ein Command ist eine Anweisung, die eine Veränderung des Systems bewirken soll. Commands sind meistens von außen initiierte Aktionen.	Ein PlaceOrderCommand, das eine neue Bestellung in einem System auslöst.
Consistency Boundary	Die Consistency Boundary bezeichnet die Grenze innerhalb eines Systems, bei der alle relevanten Daten in einer konsistenten Weise miteinander verbunden sind. Sie wird häufig mit Aggregaten und Transaktionen in Verbindung gebracht.	Das Order-Aggregate hat eine Konsistenzgrenze: Änderungen an den Bestellpositionen müssen sicherstellen, dass keine ungültigen Bestellungen entstehen.
Context Map	Eine Context Map ist eine Darstellung der Beziehungen zwischen verschiedenen Bounded Contexts innerhalb einer Anwendung und zeigt, wie sie miteinander kommunizieren.	Eine Karte, die zeigt, dass der SalesBoundedContext mit dem PaymentBoundedContext kommuniziert, um Zahlungen zu verarbeiten.
CQRS (Command Query Responsibility Segregation)	CQRS ist ein Muster, das die Trennung von Lese- und Schreiboperationen in ein System fordert. Ein Teil des Systems ist für das Schreiben zuständig (Commands), ein anderer für das Lesen (Queries).	Ein System, das CQRS verwendet, hat separate Komponenten für das Erstellen und Abfragen von Bestellungen.
DAO (Data Access Object)	Ein DAO ist eine Designpattern, das den Zugriff auf die Datenbank kapselt und CRUD-Operationen (Create, Read, Update, Delete) bereitstellt. DAO kümmert sich um die Datenpersistenz.	Ein UserDAO, das einfache Methoden wie save(), findById(), delete() für eine User-Entität bereitstellt.
Database Migration	Eine Datenbankmigration ist der Prozess, bei dem die Struktur einer Datenbank über Zeit verändert wird, oft durch das Erstellen von neuen Tabellen oder das Aktualisieren bestehender Strukturen.	Die Flyway-Bibliothek kann verwendet werden, um Datenbankmigrationen zu verwalten, wenn sich das Datenbankschema während der Entwicklung ändert.
Dependency Injection	Dependency Injection (DI) ist ein Entwurfsmuster, bei dem Objekte ihre Abhängigkeiten (z. B. Services, Repositories) zur Laufzeit von außen erhalten, anstatt sie selbst zu erzeugen.	In einer Spring-Anwendung wird der OrderService durch DI mit einem OrderRepository ausgestattet.
Domain Event	Ein Domain Event ist ein Ereignis, das eine wichtige Veränderung im Zustand der Domäne darstellt und häufig in einer anderen Umgebung (z. B. ein anderes System) behandelt wird.	Ein OrderPlacedEvent, das ausgelöst wird, wenn eine Bestellung erfolgreich abgeschlossen wurde.
Entity	Eine Entity ist ein Objekt, das eine eindeutige Identität hat und im Laufe der Zeit verändert werden kann. Der Zustand einer Entity kann sich ändern, aber ihre Identität bleibt immer gleich.	Ein User-Objekt in einer Anwendung, das durch eine Benutzer-ID eindeutig identifiziert wird.
Event Sourcing	Event Sourcing ist ein Muster, bei dem alle Änderungen des Systemzustands als eine Serie von Ereignissen (Domain Events) gespeichert werden, anstatt den aktuellen Zustand direkt zu speichern.	Bei einer Bestellung werden alle OrderPlacedEvent, ItemAddedEvent und PaymentProcessedEvent gespeichert, anstatt nur die aktuellen Bestelldaten.
Eventual Consistency	Eventual Consistency ist ein Prinzip, bei dem das System nach einer gewissen Zeit in einen konsistenten Zustand zurückkehrt, auch wenn während der Operationen vorübergehende Inkonsistenzen bestehen können.	In einem verteilten System kann es zu einer vorübergehenden Inkonsistenz zwischen verschiedenen Services kommen, aber nach einiger Zeit wird das System wieder konsistent.
Factory	Eine Factory ist eine Domänenklasse, die für die Erstellung von Aggregaten oder Entitäten verantwortlich ist, insbesondere wenn die Erstellung komplex ist oder viele Schritte erfordert.	Eine OrderFactory, die neue Bestellungen unter Berücksichtigung von Geschäftsregeln erstellt.
Read Model	Ein Read Model ist eine speziell gestaltete Repräsentation der Daten, die für Leseoperationen optimiert ist. Häufig wird es im Zusammenhang mit CQRS (Command Query Responsibility Segregation) verwendet.	Ein OrderReadModel, das alle relevanten Daten für die Anzeige der Bestellung im UI enthält.
Repository	Ein Repository ist eine Schnittstelle, die für das Abrufen und Speichern von Aggregaten verantwortlich ist. Es kapselt den Zugriff auf die Persistenzschicht.	Ein OrderRepository, das Order-Aggregates aus der Datenbank abruft und speichert.
Saga	Eine Saga ist ein langfristiger Geschäftsprozess, der aus einer Reihe von lokalisierten Transaktionen besteht. Wenn eine Transaktion fehlschlägt, müssen alle vorherigen Transaktionen rückgängig gemacht werden.	Eine OrderProcessingSaga, die aus mehreren Schritten wie Bestellannahme, Lagerreservierung und Zahlungsabwicklung besteht.
Service	Ein Service ist eine Domänenklasse, die Geschäftslogik kapselt, die nicht natürlich zu einer Entity oder einem Value Object gehört.	Ein PaymentService, der die Logik zur Verarbeitung von Zahlungen enthält.
Transaction	Eine Transaktion stellt sicher, dass eine Reihe von Datenbankoperationen als atomare Einheit ausgeführt werden. Entweder alle Operationen werden erfolgreich ausgeführt oder keine.	Eine OrderTransaction, die das Erstellen einer Bestellung und das Hinzufügen von Bestellpositionen in einer einzigen Transaktion durchführt.
Ubiquitous Language	Eine Ubiquitous Language ist eine Sprache, die von allen Beteiligten (Entwickler, Domänenexperten, Stakeholder) verwendet wird, um die Begriffe und Konzepte der Domäne zu beschreiben und zu verstehen.	Das gesamte Team verwendet denselben Begriff wie Order, Payment, Customer, um klar und eindeutig zu kommunizieren.
Value Object	Ein Value Object ist ein unveränderliches Objekt, das keine eigene Identität hat. Es wird nur durch seine Eigenschaften beschrieben.	Eine Adresse in einer Bestellung, die keine eigene Identität hat, aber durch Straßenname, Stadt und Postleitzahl definiert wird.
Write Model	Ein Write Model ist das Modell, das die Logik für Schreiboperationen und Zustandsänderungen eines Systems kapselt. Es wird oft mit einem Command verwendet.	Ein OrderWriteModel, das die Logik für das Erstellen und Bearbeiten von Bestellungen enthält.