如果您有一个域对象，并且您想要做一些有用且对该域对象的职责至关重要的事情，例如确保它有效，您有时需要访问相关对象的状态以执行此验证。
如何避免需要调用存储库或数据访问层的域对象？由于性能原因，您不能总是遍历集合关系，即使使用延迟加载也是如此，并且您经常希望在域对象中执行查询。您可以将存储库实现依赖注入到域中，但不是真正纯粹的并且使测试复杂化。
我总是放松一些事情，并允许使用 DI 从域访问存储库。我没有看到如何在一个复杂的应用程序中拥有一个“纯”域层的明确示例，它也不是贫血的，并且有一个服务/应用程序层做所有的工作，并弄乱了域对象的内部结构。
【问题讨论】：
如果对象是值对象，它 应该是不可变的和经过验证的 施工期间。
如果对象 是一个根聚合，并且它的 自己的状态足以告诉你 如果它有效与否，你可以添加 一个验证方法，它 通过聚合级联。
最后，我认为这是你的主要 关注，如果您需要访问 几个相关的对象（即 不在同一个集合中）以确保 其中一个是有效的，你 绝对需要驱逐这个 特定验证服务中的逻辑。
我真的认为将服务和存储库注入实体并不是最佳选择。创建专用服务似乎更合适，我不明白为什么它会导致您的域对象贫乏。
简而言之，如果您可以在不依赖服务或存储库的情况下验证对象状态，则让对象在聚合根级别处理它。当您需要查询服务或存储库，或者当您需要其他实体时，强烈考虑将此逻辑移到对象之外。
【讨论】：
几个小时前我回答了一个类似的问题。答案包含我在尝试用逻辑和行为丰富我的模型时使用的一些指导，而不会使它因对基础设施技术相关内容的依赖而变得肮脏。 Having trouble putting real-world logic into the DDD domain layer
答案还链接到其他有用的资源。
祝你好运，随时给我发邮件或询问我有关 DDD 和避免贫血模型的信息。这是一个有趣的话题，人们倾向于以不同的方式解决这个问题。
【讨论】：