按照 Spring 事务管理的要求，事务都是加在 Service 层上，Controller 层只调用一个 Service 方法处理业务。
现在我比较疑惑的是，比如我某个业务，需要在 用户、组织机构、商品 等不同的 Service 方法上分别进行处理，这种该如何放在同一个 Service 方法中？
如果我在同一个 Service 类中注入这多个模块的 Service ，岂不是又增加了代码的耦合度？感觉很矛盾。
兄弟听过领域驱动设计没有，简单点可以分为四层分别是接口层，应用层，业务层，持久层，你这种不就是单个业务单个业务层封装，大业务放上一层应用层面，应用层就是一堆业务的集合，满足特定业务需求，这种耦合实为正常耦合，不想代码处理，那就sql呗，有业务联系一条sql也能跑出来
你应该在service类中注入其他模块的dao吧。业务层如果你只处理当前模块的事情，那还要service层干什么，直接全都写在dao岂不是更好？
以我的理解 可以利用设计模式中的 工厂模式来统一管理 不同功能的service，这样代码的扩展性也好点
接口+设计模式。用户，组织，机构，商品，不在同一个维度，归纳为不同板块，单独对外提供接口服务。
或者使用命令模式，定义用户，组织，机构，商品的基础属性，根据需要调取实现不同的业务方法。
代码耦合完全避免未免有点不合实际，只是在开发中尽量避免
你可以看看事务传播特性