DDD存储库可以知道用户上下文吗?

假设您要开发一个系统,实体和域逻辑的可用性高度依赖于用户上下文.通过使个人资料库实例用户上下文感知来处理存储库中的用户上下文敏感度是否有意义?我正在考虑采用这种方法作为一种将用户环境依赖于远离实体的方式,但我不确定是否有任何陷阱,我可能没有意识到这一方向.我计划接近的方法是将UserContext参数添加到需要此上下文信息的存储库的构造函数中.另一个明显的选择是将用户上下文信息提供给我的存储库中的每个查询方法,但这可能意味着所有方法中的大多数都将需要这样的参数,这将大大增加每个方法调用的详细程度.

此外,我想指出,我知道,即使我要使存储库用户上下文感知,这不一定有助于直接在服务或实体需要相同的用户上下文信息时,例如基于用户确定行为组态.我对这些案例的其他解决方案感兴趣,但是现在我正在尝试一次处理一件事情,所以我首先专注于存储库.

任何建议,将不胜感激.

我感觉到这里的设计气味:-).当他们到达域层的时候,事情应该几乎被翻译成域实体/属性,不应该依赖上下文.我的意思是上下文应该用来改变/表示新的实体状态.在这里,更多的是,这个上下文将被用来确定实体将如何被持久化.我明白了吗?

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

为此,您是否可以考虑通过线程本地传递usercontext,如Spring与Hibernate Session?这样,您的Repository类的构造函数或方法将被更少的污染.但是,它确实会降低您的代码的可读性.

希望有帮助.

相关文章

什么是设计模式一套被反复使用、多数人知晓的、经过分类编目...
单一职责原则定义(Single Responsibility Principle,SRP)...
动态代理和CGLib代理分不清吗,看看这篇文章,写的非常好,强...
适配器模式将一个类的接口转换成客户期望的另一个接口,使得...
策略模式定义了一系列算法族,并封装在类中,它们之间可以互...
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,...