使用 @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

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

可以考虑用文件锁来实现，初始化的时候在系统本地序列化一个文件，启动项目时检测文件是否存在，不存在跳转到引导页，但是前后端分离的情况下还是挺烦的，初始化这些配置文件只需要加载一次，所以没有获取文件锁的时候动态创建接口给前端用来保存配置。

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 的视角出发的。
信不信书这件事要看自己的深度，如果你到了一个陌生的领域还是不要轻易下结论。

我觉得你说的是集成测试
如果 B 依赖是个 autoconfig 可以是用 exclude 排除掉
如果不是 autoconfig，那么生命周期应该是你自己控制的。

最佳实践都在各种规范里 先去把 servlet 规范看了 然后看接口传输协约定，如 restful 论文没有明确规范，但是为了你的最佳实践，所以建议你总结出一套经得起时间和规模推敲的规范。然后到后端处理，工界和学界针对意见不一致的问题先解决掉。然后基本可以总结出你想要的最佳实践了

oauth2.0 就可以解决资源鉴权问题。

依赖注入不就做这个的