Zugreifen auf Sitzung in Domänenobjekt

Question

Wir verwenden Ereignisbeschaffung in unserer App und müssen auch den Benutzer verfolgen, der Änderungen an vielen unserer Objekte initiiert hat. Zur Zeit haben wir Code wie dieser

class Order { 
    setNameBy(newname, User user) { 
    applyChange(new OrderRenamed(user.id, newname)); 
    } 
    : 
} 

Da die meisten unserer Methoden wie diese sind und alle von ihnen sind wie diese die Session Zugriff innerhalb des Domain-Objekt

setNameBy("a new name", SessionContext.currentUser) 

wir, wo Kontemplation genannt. das heißt: es fühlt sich ein bisschen chaotisch, um das Session innerhalb des Domain-Objekt

setNameBy(newname, User user) { 
    applyChange(new OrderRenamed(user.id, newname)); 
} 

wird

setName(newname) { 
    applyChange(new OrderRenamed(SessionContext.currenUser.id, newname)); 
} 

Ich persönlich bevorzuge die später Methodensignatur wie es natürlicher auf der anderen Seite Nähte.

Wie also behandeln Sie Sessiondaten wie diese am besten in DDD/CQRS Apps? Ist es OK, auf den SessionContext in den Domänenobjekten zuzugreifen, oder sollte ich andere Methoden wie die Ereignisanreicherung verwenden, um diese Informationen zu den von der Domäne ausgegebenen Ereignissen hinzuzufügen?

Answer 1

Wenn das Verfolgen des Benutzers, der die Änderung initiierte, häufig auftritt, wird der SessionContext ein inhärenter Teil der Lösung und daher IMO der Pfad des geringsten Widerstands (eine gute Lösung). Vielleicht wird eine Neuformulierung von UserContext es weniger nach einer "dreckigen" technischen Kopplung klingen lassen? :)

Ich verwende oft einen Thread-gebundenen Kontext in meinen Anwendungen (beide Ereignisquellen und nicht), und wenn Ihr SessionContext.currentUser eine Ausnahme auslöst, falls ein SessionContext nicht an den Thread gebunden wurde, kann es auch Hilfe, Bugs während des Tests zu finden (zumindest hat es für mich).

Die Alternative könnte darin bestehen, das Ereignis als Benutzerverfolgung (z. B. über eine Schnittstelle) zu markieren und das Ereignis anschließend anzureichern. Das fühlt sich für mich etwas umständlicher an und kann möglicherweise die Problemlösung erschweren, da eine nicht gebundene SessionContext-Ausnahme außerhalb der Geschäftsfunktion auftritt, die die Benutzerinformationen erfordert.

Beide Lösungen sind IMO gut genug Lösungen, so ist es meistens eine Frage von wo Sie die Kopplung mit dem SessionContext wollen.

Answer 2

Ich bevorzuge es, meine Domain-Modelle völlig von äußeren Details zu ignorieren. Wenn Ihre Domänenobjekte erfordern, dass die Benutzer-ID Geschäftsregeln durchsetzt, würde ich Ihre aktuelle Vorgehensweise verwenden und den Benutzer als Argument senden. Wenn Sie nur die Benutzer-ID für Tracking/Auditing-Zwecke benötigen, können Sie das Ereignis anreichern.