Freigeben über

Anwenden von CQRS- und CQS-Ansätzen in einem DDD-Microservice in eShopOnContainers

Tipp

Dieser Inhalt ist ein Auszug aus dem eBook .NET Microservices Architecture for Containerized .NET Applications, verfügbar auf .NET Docs oder als kostenlose herunterladbare PDF, die offline gelesen werden kann.

PDF herunterladen

.NET Microservices-Architektur für containerisierte .NET-Anwendungen eBook-Cover-Thumbnail.

Die Gestaltung des Bestell-Microservice bei der eShopOnContainers Referenzanwendung basiert auf CQRS-Prinzipien. Es verwendet jedoch den einfachsten Ansatz, der nur die Abfragen von den Befehlen trennt und dieselbe Datenbank für beide Aktionen verwendet.

Das Wesen dieser Muster und der wichtige Punkt hier ist, dass Abfragen idempotent sind: Unabhängig davon, wie oft Sie ein System abfragen, ändert sich der Zustand dieses Systems nicht. Mit anderen Worten, Abfragen sind frei von Nebeneffekten.

Daher könnten Sie ein anderes "Lese-" Datenmodell als das "Schreib-" Datenmodell der Transaktionslogik verwenden, auch wenn die Bestell-Microservices dieselbe Datenbank verwenden. Daher ist dies ein vereinfachter CQRS-Ansatz.

Andererseits ändern Befehle, die Transaktionen und Datenaktualisierungen auslösen, den Zustand im System. Mit Befehlen müssen Sie beim Umgang mit Komplexität und sich ständig ändernden Geschäftsregeln vorsichtig sein. Hier möchten Sie DDD-Techniken anwenden, um ein besseres modelliertes System zu erhalten.

Die in diesem Leitfaden dargestellten DDD-Muster sollten nicht universell angewendet werden. Sie führen Einschränkungen für Ihr Design ein. Diese Einschränkungen bieten Vorteile wie höhere Qualität im Laufe der Zeit, insbesondere in Befehlen und anderem Code, der den Systemzustand ändert. Diese Einschränkungen erhöhen jedoch die Komplexität bei weniger Vorteilen für das Lesen und Abfragen von Daten.

Ein solches Muster ist das Aggregatmuster, das wir in späteren Abschnitten genauer untersuchen. Im Aggregatmuster behandeln Sie viele Domänenobjekte als einzelne Einheit als Ergebnis ihrer Beziehung in der Domäne. Sie erhalten möglicherweise nicht immer Vorteile aus diesem Muster in Abfragen; sie kann die Komplexität der Abfragelogik erhöhen. Bei schreibgeschützten Abfragen werden viele Objekte nicht als einzelnes Aggregat behandelt. In diesem Fall erhöht sich nur die Komplexität.

Wie in Abbildung 7-2 im vorherigen Abschnitt dargestellt, schlägt dieses Handbuch vor, DDD-Muster nur im Transaktions-/Aktualisierungsbereich Ihres Microservice zu verwenden (das heißt, wie durch Befehle ausgelöst). Abfragen können einem einfacheren Ansatz folgen und sollten nach einem CQRS-Ansatz von Befehlen getrennt werden.

Für die Implementierung der "Abfragenseite" können Sie zwischen vielen Ansätzen wählen, von Ihrem vollständigen ORM wie EF Core, AutoMapper-Projektionen, gespeicherten Prozeduren, Ansichten, materialisierten Ansichten oder einem Mikro-ORM.

In diesem Leitfaden und bei eShopOnContainers (insbesondere beim Bestell-Mikroservice) haben wir uns entschieden, direkte Abfragen mit einem Mikro-ORM wie Dapper zu implementieren. In diesem Leitfaden können Sie jede Abfrage basierend auf SQL-Anweisungen implementieren, um dank eines leichten Frameworks mit geringem Aufwand die beste Leistung zu erzielen.

Wenn Sie diesen Ansatz verwenden, benötigen alle Aktualisierungen ihres Modells, die sich darauf auswirken, wie Entitäten in einer SQL-Datenbank beibehalten werden, auch separate Updates für SQL-Abfragen, die von Dapper oder anderen separaten (nicht EF)-Ansätzen für Abfragen verwendet werden.

CQRS- und DDD-Muster sind keine Architekturen der obersten Ebene

Es ist wichtig zu verstehen, dass CQRS und die meisten DDD-Muster (z. B. DDD-Ebenen oder ein Domänenmodell mit Aggregaten) keine Architekturstile, sondern nur Architekturmuster sind. Microservices, SOA und ereignisgesteuerte Architektur (EDA) sind Beispiele für Architekturstile. Sie beschreiben ein System vieler Komponenten, z. B. viele Microservices. CQRS- und DDD-Muster beschreiben etwas innerhalb eines einzelnen Systems oder einer komponente; in diesem Fall etwas in einem Microservice.

Verschiedene Gebundene Kontexte (Bounded Contexts, BCs) verwenden unterschiedliche Muster. Sie haben unterschiedliche Aufgaben und führen zu unterschiedlichen Lösungen. Es lohnt sich zu betonen, dass das Erzwingen desselben Musters überall zu Einem Scheitern führt. Verwenden Sie CQRS- und DDD-Muster nicht überall. Viele Subsysteme, BCs oder Microservices sind einfacher und können einfacher mit einfachen CRUD-Diensten oder einem anderen Ansatz implementiert werden.

Es gibt nur eine Anwendungsarchitektur: die Architektur des Systems oder der End-to-End-Anwendung, die Sie entwerfen (z. B. die Microservices-Architektur). Der Entwurf jedes Bounded Context oder Mikroservice innerhalb dieser Anwendung spiegelt jedoch seine eigenen Abwägungen und internen Designentscheidungen auf der Ebene der Architekturprinzipien wider. Versuchen Sie nicht, überall die gleichen Architekturmuster wie CQRS oder DDD anzuwenden.

Weitere Ressourcen

ZurückWeiter