oop - DDD - 实体不能直接访问 Repositories 的规则

Question

在领域驱动设计中，似乎有 lots的 agreement实体不应直接访问存储库。

这是否来自埃里克·埃文斯 Domain Driven Design书，还是从别处来的？

对它背后的推理有什么好的解释？

编辑:澄清:我不是在谈论将数据访问从业务逻辑分离到一个单独的层的经典 OO 实践 - 我在谈论在 DDD 中实体不应该与数据交谈的具体安排根本没有访问层(即它们不应该保存对 Repository 对象的引用)

更新:我给了 BacceSR 赏金，因为他的答案似乎最接近，但我对此仍然一无所知。这么重要的原则，网上应该有什么好文章吧？

更新:2013 年 3 月，对这个问题的赞成意味着人们对此很感兴趣，即使有很多答案，我仍然认为如果人们对此有想法，还有更多空间。

Answer 1

这里有点困惑。存储库访问聚合根。聚合根是实体。这样做的原因是关注点分离和良好的分层。这对小型项目没有意义，但如果您在大型团队中，您想说:“您通过产品存储库访问产品。产品是实体集合的聚合根，包括 ProductCatalog 对象。如果要更新 ProductCatalog，则必须通过 ProductRepository。”

通过这种方式，您可以非常非常清晰地分离业务逻辑和更新内容。你没有一个 child 独自离开并编写整个程序来完成所有这些复杂的事情到产品目录中，当涉及到将它集成到上游项目时，你坐在那里看着它并意识到它一切都必须抛弃。这也意味着当人们加入团队、添加新功能时，他们知道去哪里以及如何构建程序。

可是等等! Repository 也指持久层，就像在 Repository Pattern 中一样。在一个更好的世界中，Eric Evans 的 Repository 和 Repository Pattern 将具有不同的名称，因为它们往往会重叠很多。要获得存储库模式，您需要与其他访问数据的方式(使用服务总线或事件模型系统)进行对比。通常当你达到这个级别时，Eric Evans 的 Repository 定义顺便说一句，你开始谈论有界上下文。每个有界上下文本质上都是它自己的应用程序。您可能有一个复杂的批准系统来将东西放入产品目录。在你的原始设计中，产品是中心部分，但在这个有界上下文中，产品目录是。您仍然可以通过服务总线访问产品信息和更新产品，但您必须意识到有界上下文之外的产品目录可能意味着完全不同的东西。

回到你原来的问题。如果您从实体内部访问存储库，则意味着该实体实际上不是业务实体，而可能是应该存在于服务层中的东西。这是因为实体是业务对象，应该尽可能地像 DSL(领域特定语言)一样关注自己。该层只有业务信息。如果您正在对性能问题进行故障排除，您就会知道要查看其他地方，因为此处应该只包含业务信息。如果突然之间出现应用程序问题，那么扩展和维护应用程序变得非常困难，而这正是 DDD 的核心:制作可维护的软件。

回复评论 1 : 对，好问题。所以并不是所有的验证都发生在领域层。 Sharp 有一个属性“DomainSignature”，可以满足您的需求。它具有持久性，但作为一个属性可以使域层保持清洁。它确保您没有重复的实体，在您的示例中名称相同。

但是让我们谈谈更复杂的验证规则。假设您是 Amazon.com。您是否曾经使用过期的信用卡订购过商品？我有，我没有更新卡并购买了一些东西。它接受订单，用户界面通知我一切都很好。大约 15 分钟后，我会收到一封电子邮件，说我的订单有问题，我的信用卡无效。这里发生的事情是，理想情况下，域层中有一些正则表达式验证。这是正确的信用卡号吗？如果是，则保留顺序。但是，在应用程序任务层有额外的验证，其中查询外部服务以查看是否可以通过信用卡进行支付。如果没有，请不要实际发货，暂停订单并等待客户。这一切都应该在服务层中进行。

不要害怕在可以访问存储库的服务层创建验证对象。把它放在域层之外。