Service 调用问题

• 資深大佬 : sheeta

  ServiceManager 如何

• 資深大佬 : ebingtel

  不合理感觉……潜在的问题是: 导致循环引用……可以在上层进行组合调用多个 service

• 主 資深大佬 : rainbowyao

  @ebingtel 组内开发人员都约束一样，约定只能单向调用应该就不存在循环引用了

• 主 資深大佬 : rainbowyao

  @sheeta 没怎么用过啊

• 資深大佬 : ebingtel

  @rainbowyao 业务 service 多了 是怎么保证单向调用对 肉眼么? 方法就是: 绝对不允许 service 之间调用

• 資深大佬 : Egfly

  Service 之间应该不能调用。如果发现有共用的逻辑，可以考虑再抽出一层，比如 logic

• 資深大佬 : securityCoding

  不合理 , 往下抽一级出来 , 我习惯命名 component , 可以看看阿里巴巴开发手册关于项目结构命名的规范

• 資深大佬 : yeqizhang

  分层这么严格的吗？我之前都是有注入其它 service，也没遇到什么问题。
  不知道这么写会有什么问题？有问题之后尽量不这么写了……

• 資深大佬 : DebugTy

  dao -> repository -> service

• 主 資深大佬 : rainbowyao

  这么一看好像都是反对的声音，学习了

• 資深大佬 : wysnylc

  可以互相调用,要不然怎么重用????

• 資深大佬 : yidinghe

  Service 和 service 之间应该存在领域划分，应该职责边界合理分明，这样做的目的是保持数据的内聚性，避免胡乱调用导致低性能。

• 資深大佬 : xuanbg

  1 、搞一个公共类，两个 services 都调用公共类里面的静态方法。
  2 、搞一个基类，两个 services 都继承这个基类。
• 資深大佬 : miniliuke

  @yidinghe service 之间的交互通过 Eventbus 吗？总感觉这样写出了减少了耦合但是代码不可读性上升了……搞个更高层的 Service 做代理？有什么好的解决方案么？

• 資深大佬 : mazyi

  业务 service 互相不能掉，还有基础 service 嘛。不要局限于 service，应该看看构架啦。

• 資深大佬 : yidinghe

  @miniliuke 如果合理的分类和命名 event/publisher/handler，并且能够在 IDE 中追踪，其实代码可读性并没有受到太大影响。比如说我有个事件 UserLoginEvent，那么代码中要有一个约定，就是所有构造 UserLoginEvent 对象的地方一定是发布事件的地方，所有将 UserLoginEvent 对象作为参数的方法一定是处理事件的方法。如果不遵守这个约定，比如将 UserLoginEvent 对象到处传递，这就影响代码可读性了。

• 資深大佬 : ZSeptember

  可以相互调用的。

• 資深大佬 : optional

  可以互相调用啊，否则为什么封装 service，不过循环引用尽量避免。

• 資深大佬 : nutting

  spring 可以自己解决循环依赖吧

• 資深大佬 : iffi

  facade 即可

• 資深大佬 : namelosw

  首先得说清楚是什么 Service，Service 是现在 overload 最严重的词了。

  我发现上说得也都不是一个东西。

  我们一般说 Domain Service，Application Service，Microservice 。应该还有无数种 service 。

  凡事没有绝对，不过我们一般 Domain Service 不能互相引，Application Service 可以。

  对于 Microservice，这个问题比较复杂：
  1. 不互相引，经常会导致 service 之间逐渐分层，最后出现底层和上层 service，一般是 microservice 反模式。不过有人非得硬扯美其名曰中台。
  2. 不互相引，但是靠 BFF 或者 composer 协调，固定两层。经常会导致 BFF 或 composer 写了很多逻辑，而且很多纯给其他 service 传话用的。
  3. 不互相引，每个 service 靠 subscribe event 过日子，需要的时候得自己存一份数据。相对复杂。
  4. 互相引。很直接。开始代码简单，功能好实现，不能独立部署，但是后面会很乱，最后看起来比单体更复杂。
  5. 回单体。有时候其实也不是个坏选择，取决与业务。正如 SICP 里说的，逻辑可以被有效拆分的时候才适合用面向对象范式，领域之间互相的关系太紧密就不适合，比如模拟量子力学（所有单位都互相影响）用 OO 就是找不痛快。业务越复杂越像量子力学。Service 只是更大的 Object，所以这个说法也同样适用。

  这种问题出现的原因是切分 service 切分错误，或者粒度过细，导致 service 之间业务会互相依赖。所以碰见很多这种问题是切分问题，在 1234 或者其他选择里面选基本都是错的，没有太好的办法。如果只碰见很少这种问题怎么解都不难。

  最理想的情况是 service 之间老死不相往来，每个 service 负责一个很独立的领域，偶尔有很小的交互，这时候 123 任选就行了。所以不太确定的时候可以切得大一些，熟练了之后可以逐渐向细粒度发展或者重构。

  实在没办法改可以把关系密切的几个 service 合起来当一个小组，这个小组看作一个单独的 servcie，小组之间可以用 4，组间用 123 。

• 資深大佬 : Aaronsunny

  是可以调用的，但是最好还是往下下沉一层，从架构的角度上来看更合理。