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!).

粘一段 Jhispter 对这里的理解

还面临一众读不懂 ddd 瞎吓唬 ddd 的人，比如一楼。

另外说一下你的开源项目，现在国内市场讲究攀交情比名气。所以找个好靠山背书（比如阿里的开源）比研究这些见效快

问题挺好。但是我面试的时候从来都问我 堆、栈、算法、数据结构、图、树。卷就完了。你聊这些你不怕面试官答不上来吗？

你以为国内培训班是山寨谁的？

你现在的问题不是研究单点登录，更应该重学一遍如何造句

使用 @entity 跟 spring 的 context 一点关系都没有。

果粉急了

远程验签，核心接口远程调用

@howells
关于这个 VO 的解释都是出自阿里的 java 开发规约。每个领域概念出现是为了解决问题而出现的。
DTO/VO 的概念重复。
有的公司会对给请求叫 xxxRequestObject 返回值 xxxResponseObject
这无可厚非所有领域概念都是人抽象出来的。
如果大多数人能从这个抽象概念中获取到实质的好处。那么这个概念就被推崇。如果不能那么这个概念只能提高架构的复杂度。加速代码腐坏。

https://stackoverflow.com/questions/1612334/difference-between-dto-vo-pojo-javabeans

Early J2EE literature used the term value object to describe a different notion, what I call a Data Transfer Object. They have since changed their usage and use the term Transfer Object instead.

https://docs.oracle.com/cd/A97335_02/apps.102/bc4j/developing_bc_projects/bc_awhatisavo.htm
希望楼上不要误导人

vo 两种解释 value object, view object
这两种 VO 都不应该返回给请求方

引用 DTO 是为了与业务 Domain 解耦合，在请求时对请求参数进行聚合

点赞 有学习到

你先粘两端代码上来，让大家评价，总有人自我感觉良好

https://docs.microsoft.com/zh-cn/dotnet/architecture/microservices/architect-microservice-container-applications/direct-client-to-microservice-communication-versus-the-api-gateway-pattern

看一下这个文章在微服务架构下，对网关的理解