做业务不要先考虑“解耦“，而是要先满足业务流程。即你的程序的结构应该是一个个纵向的业务流，从controller到最后的数据存储。不同的业务流不会相互干扰。
等到你做了很多个业务流后，再去尝试辨识哪些地方有可能是能公用的，再去尝试去复用。公用的前提是这块代码几乎很少改
这块代码有比较合理的业务抽象 —— 即从人类直觉上这给地方抽出来也是说得通的
就算这块代码要改。他的改动对其他依赖造成的影响总是符合常识的，而不是会引发一大堆问题
如果得不到这样的特性，即使代码看起来有相似之处，也不要去抽。错误的抽象才是代码维护的大敌。一旦做了，你根本控制不了你的修改的影响范围和影响程度。
题主对解耦的理解也有偏颇。从题目上看，似乎“逻辑不写一起“就解耦了，而写在一起就耦合。实际上并不是这样的。不要认为任何业务逻辑可以做任何细粒度的拆解。从业务角度，一个业务是一个“步骤的集合”。总会有第一步干什么，第二步干什么，等等。很多时候，这些步骤写一起才更容易看懂，更容易修改和维护。
更精细的区分，一个业务的逻辑大概可以分为两类：业务直接相关的主逻辑。比如你要实现下单买东西，那么创建订单、扣款是主逻辑。这些逻辑必须要写到一起，而且往往用同一个事务包起来保证一致性。如果主逻辑非常复杂，就尝试用多个层级来拆解这些流程，但他们还是在一起。
业务辅助相关的逻辑。比如更新计数、更新ES的搜索数据、发一个业务统计log等。这些内容可以不要掺合到主逻辑中。可以用AOP，事件队列(单机的/分布式的)的形式来解耦。
但解耦是有前提的。事实上解耦会让系统结构更复杂了。比如一个业务接口调用完了，计数却没有增加，或者晚了很久才增加。要调查问题，就需要系统监控等做的相当到位。团队的相关模块负责人可以有办法来精确的管理跨系统的数据流，能快速定位错误原因。
同时，你的产品设计也可能需要跟着更改。比如计数可能因为最终一致性而暂时不准，会引起用户的困惑。这时候产品设计上可能需要一个临时的“假的，但是符合用户直觉“的计数，或者以各种方式隐藏计数等措施来对产品做调整。
解耦不是写业务代码的最终目标，用可以接受的性价比进行业务开发和代码维护才是。如果你的team里没有那么多人来各自负责独立的模块，也没有很好的INFRA支持，而是很少数几个人处理所有逻辑，那整体看下来还不如把代码都写一起。
