Es wäre optimal, weil sehr simpel zum entwickeln, wenn die gesamte Business Logik unabhängig in den Aggregates implementiert würde. Man ruft einen Methode in einem Aggregate auf, alle Regeln werden geprüft, und das Aggregate nimmt dann die entsprechenden Änderungen vor.

Es gibt aber Szenarien in denen Business Regeln mehrere Aggregates betreffen. Sei es eine einfache Regel wie der Transfer von einem Bankkonto zu einem anderen - der Transfer darf nur statt finden wenn ein Konto be- und das andere entlastet wurde. Hierfür gibt es mehrere Möglichkeiten der Umsetzung. Entweder findet man ein neues Aggregate um die Regel sicher zu stellen, z.B. das KontoTransfer Aggregate. Dieses würde die Transaktionalität sicher stellen, indem es die Be- und Entlastung der beiden Konten in einer Änderung darstellen kann. Es müsste aber vorher die beiden Konten fragen, ob der Transfer erlaubt ist - ein Fall für Eventual Consistency, weil die Konten diese Fragen nur beantworten können mit Daten, die nicht zu 100% aktuell sein müssen¹⁾.

Oder man setzt einen Workflow als Saga um, der u.a. zusätzlich das Reservation Pattern verwenden kann, um einzelne Aktionen des Transfers rückgängig zu machen, falls der Transfer im Ganzen nicht rechtzeitig vollendet werden kann.

Wenn man alle mitwirkenden Aggregates im Zugriff hat, kann man den Transfer aber auch als einen Domain Service implementieren. Ein Domain Service ist ein erweiterter Transaktionsrahmen. Der Domain Service würde beide Konten laden und eines be- und das andere entlasten. Die Infastrukturschicht stellt dabei sicher, dass das alles innerhalb von einer Transaktion geschieht. Zudem ist ein Kontotransfer nur über den Domain Service möglich, d.h. die entsprechenden Methoden in den Konto Aggregates sind nicht öffentlich zugängig.