DIP 这里引入的是必要的复杂度，还是意外的复杂度。
这里是 jhipster 针对目前 spring mvc 模式中针对 service 接口从‘技术角度’上的理解
Should we use interfaces with our Service Beans?
Short answer: No.

If you want the long answer, here it is:

One of the main interests of using Spring is AOP. This is the technology that allows Spring to add new behaviors on top of your Beans: for instance, this is how transactions or security work.

In order to add those behaviors, Spring needs to create a proxy on your class, and there are two ways of creating a proxy:

If your class uses an interface, Spring will use a standard mechanism provided by Java to create a dynamic proxy.
If your class doesn’t use an interface, Spring will use CGLIB to generate a new class on the fly: this is not a standard Java mechanism, but it works as well as the standard mechanism.
Some people will also argue that interfaces are better for writing tests, but we believe we shouldn’t modify our production code for tests, and that all the new mocking frameworks (like EasyMock) allow you to create very good unit tests without any interfaces.

So, in the end, we find that interfaces for your Service beans are mostly useless, and that’s why we don’t recommend them (but we leave you with the option to generate them!).
但是！
如果仔细想想为什么使用接口进行依赖注入是一种增加复杂度方式，因为根本没有通过依赖注入获取到任何好处。
让我们在去想想接口的特性，可以被多个类多实现，最大程度上解耦。问题就在这里了，为什么我们的接口很少被多个类实现，是我们写的 curd 更多的业务是面向过程的代码，没有针对业务进行抽象归纳总结，是 oop 编程的一种反模式。
而书中的论点更多都是以 oop 的视角出发的。
信不信书这件事要看自己的深度，如果你到了一个陌生的领域还是不要轻易下结论。