2008-10-07 50 views
12

如果你有一个领域对象,并且你想要做一些有用的和中心的领域对象的责任,如确保它是有效的,你有时需要访问相关对象的状态以执行此验证。如何避免贫血的领域层,并仍然有丰富的验证和业务规则

如何避免域对象需要调用到存储库或数据访问层?由于性能的原因,即使使用延迟加载,您也无法始终采用集合关系,而且您经常希望在域对象中执行查询。您可以将存储库实现依赖注入到域中,但不是真正纯粹且复杂的测试。

我总是放松一些事情,并允许使用DI从域访问存储库。我没有看到如何在复杂的应用程序中创建“纯”域图层的清晰示例,该应用程序并不贫乏,并且服务/应用程序层做了所有的咕噜声并且弄乱了应该成为域对象内部的东西。

回答

12
  • 如果对象是一个值对象,它 应该是不可变的,施工期间验证 。

  • 如果对象 是根聚集,且其 自己的状态足以告诉你 如果它是有效还是无效,你可以在上面通过汇聚添加 验证方法,其中 级联。

  • 最后,我认为这是你的主要 关注,如果你需要访问 几个相关对象(即是 不在同一集合),以确保 其中之一是有效的,你 明确需要在特定的验证服务中将这种逻辑推回 。

我真的认为注入服务和存储库到实体并不是最好的选择。创建专门的服务似乎更合适,我不明白为什么它会导致你有贫血域对象。

简而言之,如果您可以在不依赖服务或存储库的情况下验证对象状态,请让对象在聚合根级别处理它。当您需要查询服务或存储库时,或者当您需要其他实体时,则强烈考虑将此逻辑移到对象之外。

+0

注入到实体是保持域层解耦的主要思想。在实体中注入存储库是最佳选择。你的专业服务是什么意思?仅当命令的上下文跨越多个实体时才使用域服务。不应该有专门的实体服务。 “ - (2x减)” – Tudor 2012-10-04 23:08:55

1

几小时前我回答了一个类似的问题。答案中包含一些指导原则,当我尝试用逻辑和行为来丰富我的模型,但不会使依赖于与技术相关的东西变得肮脏。 Having trouble putting real-world logic into the DDD domain layer

该答案还链接到其他有用的资源。

祝你好运,随时给我发邮件或问我关于DDD和避免贫血模型。这是一个有趣的话题,人们倾向于以不同的方式解决这个问题。