DDD 存储库可以知道用户上下文吗？答案

【问题标题】：Can DDD repositories be aware of user context?DDD 存储库可以知道用户上下文吗？
【发布时间】：2011-03-21 05:33:02
【问题描述】：

假设您要开发一个系统，该系统的实体和域逻辑的可用性高度依赖于用户上下文。通过使各个存储库实例了解用户上下文来处理存储库中的用户上下文敏感性是否有意义？我正在考虑采用这种方法作为一种将用户上下文的依赖从我的实体中拉开的方式，但我不确定在这个方向上是否存在我可能不知道的任何陷阱。我计划首先解决此问题的方法是将 UserContext 参数添加到需要此上下文信息的存储库的构造函数中。另一个明显的选择是将用户上下文信息提供给我的存储库中的每个查询方法，但这可能意味着所有方法中的大多数都需要这样的参数，这反过来会大大增加每个方法调用的详细程度。

另外我想指出的是，即使我要让存储库用户上下文意识到，当服务或实体出于诸如确定行为等原因需要相同的用户上下文信息时，这也不一定会直接帮助基于用户配置。我也对这些案例的其他解决方案感兴趣，但现在我尝试一次解决一件事，所以我首先关注存储库。

任何建议将不胜感激。

【问题讨论】：

@Nilesh 同意我认为这里有一个有趣的观点。 @jpierson 澄清是否需要 UserContext 来提供/计算访问您域中某些聚合的授权？这意味着管理员可以访问此聚合根，但普通用户无法检索它们？
@Kyri - 关闭，我有两种需要此上下文的情况，一种是根据用户可以访问的可能值验证值，第二种是在另一个值发生变化的情况下设置默认值在一个实体上。因此，一个示例可能是具有电话号码的联系人实体，并且当电话号码更改时，应验证其区号以确保它是当前用户具有管辖权的，并且如果它是有效的并且联系人的城市名称未设置，我们将默认城市名称与区号对应的值。
@josh - 我一直在推迟设计的这一部分，实际上我想出了一些我认为合理的东西。如果我最终继续前进，我会在这里接受最接近的相关答案，或者我会发布我的答案来解释我做了什么。您可能还想关注我的另一个密切相关的问题stackoverflow.com/questions/5454521/…。

标签： repository domain-driven-design

【解决方案1】：

我在这里闻到了设计的味道 :-)。当事物到达领域层时，它们几乎应该被翻译成领域实体/属性，并且不应该依赖于上下文。我的意思是应该使用上下文来更改/表示实体的新状态。在这里，似乎更多的是使用上下文来确定实体将如何被持久化。我是否理解正确？

话虽如此，如果您对上下文的依赖更多是从基础架构的角度而不是业务功能的角度来看，那么拥有上下文敏感的存储库就是您想出的正确模型。

为此，您是否可以考虑像 Spring 对 Hibernate Session 那样通过线程本地传递用户上下文？这样，您的 Repository 类的构造函数或方法的污染就会减少。但是，它确实会稍微降低代码的可读性。

希望对您有所帮助。

【讨论】：

@Nelesh - 我现在要解决的主要潜在问题是我的实体中的验证规则需要基于当前用户的信息才能进行验证。在这种情况下，用户上下文包含有关该用户的有效输入的信息。
@jpierson - 这样就可以在实体中建模，即这些验证和他们需要的输入将传递给实体并最终传递给持久性框架。