tawiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Autorisation ======
//"Authorization is orthogonal to the domain"//. In anderen Worten ist die Autorisation in den meisten Domänen((mit Ausnahme der Autorisations-Domäne)) nicht expliziter Bestandteil der Domäne, und sollte so gebaut werden, dass sie so wenig intrusiv ist wie möglich.
\\ \\
In den meisten Fällen kann einfach der Befehl genommen werden, zusammen mit dem authentifizieren Anwender, und es wird geprüft, ob der Anwender das Recht hat, den Befehl auszuführen. Ein Problem besteht, wenn der Befehl nicht alle notwendigen Informationen beinhalten, um ihn autorisieren zu können. Der Prozess der Autorisierung kann in dem Fall das //read model// bemühen, um die notwendigen Informationen zu ermitteln.
===== Fälle in denen das Read Model versagt =====
Angenommen es gibt folgende Befehle
  * Lege Termin für Mitarbeiter in Projekt an
  * Ändere Termin auf einen anderen Mitarbeiter
  * Ändere Termin auf ein anderes Projekt
  * Ändere die Termin Details
Angenommen es gibt folgende Rechte
  * Mitarbeiter dürfen eigene Termine anlegen und beliebig ändern
  * Projektleiter dürfen Termine in ihren Projekten für alle Mitarbeiter anlegen und beliebig ändern
Jetzt passiert folgendes
  - Mitarbeiter ABC legt einen Termin in Projekt P1 für sich selbst an
  - Mitarbeiter XYZ, Projektleiter im Projekt P1, bucht den Termin auf Mitarbeiter DEF um, und ändert dabei einige Details des Termins
  - Mitarbeiter ABC ändert die Details des Termins
Schritt 3 sollte nicht mehr möglich sein wenn Mitarbeiter ABC nicht Projektleiter im Projekt P1 ist. Wenn die Autorisierung aber lediglich das //read model// verwendet, und die Umbuchung des Termins auf Mitarbeiter DEF im //read model// noch nicht sichtbar ist, wenn der dritte Befehl abgeschickt wird, würde der dritte Befehl autorisiert werden, weil der Absender und Termininhaber((im Lesemodell, nicht in der Domäne!)) beide Mitarbeiter ABC sind. Mitarbeiter ABC würde somit fälschlicherweise einen Termin für Mitarbeiter XYZ ändern.
===== Das Modell ist das Problem =====
Der Workflow von oben zeigt, dass das Modell problematisch ist. Wenn ich Termindetails ändern möchte, schicke ich zwar meine Logindaten mit, damit der Service weiß, dass ich, Mitarbeiter ABC, die Änderungen abschicke. Aber weder in den Logindaten, noch im Befehl, steht drin, wem der Termin gehört. Der Befehl lautet z.B. "Ändere die Terminlaufzeit auf 08:00-12:00 für den Termin mit der ID 355DD55321EE".
\\ \\
Im Grunde müsste ich den Befehl darüber autorisieren, indem ich mir die Entität(en), für die der Befehl gilt, hole, sie analysiere, und dann prüfe, ob der Befehlsgeber die nötigen Rechte für die gewünschten Änderungen hat. Ich würde mir also den Termin mit der Nummer 355DD55321EE holen, gucken für wen er ist, und dann prüfen, ob der Aufrufer das Recht für die gewünschte Änderung hat.
\\ \\
Das Modell ist also nur problematisch, wenn ich mit einer Kopie des Termins arbeite((aus dem read model)), und den Befehl genehmige, ohne zu wissen, ob die Kopie überhaupt noch aktuell ist. In manchen Fällen mag das in Ordnung sein, z.B. wenn die relevanten Daten unveränderlich sind. In anderen Fällen kann es problematisch sein. In diesen Fällen müsste man sich die Entitäten direkt über Repositories geben lassen, in dem Wissen, dass der Befehl dann auch auf genau diese Entität angewendet wird((Geladene Entitäten im Aufruf müssen also gecached werden können)). Zudem **müssen die relevanten Eigenschaften des Befehls abfragbar sein**. CQS sollte immer zur Anwendung kommen, CQRS nur bedingt.
\\ \\
Es gibt somit keine Königslösung. Wie in so vielen Fällen hängt die Lösung davon ab, was gefordert ist.
tawiki

User Tools

Site Tools

Page Tools
