spring cloud 有必要把所有 api 接口放在一个模块中吗

[zhb1nk]

最近在学习 spring cloud，看到一个视频中老师把所有模块的 controller 写成了接口，都放在了一个叫 api 的模块中，然后在每个业务模块中写接口的具体实现。想问下这样有必要吗，各位在实际的工作中会选择这样做吗？谢谢！

[xuanbg]

不建议这么做。我都是按功能先分 C 端 B 端，然后分大模块，再分小模块把包分好。最后在小模块里面建 xxxController/xxxService/xxxServiceImpl 这么 3 个文件。好处是层次分明，找文件非常方便。而且以后要拆分服务也很方便，整个包复制到新项目后老项目里面删掉就行了，不需要到处找文件。

[waising]

没必要吧。都拆分了没必要在关联一起，内部自由调用就行了

[yelog]

不同业务的逻辑和 api 写在各自的业务模块，通过 gateway 等组建进行路由即可

[XuHuan1025]

知道了 慕课网的课全放在 service-api 接口

[Uchiha0bito]

合理 接口和实现分开 只提供一套接口给调用方

[gangsta]

视频通常只是为了快速演示而已。几年前在一个现场活动中看到 Spring 官方的团队成员，应该是叫 Josh Long，做 coding 演示的时候为了图快直接把 controller 、java bean 还有 service 写在同一个 class 里面，然后他打字又很快(差不多就是边念英文边打)，一顿骚操作现场全部惊呆了...

[young1lin]

@gangsta 是这样的，我看他的 Spring Cloud Kafka Stream 的教学视频，全部放在一个类里面，就是为了演示快，一把梭。人家是 Spring 布道师，是 Pivotal 团队的，也是 《 Spring Cloud Native Java 》的作者。

[fanlis]

我怀疑人老师是不是写的 OpenFeign 接口

[stramkismet]

我一般喜欢把服务间调用的接口单独写个 api 模块(feign 接口),然后给其他服务进行引用。controller 继承这个 api 模块。

[hyqCrystal]

我来整理一下，不知道理解的对不对，参考一下，我也经常看开源项目的结构
有人说这种业务都拆分了，没必要写在一起，但是其实写在一起是微服务化将 api 抽象方便统计管理 fegin API
当然，我猜想这个写法的第一个人 思想应该是来源于之前用 Dubbo，后来大家都这样写
有利有弊吧： 利：好管理接口和 Fegin 接口 弊:微服务解耦开发项目模块的思想又被干回去了

[hyqCrystal]

@xuanbg 服务之间的调用 又得写一遍 interface 了 写一起应该是解决这个问题的 另外，api 模块也可以区分 B 端和 C 端

[xuanbg]

服务之间调用为啥又要写一遍，原来接口不好使吗？
@hyqCrystal