Differences

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

--- technology:domainmodel:processmanager [2013/01/11 22:02]
rtavassoli [Alternative Lösung]
+++ technology:domainmodel:processmanager [2013/01/12 08:56] (current)
rtavassoli [Alternative Lösung]
@@ Line 81: / Line 81: @@
 ==== Alternative Lösung ====
 Es gibt in diesem einfachen Fall auch eine Lösung ohne Saga. Folgendes kann gemacht werden wenn ein Konto angelegt werden soll:
-  - Befehl zur Kontoanlage absenden,
+  - Befehl zur Kontoanlage absenden. Der Befehl/das Konto kann den Wunsch-Usernamen enthalten - für den Fall, dass das UI das Konto schon zur Anzeige hat, den Usernamen aber noch nicht hat. Der Denormalisierer schreibt dann in eine Tabelle den Wunschnamen((wenn AccountAdded behandelt wird)) + den Tatsächlichen((wenn UsernameAdded behandelt wird)). Das UI kann den Wunschnamen samt Sternchen(*) anzeigen, falls der //richtige// noch nicht da ist((also UsernameAdded noch nicht erhalten wurde)),((in diesem Fall würde sogar ein AddAccount Befehl vom UI reichen, und ein Handler, der das Ereignis AccountAdded abfängt und AddUsername abschickt - es enthält dann ja die Konto-ID + den Wunschnamen, um zu versuchen, einen Usernamen anzulegen, also um den Befehl AddUsername abzuschicken. Zudem kann der Denormalisierer in die Tabelle von oben rein schreiben, wenn ein Name vergeben ist, das UI könnte dann das Konto samt Wunschnamen anzeigen plus zwei Sternchen oder sonst was, um darauf hinzuweisen, dass der Name nicht geklappt hat)),
   - Eine gewisse Zeit auf das Ergebnis warten/pollen.
      - Wenn das Konto angelegt ist, den Befehl zur Usernamenanlage absenden,
@@ Line 87: / Line 87: @@
      - Wenn das Konto nicht angelegt werden konnte ist die Aktion zu Ende, ohne das irgend etwas angelegt wurde.
   - Wenn das Zeitlimit überschritten ist, bzw. irgend eine unerwartete Exception passiert, Abbruch. Leeres Konto mit Guid braucht nicht korrigiert werden, bzw. kann es dem Anwender angezeigt werden, und er kann die Passwortangabe erneut versuchen.
-Die Alternative Lösung basiert darauf, dass ein Konto ohne Referenzen nutzlos ist, damit nichts passieren kann, das zu Fehlern in den Geschäftsprozessen führt, und das Konto keine Daten blockiert - eine Guid wird i.d.R. kein zweites mal erzeugt, und wenn doch, gibt't halt eine neue. Die Reihenfolge der Befehle kann also derart sein, dass man nicht kompensieren muss, den Prozess somit sehr einfach und ohne Saga halten kann.
+Die Alternative Lösung basiert darauf, dass ein Konto ohne Passwort nicht schadet, und auch keine Daten blockiert - eine verwendete GUID. Entweder wird es dem Anwender gar nicht erst angezeigt, damit nichts weiteres mit dem Konto passieren kann, oder es wird dem Anwender angezeigt damit er das Passwort nachträglich eintragen kann.
+\\ \\
+Das ist ein simpler Fall. Aber auch das ist eine Erfahrung: jeder Fall mag anders sein, und es gibt nicht immer //die Lösung//. Wenn man aber die Prozesse analysiert sollte man immer zu einer Lösung finden.
 ==== Ändern des Benutzernamen ====
 Das ist noch viel einfacher. Es muss nur ein Befehl an das UniqueUserNames Aggregate geschickt werden, um den Benutzernamen zu ändern. Das wird entweder erlaubt oder abgelehnt.
 \\ \\
 Hier ist wichtig zu verstehen, dass eine Änderung am Benutzernamen, zusammen mit dem Passwort, nicht transaktional geschehen kann - und es auch **gar nicht muss**. Damit der Anwender gar keine anderen Erwartungen hat, gibt es eine Befehlsschaltfläche zum Ändern des Passwortes, und eine für den Benutzernamen. Er wird gar nicht erst beide zum Ändern gemeinsam eingeben können.

tawiki

User Tools

Site Tools

Differences

Page Tools