• 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

• Es werden alle gemeinsamen Punkte identifiziert, die relevant sein können, und vorbereitend *explizit* in die Domäne, die Ereignisse, die Befehle und die DTOs eingebaut! Dieser Punkt ist immens wichtig, vor allem die Konsequenzen daraus. Wenn das nicht so gemacht würde, wären Projektionen auf den BC sehr schwierig und wir wären wieder in der dritten Normalform⁶⁾ und im relationalen Datenbanken Paradigma von dem wir uns ja eigentlich lösen wollten.

Wen oder was ein Konto repräsentiert ist ein wichtiger Aspekt eines Kontos. Ein Systemkonto repräsentiert ein System, bzw. Dinge, die das Konto tun können soll, z.B. ein “Konto für die Outlook Schnittstelle”. Ein Benutzerkonto repräsentiert eine Person, z.B. “Max Mustermann”. Die Bezeichnung für das Systemkonto steht aber in SystemAccount, die der Person in der Person in einem anderen BC, repräsentiert lediglich durch die PersonID in UserAccount. Somit ist die Bezeichnung des Subjektes des Kontos nur implizit ermittelbar über das Systemkonto oder über das Benutzerkonto, das dann noch die Person dafür benötigt.

Was, wenn ein neuer Kontotyp dazu kommt? Man kann im Vorfeld nicht wissen, wie die Bezeichnung des Subjekts zu ermitteln ist. Man könnte sowas wie Projektionsereignisse definieren, wie z.B. AccountSubjectRenamed(Guid AccountId, string SubjectName), und von den unterschiedlichen Konto Implementierungen verlangen, diese Ereignisse auszulösen. Was aber ist ein Projektionsereignis? Die Domänenereignisse sollen doch alles, was die Domäne betrifft, erfassen. Und was, wenn die Projektionen falsch sind und korrigiert werden müssen? Die Projektionsereignisse einfach neu erzeugen⁷⁾? Das wäre nicht richtig, weil dann historische *Ereignisse* verändert würden.

Gemeinsame Aspekte müssen explizit gemacht werden. Das ist Speicherintensiver, Daten werden in der ersten Normalform⁸⁾ doppelt gehalten, können zeitweise abweichen, werden aber eventuell schlüssig sein⁹⁾, usw. Der Vorteil ist aber der, dass das, was danach kommt¹⁰⁾ wesentlich einfacher sein wird. Wenn ich weiß, dass es einen Bezeichner des Subjektes im Konto gibt, egal ob es ein Systemkonto, ein Benutzerkonto oder sonst eine Kontoart ist, dann ist das Arbeiten mit dieser Bezeichnung direkt und einfach. Es vollendet auch den BC als solches, denn was ist ein Benutzerkonto mit einer PersonenId von 3F2504E0-4F89-11D3-9A0C-0305E82C3301, wem gehört es? Wenn im Konto steht, dass es “Max Mustermann gehört, der eine Person mit der Identität 3F2504E0-4F89-11D3-9A0C-0305E82C3301 ist”, hat der Kontext alles, was er benötigt.

• Die Projektionsseite ist nun tatsächlich ein wenig komplexer. Projektionen werden dadurch erzeugt, dass Ereignisse behandelt werden, und aus diesen Ereignissen Sichten erstellt werden, die abgefragt werden. Die Sichten werden dann in Data Transfer Objects¹¹⁾ gewandelt, die dann an andere Systeme¹²⁾ gesendet werden können. Die anderen Systeme müssen nun mit den DTOs arbeiten können. Die Komplikation liegt darin, dass jede neue Kontoart neue Ereignisse, DTOs und Anforderungen and die Sichten einführt. Das wird am besten hier besprochen:

Ich¹³⁾ bin an der Erstellung von Konten interessiert, will wissen, wann ein Konto erstellt wird. Ich abonniere somit das AccountCreated Ereignis. Da UserAccountCreated und SystemAccountCreated von AccountCreated abgeleitet sind, würden beide von mir behandelt werden. Wenn eine neue Kontoart mit einem neuen Erzeugungsereignis dazu kommt, wird mir das auch automatisch zum Behandeln übergeben.

In diesem Fall sollte ich nicht fest auf die vorhandenen [User/Sytem]AccountCreated reagieren, sondern auf die Basisklasse AccountCreated. Ansonsten würde ich Ereignisse eines neu dazu gekommenen Kontos nicht behandeln, und die Systemerweiterbarkeit ist nicht gegeben. Angenommen, ich möchte eine Liste aller Konten darstellen, mit der Bezeichnung der Kontoart und der Kontobezeichnung. Für Systemkonten ist das “Systemkonto”¹⁴⁾ plus die Bezeichnung des Kontos, z.B. “Outlook-Schnittstellenkonto”, für Personenkonten “Benutzerkonto” samt der Personenbezeichnung. Das ist schon nicht ganz so einfach, weil die Kontoart in die Sprache des Anwenders übersetzt werden sollte, und weil UserAccount nur die PersonID hält, nicht aber die Personenbezeichnung kennt. Und was, wenn neue Kontenarten dazu kommen?

