Es gibt verschiedene Arten von Mengen basierten Regeln. Im einfachsten Fall baut man einfach ein Aggregate für die Menge, mit Entitäten, die die einzelnen Aggregates referenzieren. Wenn z.B. die Projektnummer eindeutig sein muss, hat das Project Aggregate selbst keine Projektnummer. Es gibt ein ProjectKeyRegistry Aggregate, in dem die Projektnummern eindeutig gehalten werden. Jede Projektnummer im Aggregate ist eine Entität, welche ein Project Aggregate referenziert.

Projektionen können nun für das Read Model ein Project aufbauen, indem das Project Aggregate und das ProjectKeyRegistry Aggregate kombiniert werden¹⁾.

Problematisch wird es nur, wenn auch das Project Aggregate Regeln bezüglich der Nummer hat. Der Command Handler könnte bei Bedarf die Nummer aus dem Read Model an die Methoden des Project Aggregates übergeben, aber das wäre dann nur noch schließlich konsistent. Zudem möchte man hier und da Änderungen über das Project Aggregate steuern, d.h. wenn der Projektstatus eine Änderung der Projektnummer nicht zulässt, soll man auch nicht über die ProjectKeyRegistry einfach die Nummer ändern können.

Also müsste man ein ProjectSystem Aggregate bauen, durch das alles läuft, und Projekte sind immer nur Entitäten. Das wäre die konsistenteste Lösung. Es geht aber darum, im CAP einen vernünftigen Kompromiss zwischen der Konsistenz²⁾, der Verfügbarkeit³⁾ und der Partitionstoleranz⁴⁾ zu finden. Wenn man zuviel Gewicht auf die Konsistenz legt, leiden die anderen beiden Punkte.

Wenn die Aussage also ist, dass es auf keinen Fall zwei gleiche Projektnummern geben darf, dann muss man für die Projektnummer die Konsistenz auf 100% halten, also die Projektnummernvergabe für alle Projekte serialisieren. Das heißt aber nicht, dass man alles das Projekt betreffend serialisieren muss. Die Projektnummer wird i.d.R. einmal vergeben, vieles Andere wird öfters geändert.

Ich möchte als Anwender nun auch mehrere Aktionen das Projekt betreffend abschicken, und erwarte, dass entweder alle oder keine durchgeführt wird. Wie geht so was?

Das sieht ja erst mal kompliziert aus für solch eine simple Aufgabe. Wie läuft das ab?

public class Project: ProjectBase
{
  public void SetProjectKey(string projectKey, IProjectKeyRegistry registry)
  {
    // eigene Prüfungen
    var reservationNumber = registry.Register(Id, projectKey); // asynchron, wird also gespeichert
    ApplyChange(new ProjectKeySet(reservationNumber, projectKey);
  }
}

Im Erfolgsfall ist das das schönste Modell. Der Anwender schickt einen Befehl, der an das Projekt gerichtet ist ⁵⁾, und weiß, dass die Projektnummer geändert wurde wenn der Befehl fehlerfrei durchgelaufen ist.

Wenn ProjectKeyReserved oder ProjectKeySet erhalten wurde⁶⁾, muss eine SAGA gestartet werden, die für die Project Id läuft. Sobald auch das zweite dieser Ereignisse erhalten wurde, kann die SAGA der ProjectKeyRegistry mitteilen, dass sie aus der Reservierung eine Registrierung machen soll.

Womit wird die Projektnummer im Read Model gesetzt? Mit ProjectKeySet vom Projekt, oder mit ProjectKeyRegistered von der Projektnummer-Registratur?

Die Registratur ist ja im Grunde nur dafür da, eindeutige Projektnummern zu verifizieren. Was alles andere Betrifft, ist die Projektnummer relevant, die im Projekt steht, und nicht in der Registratur. Das Read Model aller Projekte ist nur schließlich konsistent, d.h. es könnten im Read Model doppelte Projektnummern erscheinen⁷⁾.