我正在我的系统中创建域模型。在设计模型对象时，我应该为每个实体对象创建接口吗？人们告诉我，我们的Web层不应该关心实体的实现，我们应该能够交换实现，但我不确定是否会发生。
例如，如果我们有一个维护学生列表的Teacher类，则getStudents方法可以是：
public List<Student> getStudents() {
return this.students;
}
或这个：
public List<Student> getStudents() {
return someExternalService.retrieveStudents();
}
我理解这个好处，但一般做法是什么？
除非你有充分的理由认为你需要换掉模型，否则我不会担心它。基于YAGNI原则（你不需要它）
我见过或参与的项目都没有域实体的接口。
但在我的一个项目中，我有界面 NamedEntity：
public interface NamedEntity {
int getId ();
String getName ();
}
所有域实体都实现了此接口。它让我有可能不为不同的实体创建不同的jsf转换器，但创建一个使用此接口而不是具体域类的转换器。
我不能说一般的做法，但这不仅仅是隐藏实施。
它是将接口正式化为文档和合同的基础。
在将模型抽象为接口时，您将为服务客户端开发人员创建文档。根据您的开发风格，您可能已经或可能没有正式的服务描述（例如，基于WSDL的描述）。接口可以满足这种需求。
我认为具有检索对象的服务接口和模型对象本身之间存在重要区别。
在运行时，加载模型对象的服务可能会根据您请求数据的位置而有所不同。但无论您如何创建此对象，预期的数据对象的格式和类型都不会更改。因此，携带状态的模型对象不需要接口，但是创建和加载这些模型对象的服务类需要接口。
如果模型对象不仅仅是一个简单的bean类型的对象，而是一个暴露某种行为的对象，那么模型对象拥有接口的唯一原因就有意义。
我的一般观点是，我愿意 不 为域模型创建一对一的接口集，因为这除了复制域模型的类结构之外什么都不做。它没有添加任何有用的东西。
这两个案例我可以立刻想到我 将 考虑引入接口是：
换句话说，添加接口，如果它们可以帮助您描述行为或帮助您隐藏客户端的实现细节。其他原因可能是有效的，但这些是我想到的两个。
提取接口是最简单的重构之一;最坏的情况是它是一个类重命名 - >移动方法。一旦你找到理由，改变主意的努力是微乎其微的。我总是发现，如果一个决定很容易改变，它会更加强化YAGNI和KISS。相反的论点是，最初创建一个接口并不是很费力，这是正确的，但如果做出多次决定，维护会随着时间的推移而增加 - 通常不会被使用。