我可以从真实的世界的项目中看出，它在没有接口的情况下工作得很好，只有实现类。遵循“你不需要它”（YAGNI）的原则，如果你遵循这个规则，你就简化了你的代码。依赖注入也可以很好地与类一起工作，接口不是它的必要条件。
当然，你可以编写和重用测试实现，但是你也可以用mock来做同样的事情。并覆盖测试用例的实现类的行为。

我已经通过所有的答案在这里，但想添加更多的代理
AOP可以使用JDK代理或CGlib代理
如果类实现了接口，它将使用JDK代理（当您有选择时首选）。如果类没有实现接口，它将使用CGlib代理。

这不是必须的，也许是基于意见的，但您正在添加接口以实现未来服务的灵活性，
尽管您看不到真实的使用情况，但它将允许您在单元/集成测试中使用特定服务的不同实现
您可以添加测试实现而不是当前实现，并在执行测试时使用它而不是真实的的服务（例如通过使用不同的Spring配置文件）
正如@Simulant所指出的，这可以使用模拟来完成

实际上不需要，目前，微服务或迷你代码库很受欢迎。因此，通常情况下，在rest API后端，你真的没有机会为某些接口提供服务。在这种情况下，带有@Serivice的具体类就足够了。

无论你想从依赖注入（DI）模式中获得什么好处，你都需要针对抽象进行编程，通常是接口。
DI还有更多的好处，但最有说服力的似乎是它允许单元测试。在那里，你的接口将至少获得一个实现（模拟实现），当你想要测试你的类时，它将与它的依赖项（接口的生产实现）隔离。
也就是说，这并不意味着每个类都必须实现某个接口。代码的某些部分可以毫无问题地紧密耦合在一起。
请注意，使用或不使用Spring并不影响使用DI/不使用DI的决定。

正如其他人所建议的那样，这实际上取决于用例。虽然Spring和Java一般都是作为一种冗长的语言开始的，在设计中，接口应该充当客户端，实现类，可以看到的东西，但我发现这些天越来越少的冗长代码，尤其是。使用Sping Boot 和Lombok等库。
因此，为Service、DAO创建接口并不是强制性的，但如果您正在处理一个相当中等的代码库，其中有多个开发人员和可能的客户端在应用程序外部使用这些API，那么这是首选。但是如果您正在为一个小型项目或概念验证项目工作，那么您也可以在一个Java类上创建CRUD应用程序。

也许我是不走运，但每当我看到基于这种接口创建的微服务时，我都会认为它毫无意义。从实际的Angular 来看，接口没有增加任何好处，它只会增加官僚主义。尽管它没有提供任何附加值，但总是有一些开发人员用各种论点为接口创建辩护。事实上，人们应该考虑它现在实际上带来了什么好处，如果没有任何好处，那么就问一个问题，为什么我们要这样做。