====== Vererbung, Rollen und Strategien in CQRS mit Event Sourcing ======
{{ :patterns:inheritanceroleandstrategy.png |}}
Der Authentication BC verwendet [[patterns:inheritancerolestragegyoverview:inheritance|Vererbung]] für das Konto((Account)). Ein Konto kann entweder ein System darstellen((z.B. einen Dienst, der Rechte haben muss um Schnittstellen bedienen zu können)) oder eine Person. Dabei kann die Person entweder direkt im Konto über den Namen identifiziert werden, oder sie kann wie in PRO•M einer Person zugeordnet werden((Wobei die Person im Authentication BC lediglich durch ein Value Object, die PersonID, dargestellt wird. Es ist dem Authentication BC egal, was dieses Value Object darstellt. Die eingezeichnete Referenz von UserAccount zu Person ist auch nur //gedacht//. Es gibt Übersetzer im //Anticorruption Layer// zwischen den Kontexten um aus einer PersonID im UserAccount eine Person im Person BC zu identifizieren)). Es ist theoretisch möglich, dass Konten auch noch andere Dinge darstellen werden, z.B. Personen aus anderen BCs als des //Person BC// in PRO•M, daher wird gleich die Möglichkeit eingebaut, von Account abzuleiten.
\\ \\ 
Der Mitarbeiter((Employee)) im Employment BC ist eine [[patterns:inheritancerolestragegyoverview:role|Rolle]] einer Person im PersonBC. Das wird nicht über eine PersonID in Employee dargestellt, sondern dadurch, dass die EmployeeID die PersonID //ist//. Die Person in Person BC wird auch nicht über die Mitarbeiterrolle erweitert((obwohl das möglich und auch vorbereitet ist - abstrakte Rollen einer Person, die dann z.B. von Employee geerbt werden können)), sondern komplett im Employee BC implementiert. Das ist eine stärkere Trennung als das Rollenmuster, aber in der Konsequenz ist es dem Rollenmuster ähnlich. Die Trennung in einen separaten Kontext vereinfacht die Komplexität des Systems. Will ich mit einer Person interagieren, lade ich die Person und sende Befehle an sie. Will ich mit der Person in der Rolle eines Mitarbeiters interagieren, lade ich den Mitarbeiter((Employee)) über die PersonID((Anstatt die Person zu laden und dann über person.GetRole(typeof(Employee) ) die Mitarbeiterrolle zu erhalten)). Sobald ich die Rolle im Zugriff haben, kann ich sie direkt ansprechen, d.h. es geht hier lediglich darum, wie ich Zugriff auf die Rolle erhalte, und in diesem Fall ist es über ein eigenes Employee Repository.
\\ \\
Der Account im Authorization BC könnte ebenfalls als Rolle von Account im Authentication BC gesehen werden. Das ist aber nicht der Fall. Die Kontexte existieren neben einander, unabhängig voneinander, und können sich getrennt voneinander weiter entwickeln. Eine Übersetzung in einem Anticorruption Layer wird die Verbindung zwischen den Konten herstellen((in dem einfachsten Fall über ein und dieselbe ID)). Wenn also ein Konto mit einer ID = XYZ identifiziert((authentifiziert)) wurde, dann wird das Konto aus dem Kontext in ein Konto im Autorisierungskontext übersetzt, um die Rechte des Kontos zu prüfen. Auch wenn es nicht in der Überschrift steht, ist das ein gutes Beispiel für das Aufteilen von Aufgaben in unterschiedliche Bounded Contexts, und wie man die BCs einfach und überschaubar hält, sie aber weiterhin //zusammen arbeiten lässt// indem man ACLs implementiert, die zwischen den Kontexten übersetzen.
\\ \\
Die Authentifizierung wird über das [[patterns:inheritancerolestragegyoverview:strategy|Strategy Pattern]] implementiert. Anstatt UserAccountUserNameAuthentication von UserAccount abzuleiten, und SystemAccountUserNameAuthentication von SystemAccount, ist es sinnvoller, jedem Konto eine Strategie zur Authentifizierung an die Hand zu geben. Erstens kann dadurch dieselbe Strategie für die unterschiedlichen Kontoarten verwendet werden, zweitens können die Strategien unabhängig von den anderen Bereichen erweitert werden. So kann z.B. eine //X.509// Strategie dazu kommen, ohne dass irgend ein anderer Aspekt der Anwendung angepasst werden muss((Das alles dient dem //Open-Closed concept//: Ein System soll offen für Erweiterungen sein, aber geschlossen für Änderungen)).