DDD：为什么将单独的存储库方法分配给不同的接口？

Question

根据沃恩·弗农（Vaughn Vernon）的IDDD_Samples，存储库接口具有一些方法：发布身份（nextIdentity），保存实体（save），获取实体（{{1}） }），删除实体（productOfId），依此类推。

但是，很少在单个用例中使用所有方法。例如，在创建新实体的情况下，将使用两个方法remove和nextIdentity，但不使用其他方法。

从I nterface Segregation Principle的角度来看，我认为存储库的方法应该分成一些接口。这有什么帮助？

Answer 1

我的long-winded answer至another question归结为使客户处理“错误”事情的能力降至最低。

在“正确的”时间引入并使用更小的接口可以防止许多错误和开发人员可能引起的意外问题。

这意味着您的直觉将您引向正确的方向。您可以通过dependency injection或其他方式将这些“较小”的接口传递给具有更狭窄方案的组件（即针对每种用例设计的组件）。这样可以防止您或其他人自动执行“不应”执行的操作。

Answer 2

  

从接口隔离原理的角度，我认为应该将存储库的方法分为一些接口。这有什么帮助？

我将这样描述：接口隔离是以成本来实现的。

在这种情况下，隔离此接口会引入八个？新角色接口，每个接口都需要管理。可能更多，也许更少，这取决于我们要管理多少个不同的用例，以及我们要支持多少精细控制。

我怀疑，出于弗农的目的，他想要的是banana-清楚地表明了存储库的职责，而没有拖累大猩猩和其余丛林。

表达同一想法的另一种方式：这里的职责有很多cohesion-当您替换持久性解决方案时，很可能需要更改所有这些职责的实现，并且他们在一起改变是很自然的。

最适合本教程的解决方案是尝试向学生提出一个单一的想法，而最适合生活的系统的解决方案是您经常需要对职责的实现进行细粒度的更改。不一定相同。

课程的马匹。