patterns:inheritancerolestragegyoverview:inheritance
Differences
This shows you the differences between two versions of the page.
|
patterns:inheritancerolestragegyoverview:inheritance [2013/01/08 16:27] rtavassoli |
patterns:inheritancerolestragegyoverview:inheritance [2013/01/08 16:29] (current) rtavassoli |
||
|---|---|---|---|
| Line 47: | Line 47: | ||
| * 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. | * 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: | 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 Bezeichnung des Kontoinhabers im Benutzerkonto. Wie diese Bezeichnung 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, | + | * 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. | * 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. | 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. | ||
patterns/inheritancerolestragegyoverview/inheritance.1357658832.txt.gz · Last modified: 2013/01/08 16:27 by rtavassoli
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported
