Ich beginne gerade meinen ersten wirklichen Versuch mit einem DDD / CQRS / ES-System, nachdem ich eine Menge Material und Beispiele studiert habe.
1) Ich habe Ereignisbeschaffungsbeispiele gesehen, bei denen die Aggregate Event-Handler sind und ihre Handle-Methode für jedes Ereignis den Status der Objektinstanz verändert (Sie implementieren eine IHandleEvent & lt; EventType & gt; -Schnittstelle für Ereignisse, die den Status mutieren würden)
2) Ich habe auch Beispiele gesehen, bei denen die Aggregate einfach wie einfache klassische Entity-Klassen aussehen würden, die die Domäne modellieren. Eine andere Ereignishandler-Klasse ist an der Mutation des Zustands beteiligt.
State wird natürlich in beiden Fällen von den Ereignishandlern mutiert, wenn das Aggregat aus einem Repository-Aufruf neu erstellt wird, der alle vorherigen Ereignisse für dieses Aggregat erhält, und wenn ein Befehlshandler Methoden auf einem Aggregat aufruft. Obwohl ich im letzteren Fall Beispiele gesehen habe, in denen die Ereignisse im Befehlshandler und nicht im Aggregat veröffentlicht werden, was meiner Überzeugung nach falsch ist.
Meine Frage ist, was sind die Vor- und Nachteile zwischen Methode (1) und (2)
Der Auftrag, einen Befehl zu empfangen / zu bearbeiten, unterscheidet sich von der Aktion. Der Ansatz, den ich nehme, ist ein Handler zu haben. Es ist Aufgabe, einen Befehl zu erhalten. Der Befehl enthält die AggregateId, mit der dann alle Ereignisse für das Aggregat abgerufen werden können. Anschließend können diese Ereignisse über eine LoadFromHistory-Methode auf das Aggregat angewendet werden. Dies bringt das Aggregat auf den neuesten Stand und macht es bereit, den Befehl zu empfangen. Also meine kurze Version ist Option 2.
Ich habe einige hilfreiche Beiträge, der erste ist ein Überblick über den Ablauf einer typischen CQRS / ES-Anwendung. Es ist nicht so, wie es oft sein sollte. Sie finden dies unter CQRS - Eine Schritt-für-Schritt-Anleitung zu der Ablauf einer typischen Anwendung !
Ich habe auch einen Beitrag darüber, wie man einen aggregierten Root für CQRS und ES erstellt, wenn das hilfreich ist. Sie finden das unter Aggregate Root - So erstellen Sie einen für CQRS und Event Sourcing
Jedenfalls hoffe ich, dass das hilft. Alles Gute, um deine CQRS / ES App zu bauen!
Obwohl ich mit Codescribler einverstanden bin, muss ich noch ein bisschen weiter ins Detail gehen. Bei ES geht es darum, einen Entitätszustand als einen Strom von Ereignissen (der gespeichert wird) auszudrücken. Ein Message-Handler ist nur eine Service-Implementierung, die einer Entity mitteilen wird, was sie tun soll.
Mit ES implementiert die Entität ihre Änderungen, indem sie ein oder mehrere Ereignisse generiert und sie dann auf sich selbst anwendet. Die Entität weiß nicht, dass ihre Änderungen von einem Befehl oder Event-Handler kommen (es sollte "immer" ein Command-Handler sein, aber gut .. manchmal ist es egal), ändert jedoch den Status über eigene Ereignisse, die veröffentlicht werden durch einen Dienst (oder den Ereignisspeicher selbst).
Aber ... in einer aktuellen App akzeptierte meine ES-Einheit aus pragmatischen Gründen die Befehle direkt, obwohl die Entität selbst keine Implementierung eines Befehlshandlers war. Der Handler würde den Befehl nur an die Entität weiterleiten.
Sie können Nachrichten also direkt mit einer Entität behandeln, aber nur als Implementierungsdetail. Ich würde nicht empfehlen, eine Entität als Befehls- / Ereignisbehandler zu definieren, da dies eine Verletzung der Trennung von Interessen darstellt.
Tags und Links event-sourcing cqrs