Differences

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

--- patterns:inheritancerolestragegyoverview:inheritance [2013/01/08 15:59]
rtavassoli
+++ patterns:inheritancerolestragegyoverview:inheritance [2013/01/08 16:29] (current)
rtavassoli
@@ Line 35: / Line 35: @@
 === Besprechung ===
   * 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((oder der Datensatz wird dort nicht angezeigt)). Man kann den Handler aber auch selbst dazu bauen, wenn man entsprechende Kenntnisse von den verwendeten BCs hat,
+  * Wenn ein neues Konto dazu kommt, sollte es einen Handler mitbringen, der die AccountInfo füllt. Ansonsten wäre die Info im UI immer leer((oder der Datensatz wird dort nicht angezeigt)). 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,
@@ Line 41: / Line 41: @@
   * 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((und alle erweiterbaren Typen)) sollte den Typ des Kontos beinhalten((das sollte im Grunde automatisch passieren - wird in das Framework eingebaut)). 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.
+=== Doppelt gemoppelt? Gefahr widersprüchlicher Daten? ===
+Ist das nicht alles doppelt gemoppelt? Ich habe doch die Personenbezeichnung im Personenkontext, wozu nochmal in den AccountInfo Kontext schreiben? Aus mehreren Gründen
+  * Die Bounded Contexts sollen einigermaßen autark sein. Wenn ich was im Authentifizierungskontext mache, möchte ich dort alles haben, was ihn betrifft((eventuell gemeinsam mit den diversen Info-Kontexten...)).
+  * Die Koppelung der Kontexte soll auf ein Minimum reduziert sein. Wenn die Referenzen nicht explizit aufgelöst werden, sondern implizit gehalten und jedesmal ermittelt werden müssen, sind die Systeme stark aneinander gebunden,
+  * Man könnte eine Sicht inklusive der Bezeichnung des Subjektes((was oder wen das Konto repräsentiert)) auf alle Konten haben, die dann von Handlern wie oben aufgezeigt gefüllt werden. Man bräuchte dazu keinen zusätzlichen BC und kein AccountInfo Aggregate. In dem Fall würde die Projektion((Sicht)) von allen weiteren Projektionen, die sich für die Bezeichnung interessieren, geteilt werden. Wenn es keine weiteren Projektionen gibt, wäre das ein einfacher und sinnvoller Weg. Wenn es aber mehrere Projektionen gibt, die den Bezeichner benötigen, und wenn man davon ausgehen kann, das weitere dazu kommen werden, ist eine Basisprojektion nicht mehr sinnvoll. Die anderen müssten Zugriff auf sie erhalten, sie ständig abfragen, und Änderungen an der Basisprojektion müssten über //Projektionsereignisse-/Meldungen// mitgeteilt werden. In dem Fall sollte man sich dazu entscheiden, das Ganze explizit zu machen und einen eigenen Kontext mit einer echten Domäne dafür zu bauen.
+Was ist mit der single-source-of-truth? Die wahre Personenbezeichnung der Person eines Benutzerkontos steht doch in den Personenereignissen. Wenn wir ihn jetzt nochmal in die Ereignisse des Authentication Info BCs schreiben, haben wir zwei mögliche unterschiedliche Bezeichnungen für ein und dieselbe Person. Dazu folgendes:
+  * wir haben nicht zwei unterschiedliche Bezeichnungen für eine Person. Wir haben die Bezeichnung der Person im Personenkontext, und wir haben eine //Repräsentation// des Kontoinhabers im Benutzerkonto. Wie diese Repräsentation aufgebaut sein soll entscheidet das Benutzerkonto, nicht der Personenkontext. Dort kann alles mögliche stehen, es bedeutet nicht, dass die Person eine falsche Bezeichnung hat, sondern dass die Sicht des Benutzerkontos auf die Person eine andere ist,
+  * die Applikation stellt sicher, dass die Bezeichnung im Konto schließlich mit der Personenbezeichnung übereinstimmt. Das ist die Eventual Consistency, von der gesprochen wird. Das gilt natürlich nur, wenn die Systeme fehlerfrei laufen, aber auch Fehlerbehebung ist ein Teil von Eventual Consistency.
+Was ist mit //Event Enrichment//. Man könnte die Ereignisse bereichern((z.B. mit dem //Decorator Pattern//)) anstatt eine neue Domäne zu bauen mit eigenen Ereignissen. Ich finde eine zweite Domäne wesentlich einfacher als Ereignisse zu bereichern. Das Abfragen der bereicherten/dekorierten Ereignisse nach ihrem Typ und den internen Eigenschaften der Basisklassen ist komplexer als eigene, zusätzliche Ereignisse. Zudem ist eine nachträgliche Bereicherung bereits vorhandener Ereignisse unmöglich. Info-Kontexte nachträglich dazu zu bauen und mit historischen Ereignissen zu befüllen ist aber möglich - und sehr einfach.

tawiki

User Tools

Site Tools

Differences

Page Tools