访问域对象中的会话答案

【问题标题】：Accessing Session in Domain Object访问域对象中的会话
【发布时间】：2012-04-11 14:11:39
【问题描述】：

我们在我们的应用程序中使用事件溯源，并且严格需要跟踪对我们的许多对象发起更改的用户。目前我们有这样的代码

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

由于我们的大部分方法都是这样的，所有的方法都是这样调用的

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

我们正在考虑访问域对象内的 SessionContext。即：

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

变成

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

我个人更喜欢后面的方法签名，因为它接缝更自然，另一方面，访问 Domain 对象内的 SessionContext 感觉有点混乱。

那么，在 DDD/CQRS 应用程序中，您如何最好地处理此类会话数据？访问域对象中的 SessionContext 是否可以，还是应该使用其他方法（如事件丰富）将此信息添加到域发出的事件中？。

【问题讨论】：

【解决方案1】：

如果跟踪发起更改的用户频繁发生，则 SessionContext 成为解决方案的固有部分，因此 IMO 成为阻力最小的路径（一个足够好的解决方案）。也许对 UserContext 的改写会让它听起来不像是“肮脏”的技术耦合？ :)

我经常在我的应用程序中使用线程绑定上下文（包括事件源和非事件源），如果 SessionContext.currentUser 抛出异常以防 SessionContext 未绑定到线程，那么它也可以帮助发现错误在测试期间（至少对我来说）。

替代方法可以将事件标记为需要用户跟踪（例如使用界面），然后再丰富事件。这对我来说有点麻烦，并且可能会使问题解决变得更加困难，因为未绑定的 SessionContext 异常将发生在需要用户信息的业务功能之外。

这两种解决方案都是 IMO 足够好的解决方案，因此主要取决于您希望在哪里耦合到 SessionContext。

【讨论】：

【解决方案2】：

我更愿意让我的领域模型完全不了解外部细节。如果您的域对象需要用户 ID 来执行业务规则，我会使用您当前的方法并将用户作为参数发送。如果您只需要用户 ID 来进行跟踪/审核，您可以丰富事件。

【讨论】：