域专用接口

Question

与领域模型中的抽象类相比，使用接口有什么实际好处吗？是否有人在实际项目中使用领域模型中的接口有任何经验？

从技术角度来看，DDD定义了聚合、值、存储库等构造型。例如，存储库可以定义为像ICustomerRepository这样的接口，然后由基础结构实现。这是接口的有效用例，因为存储库可以有多个实现(模拟、伪造等)。然而，这完全是使用它的一个技术原因:在这里，接口只用于将特定于域的存储库与其技术实现分离。

但是纯粹的特定于域的接口呢？有没有人遇到过接口和实现都是非技术的情况？特别是，在实现特定于域的类型时，选择接口而不是抽象类的原因是什么？也许当涉及到多重继承的时候，它是必需的，但是它有多大的可能性，那么它能被认为是一个好的设计吗？

Answer 1

是否有人在实际项目中使用领域模型中的接口有任何经验？

我们有很多interfaces，其中有几个有很大的问题，那就是时间耦合-和不可知的耦合.

应该是一个模板化的抽象类

实际实现中的接口方法排序和代码结构清楚地表明，如果不知道这些方法应该如何交互，就根本不可能实现interface。不仅什么方法叫什么其他方法，而且在什么条件下，和特别必要的细节w/在个别的方法。

在看到第三个实现之后，很明显，有一个重构尖叫出来，但不能因为发生了什么给出的代码：

• 时间的蹂躏
• 不同编解码器
• 最糟糕的是，不同的编解码者在不同的时间，尤其是在不可避免的工作人员翻转。

后续实现是“不同的，而不是与众不同的”

。

第一个实现是模仿的--我并不是说必须剪切和粘贴--在下一个和下一个等等实现中，细微差异的必然结果是，在密切的(和耗时的)检查中被证明仅仅是不同。

维护在几个方面得到了dis增强--

1. 缺乏抽象的阶级结构助长了对单一责任原则的严重违反。
2. 这个东西就成了干爽的海报。
3. 不相关的实现差异和SRP违规行为掩盖了真正的功能共同性。
4. 不可避免的是，一些实现揭示了一个常见的错误，但只有在报告错误的地方才能修复。对于从事大型项目的人来说，这并不令人惊讶。
5. 不可避免的是，有些实现引入了一些bug，这些错误会被具有基础实现和错误处理的抽象类所阻止。
6. 重构变得(a)太耗时(b)太危险(c)通常不切实际