Wir haben somit identifiziert, welche Gemeinsamkeiten die unterschiedlichen Kontoarten besitzen sollen. Die Bezeichnung der Kontoart plus die Bezeichnung des Kontoinhabers. Welche Ereignisse führen nun dazu, dass sich die Bezeichnung des Kontoinhabers ändert? SystemAccountDescriptionChanged wäre eins. Was ist mit der Personenbezeichnung? Die Person eines UserAccounts ändert sich nie, aber die Bezeichnung kann sich ändern, entweder weil sie korrigiert wurde, oder weil die Person ihren Namen geändert hat¹⁵⁾. Muss ich also wissen, dass ich auch auf PersonNameChanged Ereignisse lauschen muss? Das ginge ja noch, aber bei neuen Konten wäre das nicht mehr möglich.

Zusammenfassende Ereignisse für Projektionen von abstrakten Klassen. Als erstes muss identifiziert werden, welche Gemeinsamkeiten für abstrakte Klassen existieren. Dann werden Ereignisse eingeführt, die Änderungen an diesen Gemeinsamkeiten melden. Diese Ereignisse werden ausgelöst durch

• andere Ereignisse. Z.B. wird ein handler von PersonNameChanged eingebaut, der den neuen Namen meldet. Dieser handler behandelt ebenfalls UserAccountCreated, um zu wissen, zu welchem Benutzerkonto die Person gehört. Beim behandeln von PersonNameChanged wird also der neue Personenname gespeichert, das Konto¹⁶⁾ der Person werden ermittelt, und für jedes wird ein AccountDescriptionChanged(Guid AccountID, string Description) Ereignis ausgelöst. Keine Ahnung wie dieses Muster heißt, es ist aber einfach zu verstehen und genauso einfach zu implementieren,
• regelmäßige Abfragen. Wenn Namensänderungen z.B. nicht über Ereignisse gemeldet werden, würde man die Personenbezeichnungen regelmäßig abfragen. Wenn sich eine ändert, wird wie im ersten Fall dafür ein AccountDescriptionChanged Ereignis ausgelöst.

Es können beliebig tiefe Ereignisketten gebildet werden. AccountDescriptionChanged könnte z.B. von einem weitern handler in ein weiteres Ereignis gewandelt werden, usw.

Das Problem bei solche einer Push Lösung ist die, dass man es nur per Konvention von der Implementierung einer weiteren Account Klasse verlangen kann. Das ist aber immer noch besser als die Notwendigkeit, vorhandene Klassen für einen neue Account Klasse ändern zu müssen. Es geht ja darum, ein System erweitern zu können ohne vorhandene Systeme zu (zer)stören. Und genau das wäre damit erreicht. Zudem kann man die Konvention per Pull ein wenig formalisieren.

Account hat eine abstrakte Methode GetSubjectDescription(). Die muss von der geerbten Kindklasse implementiert werden; wie, ist der Kindklasse überlassen. SystemAccount würde einfach den Wert des Feldes Description raus geben. UserAccount würde entweder eine Projektion von der Person fragen, oder die Person direkt befragen, wenn sie im selben Prozess laufen¹⁷⁾:

public class UserAccount: Account
{
    ...
    private IPersonQuery PersonQuery { get; set; }
    public Guid PersonId { get; private set; }
    ...
    public UserAccount(IPersonQuery personQuery)
    {
        PersonQuery = personQuery;
    }
    ...
    public string GetDescription()
    {
        return personQuery.Get(PersonId).GetDescription();
    }
    ...   
}

IPersonQuery kann ein Repository<Person> dahinter liegen haben, eine Abfrage, etc.

Immer wenn die Kontobezeichnung benötigt wird, kann das Konto direkt befragt werden. Das Problem besteht darin, wann danach gefragt werden soll. Vor jeder Abfrage auf Daten, die die Kontobezeichnung benötigen? Wenn es 1.000 Konten gibt, und man eine Abfrage auf sie startet, müßten dann erst 1.000 Pullaktionen durchgeführt werden? Sinnvoller wäre ein regelmäßiges Abfragen, oder eine Push-Pull Kombilösung.

1. Es gibt einen Denormalisierer im Personen Kontext, der die Personenbezeichnung aktualisiert und dann eine PersonNameChanged(Guid id, string newName) Nachricht¹⁸⁾. Darüber wird dann ein AccountSubjectDescriptionChanged Ereignis Es gibt im UserAccount Kontext einen Handler, der eine SAGA startet sobald ein UserAccount erzeugt wurde. Die Saga lauscht auf AccountSubjectDescriptionChanged und auf PersonNameChanged. Derselbe Handler lädt dann aus dem Abfragedienst aus Punkt 2. die Personenbezeichung und meldet UserAccount Es gibt im UserAccount Kontext einen Denormalisierer, der auf UserAccountCreated Ereignisse lauscht, sowie auf die PersonNameChanged Ereignisse aus 1. Es muss einen Denormalisierer geben, der auf Ereignisse die Personenbezeichnung betreffend wartet, sowie auf Ereignisse, die ein UserAccount anlegen. Wird ein UserAccount angelegt, wird die PersonID gespeichert, damit der Denormalisierer weiß, dass die Bezeichnung dieser Person benötigt wird. Dann wird geguckt, ob die Personenbezeichnung bereits vorhanden ist. Wenn ja, wird gleich hinterher ein AccountSubjectRenamed mit der Bezeichnung hinterher geschickt.
   
   Der Handler für UserAccountCreated kann jetzt ==== Service Locator ==== Die Kontoartbezeichnung sollte einen Default haben, z.B. in Deutsch. Jedes DTO für Account wird zudem den Typ beinhalten, also 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.