特定角色的知识库与特定的知识库

Question

直到我找到这个文章，我才知道特定于角色的存储库。

我们可以选择将接口隔离原则应用于基于角色的接口，并定义只公开一个类所需的接口，而不是在阳光下公开每个方法的所有存储库。公共接口IProductRepositoryForNewOrder { Product[] FindDiscontinuedProducts()；} 单个存储库实现实现了所有产品存储库接口，但调用方只公开和使用所需的单一方法。

( a)两者之间的区别在于，对于特定的存储库，每个聚合根有一个特定的契约，而角色特定的存储库每个聚合根可以有几个契约，每个契约都是针对在聚合根上操作的特定调用者的需要而量身定制的？

( b)在你看来，这两种模式的利弊各有哪些？

谢谢

更新：

昨天，我发现了一个答案，本质上您认为应该使用特定于角色的存储库模式：

“另一种选择是使用lambda而不是OrdersSelectorService。如果您的语言中没有lambda，那么它应该是一个接口。传递OrderRepository的好处是基于接口隔离原则，其目标是减少不必要的耦合。客户的行为不太可能需要OrderRepository上的所有方法，而是需要一个特定的功能，因此要做到这一点是明确的。”

为什么在上面的摘录中，您提倡使用特定于角色的存储库模式，但在这里，您似乎建议只在特殊情况下使用它。另一个话题中的例子是否是一个特殊的情况(不管怎么说，我不是说你在自相矛盾，我只是不明白这两个例子在使用或不使用特定角色的模式方面有何不同)？

Answer 1

我完全支持可靠的代码，但是接口隔离原则确实有其局限性，特别是在DDD上下文中。

拾取模式

如果您将ISP应用到信函中，您几乎可以从文章中获取关于存储库的声明，并将其稍加修改。

使用域实体的类很少使用其中的每个方法。

因此，对于每个域实体，您应该创建与实体的客户端一样多的接口，只使用每个接口中与客户端相关的方法，并使实体实现这些接口。

当然，这是荒谬的，没有人会这样做。但是，ISP应该是一个通用的OO概念，不是吗？

/选择器模式

现在，如果我们回顾一下ISP存在的最初原因，我们就会发现它是用来对抗胖接口的，即那些没有凝聚力的接口。但是，存储库本身不是有凝聚力的吗？它不是一个基本的原子DDD构建块吗？它应该被分割成几十个小型查询对象吗？此外，我们领域中的每个类不是都应该与无处不在的语言保持一致吗？ProductRepoInterfaceForClient1、ProductRepoInterfaceForClient2、ProductRepoInterfaceForClient3等接口的情况并非如此.

不要误解我的意思，ISP仍然很有用，尤其是作为一种方法来检测接口的契约是否比它应该的更异构。鲍勃叔叔关于ISP的原纸有很好的例子--参见“接口污染”段落和ATM示例。

但是，一旦达到了合理的内聚水平，ISP就不应该被盲目地应用，特别是如果它与基本的DDD原则相冲突，或者用数百个接口淹没您的代码库，这将成为一场噩梦。