@
guijianshi01 哈哈哈，理解理解，我就这么过来的。我的做法不敢说是完美，也是一个一个坑才过来的血泪史。
最核心的，我称为核心功能接口，我是尽最大可能划分到最细的粒度，比如一个 auth，这类接口我设计的时候原则上是不直接暴露给前端调用的，因为直接暴露意味着给前端需要请求太多的内容，无论性能还是开发流程上都不可接受，前后端会打架的。
但这类接口也不绝对，某些高频，无法也无需改动的，比如授权，这种模式下我会适当直接传给前端。
然后核心功能接口写出来其实是为了给后端调用的，用来做各种业务接口组合。这里面也是血泪史，差点和后端打疯，后端说我几个 import 的事你非要我调网络请求的形式来（我们目前的能力只能以 RESTful API 的形式互相调用），包括业务接口不一次写完，而是写完再组合… 但最后后端发现，在不同的项目中，熬过前期后，往往重新组合包装一个接口提供给前端，会变的异常轻松。
当然这里也有 API 网关这个我 18 年年初才学到的概念的支援。包括我上面讲的模式里，其实在包装组合接口提供给业务用这件事上，前端突然发现他们也有能力直接调用以及做组合了，所以业务上其实突然变的相对好一些了。
但一个系统的总体复杂度是不变的，对应的，压力放到了我这边，我自己做的这个设计和决策，现在我要为统筹管理和理清这么多接口、模式进行负责，这个压力也大。可总比和大家一起开会分析那绕来绕去的业务逻辑还是要轻松一些的。
所以我写了这么多，其实也没有直接回答你的问题。全部写一起肯定是弊大于利，畏手畏脚，甚至逼不得已要重新写一个新的大的单体出来。拆开的不合理的话，又会东改西改，并且接口功能重复，模糊，界限不清。
但就我自己的经验而言，还是要拆，拆的时候优先提炼出核心的不变的东西，尽可能在少增加额外开发的情况下将接口复用组合提供出业务接口来。而且业务接口尽量不要由核心系统直接提供，一定要有个 API gateway 层，让这个层来承担接口的分发工作。 我们用的也不好，业务中有大量冗余接口，也有很多沉没的存在安全隐患的东西，这个以后早晚要慢慢解决。但小公司，四五个人的团队，只能先到这样了。