namelosw
2020-05-14 12:40:55 +08:00
首先得说清楚是什么 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 。