Die Pattern CQRS (Command Query Responsibility Separation) und ES (Event Sourcing) spielen bei der Modernisierung von Applikationen eine wichtige Rolle. Dieses Dokument zeigt, was Organisationen tun müssen, um CQRS/ES erfolgreich einzusetzen, diskutiert Lösungsvarianten und strategische Alternativen und gibt praxisorientierte Empfehlungen.
Inhalt:
In letzter Zeit wurde die Diskussion um die beiden Entwicklungs-Pattern CQRS und ES (Command Query Responsibility Separation / Event Sourcing) immer intensiver. Auf Konferenzen, im Netz, aber auch in internen Strategiemeetings sind sie immer ganz vorne dabei, wenn es um das Thema Applikationsmodernisierung geht.
Nicht immer werden die Versprechen, die mit den Pattern verbunden sind, auch tatsächlich erfüllt. Die Einführung geht nicht selten schief.
Dieses Dokument geht der Frage nach, warum das so ist und was Organisationen tun müssen, um Fehlschläge bei der Applikationsmodernisierung mit CQRS/ES zu vermeiden. Es erklärt die komplexen Zusammenhänge in einer ereignisgesteuerten Architektur, diskutiert Lösungsvarianten und strategische Alternativen und gibt praxisorientierte Empfehlungen.
Lesen Sie unter anderem:
- Was CQRS/ES genau bedeutet.
- Welche Anforderungen Sie an eine CQRS/ES-Plattform stellen sollten.
- Wie Sie CQRS/ES erfolgreich in Ihrem Unternehmen implementieren.
Originalauszug aus dem Dokument:
Enter CQRS - CQRS or Command Query Responsibility Separation was proposed with the primary aim to tackle Model Complexity by dividing and conquering the Domain Model. Simply put, it advocates the vertical split of your Domain Model into two distinct partitions - a Command Model and a Query Model. The Command Model is focused on executing Tasks, is primarily expressed in operations (e.g. Open an Account) and only contains the data necessary for task execution and decision making. The Query Model (aka Projections) is focused on delivering information with data stored the way it is used (e.g. Relational/NoSQL). Suddenly the complexity associated with bloated Domain Models disappear due to the optimization that CQRS provides. The split also helps you focus on different types of NFRs for each side of the Domain Model e.g. certain problems might have more reads than writes while certain problems might be the exact opposite - CQRS offers a great way to help address these kind of problems.
However, the adoption of CQRS does present one problem that needs to be taken care of. How do we keep the two models in sync i.e. changes in the Command Model should (eventually) be reflected in the Query Model? An obvious answer would be “Events” which could act as the glue between the Command Model and the Query Model and since Events are the result of a task (e.g. Open an Account results in an Account Opened Event), they are tied to the Command Model.