• UserAccount und SystemAccount werden beide von Account abgeleitet,
• In Account gibt es einen abstrakten Konstruktor der in den Kindklassen implementiert werden muss. Das Systemkonto wird z.B. eine Beschreibung erhalten¹⁾, und das Personenkonto eine PersonID,
• Es gibt das abstrakte Ereignis AccountCreated, welches nur die ID des Kontos beinhaltet. UserAccount wird im Konstruktor das UserAccountCreated:AccountCreated Ereignis melden, welches neben der ID des Kontos die PersonID beinhalten wird. Entsprechendes gilt für SystemAccount oder neue Kontenarten,
• Auf der Befehlsseite wird es den abstrakten Befehl CreateAccount geben. Für UserAccount wird es CreateUserAccount:CreateAccount geben, entsprechendes gilt für SystemAccount,
• Im Command Handler wird Service Locator verwendet, um die korrekte Factory für die entsprechenden Implementierungen von CreateAccount zu ermitteln

Der Authentication BC ist dafür da, die Domäne der Authentifizierung abzubilden. Es gibt dazu fast immer noch den Aspekt der Darstellung. Gemeinsame Eigenschaften des Kontos, die mit der Geschäftslogik nichts zu tun haben, und nicht vom Anwender eingegeben werden, sondern ermittelt werden müssen²⁾ erhalten am besten einen eigenen Kontext. Es ist sinnvoll die Eigenschaften explizit zu machen, denn wenn sie implizit bleiben, sind wird schnell wieder bei der dritten Normalform³⁾, etwas wovon wir mit DDD/CQRS/ES weg wollten⁴⁾.

Es wurde also identifiziert, dass die Bezeichnung des Subjektes des Kontos im Authentication Info BC wichtig ist. Für ein Systemkonto möchte man gerne sehen, was das Konto repräsentiert, z.B. “Konto für die Outlook-Schnittstelle”. Für ein Benutzerkonto möchte man gerne sehen, wen das Konto repräsentiert, z.B. “Max Mustermann”.

Es gibt das Aggregate AccountInfo im Authentication Info BC. Es gibt den Befehl SetAccountInfo { ID, SubjectDescription }. Es gibt das Ereignis AccountInfoSet { ID, SubjectDescription }.

Für jede Kontoart, die von Account abgeleitet wird, sollte ein Handler gebaut werden, der die AccountInfo aktuell hält. Beim SystemAccount ist das einfach. Ein handler lauscht auf SystemAccountAdded und SystemAccountRenamed und veröffentlicht einfach SetAccountInfo mit der ID des Kontos und der Beschreibung des Systemkontos.

Hinweis: Denormalisierer, die Informationen aus Account und AccountInfo kombinieren, müssen darauf achten, dass sie SystemAccountAdded und AccountInfoSet nicht zwingend in der erwarteten Reihenfolge erhalten. AccountInfoSet kann durchaus vor SystemAccountAdded behandelt werden. In dem Fall kann man entweder warten, bis SystemAccountAdded erhalten wurde, und erst dann das Konto denormalisieren, oder man schreibt schon mal einen Datensatz mit der Konto-ID und der Bezeichnung, alles andere bleibt leer. Die DTOs müssen nur darauf vorbereitet sein, leere Felder zu haben, oder aber die Abfragen liefern nur Konten mit allen Feldern, so dass die DTOs sicher sein können, dass sie immer vollständig gefüllt sind.

Wie fülle ich die Personeninformation beim Benutzerkonto? Das ist etwas schwieriger. Es muss einen Handler für Ereignisse aus dem Personenkontext und dem Authentifizierungskontext geben, und dieser Handler muss Daten cachen⁵⁾, weil er nicht weiß, in welcher Reihenfolge die Ereignisse kommen. Der Handler muss folgende beiden Tabellen vorhalten⁶⁾

Der Handler verarbeitet die drei Ereignisse UserAccountAdded, PersonAdded und PersonRenamed⁷⁾. Die Workflows sind nun folgende⁸⁾:

• Die AccountInfoSet Befehle müssen zwingend erfolgreich sein. Dafür sollte man ein Systemkonto einrichten, das die entsprechenden Rechte hat, und keine Logik in dem AccountInfo Aggregate haben. Bei Fehlern wird der Handler von oben nicht weiter machen, und der Administrator sollte informiert werden, damit der Fehler behoben wird,
• Wenn ein neues Konto dazu kommt, sollte es einen Handler mitbringen, dass die AccountInfo füllt. Ansonsten wäre die Info im UI immer leer⁹⁾. Man kann den Handler aber auch selbst dazu bauen, wenn man entsprechende Kenntnisse von den verwendeten BCs hat,
• Das Open-Closed Prinzip wird eingehalten. Der Authentifizierungskontext ist geschlossen was Änderungen angeht, und offen für Erweiterungen. Durch den Authentication Info BC wird auch die Projektionsseite bedient,
• Wenn die AccountInfoSet Befehle falsch erzeugt wurden, muss der fehlerhafte Handler korrigiert werden, und es wird kompensiert - in dem Fall werden einfach neue SetAccountInfo Befehle gesendet,
• Wenn es zu einer Person viele Konten geben kann¹⁰⁾, dann ist der Prozess Speicher- und Zeitintensiv. Für eine Änderung an der Personenbezeichnung müssten N Befehle gesendet werden, diese werden alle gespeichert und es werden N Domänenereignisse generiert. Zudem werden alle Personen und Konten im Handler gecacht. Es kann auch dauern, bis alle N Befehle durchgelaufen sind. Man muss abwägen, ob man in bestimmten Fällen die Info nicht direkt in die Haupt-Domäne schreibt, und Sichten auf aktuell verknüpfte Daten dann tatsächlich über Referenzen ermittelt. Wenn die Domäne aber erweiterbar ist, ist das mit den Referenzen nicht so einfach, und Optimierungen mit z.B. geteilten Datenbank Views würden bedeuten, dass man sich an anderer Stelle einschränkt. Es ist somit eine Fall-zu-Fall Entscheidung,
• Man darf sich nicht darauf verlassen, dass man nach AccountAdded auch AccountInfoSet erhält. Das sind Ereignisse aus 2 Domänen, die durch die Applikationsschicht verknüpft werden,
• AccountAdded¹¹⁾ sollte den Typ des Kontos beinhalten¹²⁾. So kann dann jedes DTO den Typ beinhalten, z.B. PROM.Authentication.UserAccount. Anhand dieses Typs kann nun überall über Service Locator entsprechend mit dem Konto umgegangen werden. Das UI kann zum Bearbeiten den entsprechenden Controller laden, ebenso kann ein Übersetzer gefunden werden, der aus der Typenbezeichnung eine Bezeichnung in der Sprache des angemeldeten Users macht.