Der Authentication BC verwendet Vererbung für das Konto¹⁾. Ein Konto kann entweder ein System darstellen²⁾ 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³⁾. 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⁴⁾ im Employment BC ist eine 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⁵⁾, 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⁶⁾ über die PersonID⁷⁾. 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⁸⁾. Wenn also ein Konto mit einer ID = XYZ identifiziert⁹⁾ 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 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¹⁰⁾.