Differences

This shows you the differences between two versions of the page.

--- concepts:setbasedvalidation [2013/03/13 17:10]
rtavassoli
+++ concepts:setbasedvalidation [2013/03/13 18:53] (current)
rtavassoli
@@ Line 20: / Line 20: @@
   {
     // eigene Prüfungen
-    var reservationNumber = registry.Register(Id, projectKey); // asynchron, wird also gespeichert
+    var reservationNumber = registry.Reserve(Id, projectKey); // asynchron, wird also gespeichert
     ApplyChange(new ProjectKeySet(reservationNumber, projectKey);
   }
@@ Line 33: / Line 33: @@
 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((Wenn Projekt 1 erst die Nummer //123// hat, die dann in //321// geändert wird, und Projekt 2 danach die Nummer //123// erhält - vorausgesetzt die Registratur befreit Projektnummern, die geändert werden. Nun könnte Projekt 1 im Read Model theoretisch noch nicht aktuell sein und wie Projekt 2 auch die //123// anzeigen --> doppelte Projektnummer)).
 ==== Fehlerfall ====
-Es kann passieren, dass im Methodenaufruf von oben die Projektnummer reserviert wird, aber nie verwendet wird((z.B. Infrastrukturfehler)). Die reservierte Projektnummer muss in dem Fall storniert werden, damit sie wieder verwendet werden darf - im Normalfall wird derselbe Befehl nochmals versucht.
+Es kann passieren, dass im Methodenaufruf von oben die Projektnummer reserviert wird, aber nie verwendet wird((z.B. Infrastrukturfehler)). Die reservierte Projektnummer muss in dem Fall storniert werden, damit sie wieder verwendet werden darf - im Normalfall wird der Client den Befehl nochmals senden.
 \\ \\
 Dafür ist die SAGA da. Sie wurde mit ProjectKeyReserved gestartet((Nicht mit ProjectKeySet, da das Ereignis im Fehlerfall ja gar nicht stattgefunden hat)). Die SAGA wartet nun nicht einfach auf ProjectKeySet, sondern hat einen eingebauten Nerv Faktor(("Sind wir schon da?", "Sind wir schon da?", "Sind wir schon da?")). Sie sendet in dem Fall den Befehl ConfirmProjectKeyReservation an das Projekt. Im Projekt passiert folgendes:
@@ Line 69: / Line 69: @@
 Da es MainProject und SubProject gibt, die von Project abgeleitet sind, sollte es auch ein VoidProject für diesen Fall geben. Es verwendet denselben Id-Kreis wie die anderen Projekte auch.
 === Doppelte Id Vergabe ===
-Nun kann es passieren, dass der Handler für die ursprüngliche Projektanlage eine DuplicateIdException auslöst, wenn inzwischen ein VoidProject erzeugt wurde. In diesem Fall muss der Client für die Projektanlage in der Lage sein, die Anlage erneut zu senden, vorher die Id auszutauschen. Dieser Fall sollte aber so gut wie nie eintreten.
+Nun kann es passieren, dass der Handler für die ursprüngliche Projektanlage eine DuplicateAggregateIdException auslöst, wenn inzwischen ein VoidProject erzeugt wurde. In diesem Fall muss der Client für die Projektanlage in der Lage sein, die Anlage erneut zu senden, vorher die Id auszutauschen. Dieser Fall sollte aber so gut wie nie eintreten.
 === Eine Reservierung pro Projekt Id ===
 Die Registratur für Projektnummern erlaubt keine zwei gleichzeitigen Reservierungen für dieselbe Id. Das System ist nun 100% konsistent. Es kann aber folgendes passieren:
@@ Line 78: / Line 78: @@
 Jetzt können zwei Dinge passiert sein. Die SAGA hat den Befehl zur Bestätigung der Reservierung abgeschickt, ein VoidProjekt mit der Id=123 wurde erzeugt, und die Reservierung für {123,"ABC"} wurde storniert. In diesem Fall wird der neue Befehl mit einer DuplicateAggregateIdException abgelehnt und der Client muss den Befehl mit einer neuen Id absenden.
 \\ \\
-Alternativ kann es sein, dass die SAGA noch nichts gemacht hat. In der erneuten Projektanlage wird nun wieder versucht, die Projektnummer "ABC" für die Id 123 zu reservieren. Die Registratur muss in diesem Fall eine ProjectKeyReservedException auslösen. Sie kann nicht davon ausgehen, dass sich das Projekt nach ganz bestimmten Regeln verhält. Es ist das Projekt, dass in diesem Fall weiß, dass da was nicht stimmen kann. Entweder gibt es wirklich ein anderes Projekt mit der Id, dass gerade eine Projektnummeränderung vornimmt, oder es gab für die Id einen Fehler, der noch nicht abgearbeitet ist. In beiden Fällen((Also bei der ProjectKeyReservedException)) sollte die Anlage mit einer neuen Id versucht werden.
+Alternativ kann es sein, dass die SAGA noch nichts gemacht hat. In der erneuten Projektanlage wird nun wieder versucht, die Projektnummer "ABC" für die Id 123 zu reservieren. Die Registratur muss in diesem Fall eine PendingProjectKeyReservationException auslösen. Sie kann nicht davon ausgehen, dass sich das Projekt nach ganz bestimmten Regeln verhält. Es ist das Projekt, dass in diesem Fall weiß, dass da was nicht stimmen kann. Entweder gibt es wirklich ein anderes Projekt mit der Id, dass gerade eine Projektnummeränderung vornimmt, oder es gab für die Id einen Fehler, der noch nicht abgearbeitet ist. In beiden Fällen((Also bei der PendingProjectKeyReservationException)) sollte die Anlage mit einer neuen Id versucht werden.
 \\ \\
 Der einzige Fall, der nicht so einfach aufgelöst werden kann ist der, dass die neue Projektanlage abgeschickt wird, die alte Reservierung für die Projektnummer "ABC" noch nicht storniert wurde, und "ABC" im Zuge der Projektanlage nicht reserviert werden kann - obwohl "ABC" gleich freigegeben wird, was das Projekt aber nicht weiß. Die Projektanlage würde mit der Begründung abgelehnt werden, dass es die Projektnummer bereits gibt.
 \\ \\
-Dieser Fall kann aufgelöst werden, indem die Projektanlage bei einer ProjectKeyReservedException einfach immer wieder((Mit einer neuen Id - siehe ersten Fehlerfall)) versucht wird. Irgendwann ist die Reservierung weg, weil sie storniert oder bestätigt wurde.
+Dieser Fall kann aufgelöst werden, indem die Projektanlage bei einer PendingProjectKeyReservationException einfach immer wieder((Mit einer neuen Id - siehe ersten Fehlerfall)) versucht wird. Irgendwann ist die Reservierung weg, weil sie storniert oder bestätigt wurde.
 \\ \\
-So, das sollte alle Fälle abdecken.
+So, das sollte alle Fälle abdecken. Zusammengefasst:
+> Wenn man in der Projektanlage die Projektnummer setzen möchte und eine DuplicateAggregateIdException oder eine PendingProjectKeyReservationException erhält, wiederholt man die Anlage einfach immer wieder bis sie klappt oder eine andere Fehlermeldung erhält((Die Projektnummer kann dafür z.B. bei einem Import als idempotency-Id genutzt werden, denn wenn die Anlage funktioniert hat samt Projektnummernvergabe, würde man bei einem erneuten Versuch eine DuplicateProjectKeyException erhalten)). Man kann aber auch bei einer DuplicateAggregateIdException prüfen, ob es das Projekt überhaupt gibt, und wenn ja, ob es ein VoidProject ist. Dito für die andere Exception.
+> Wenn man für ein vorhandenes Projekt die Projektnummer setzen möchte, kann es genauso passieren, dass die Reservierung klappt, das Speichern des Projektes aber nicht. In diesem Fall wird ja das Projekt von der SAGA regelmäßig abgefragt. In diesem Fall kann der Befehl zur Projektnummernänderung bei einer PendingProjectKeyReservationException einfach so lange abgeschickt werden, bis der Befehl funktioniert oder aus dem Fehler eine ProjectKeyRegisteredException geworden ist.
+===== Alternativlösung =====
+Damit der Client eine Projektanlage nicht immer wieder mit einer neuen Id senden muss, kann das Projekt und der Command Handler ein wenig angepasst werden. Der Command Handler kann wie folgt aussehen:
+<code csharp>
+  public ProjectCommandHandler: CommandHandler, Handles<AddProject>
+  {
+    public void Handle(AddProject message)
+    {
+      var repo = new Repository<Project>();
+      var proj = repo.Get(message.Id);
+      if (proj == null)
+      {
+        proj = ProjectFactory.AddBootstrapped(message.Id);
+        repo.Save(proj);  // das Projekt ist nun vorhanden! auch wenn es hiernach nicht mehr weiter geht.
+      }
+      proj.Bootstrap(message.ProjectName, message.ProjectKey, ...);
+      repo.Save(proj);
+    }
+  }
+</code>
+Das sieht merkwürdig aus. Jetzt kann der Client bei einer PendingProjectKeyReservationException den Befehl einfach neu senden, muss die Id des Projektes nicht ändern. Ein Projekt, dass mit AddBootstrapped erzeugt wurde, ist im Read Model nicht sichtbar, wird auch nur zwei Befehle akzeptieren:
+  * Bootstrap
+  * ConfirmProjectKeyReservation
+Bootstrap ist wie eine Factory, und wird vom Projekt nur akzeptiert, solange es den Status //Bootstrapping// hat. ConfirmProjectKeyReservation wird im //Bootstrapping// Status immer ReservedProjectKeyNotUsed veröffentlichen. Wenn ein Projekt also zum Bootstrapping angelegt werden konnte, in der Bootstrap() Methode eine Projektnummer reserviert hat, danach aber ein Fehler passiert ist, kann die Bootstrap() Methode immer wieder aufgerufen werden, genau wie SetProjectKey() in einem vorhandenen Projekt.
+\\ \\
+Es besteht jetzt nur noch die //Gefahr//, dass bei Fehlern nach der Reservierung, oder bei Änderungen an der Projektnummer schnell hintereinander, die Reservierung noch besteht aber weder storniert noch bestätigt wurde. Das System erhält dann eine PendingProjectKeyReservationException von der Registratur. Die Command Handler können den Aufruf in dem Fall einfach immer wieder behandeln, denn sie wissen, dass dieser Fehler schließlich verschwinden muss.
+\\ \\
+Sie sollten dabei ein Time-Out setzten, d.h. dass der Befehl letztendlich abgelehnt wird, wenn der Fehler z.B. nicht nach 30 Sekunden verschwindet. In dem Fall gibt es Probleme im System, die das Messaging daran hindern, Nachrichten rechtzeitig //an den Mann// zu bringen.

tawiki

User Tools

Site Tools

Differences

Page Tools