1.讨论松耦合的前提是想清楚，为什么我们要松耦合，或则说所谓的高耦合有什么坏处。 2.松耦合的目标是维持代码的稳定性，防止由于多种变化方向或者变法频率不一样的代码耦合在一起，导致牵一发动全身的窘境，使代码变得极不稳定，既存在风险又增加运维成本。 3.所以至少我们能得到一条线索。松耦合需要保证一个类或者一个函数下的代码，都是一个维度的东西。而一个维度的东西可以认为就是徐昊老师说的必然耦合的部分。 4.铺垫完，回到我们的问题。基础设施层，到底应该是偶然耦合，还是必然耦合呢？我的答案是这两块其实都有。 5.先说基础设施偶然耦合的部分，比如db存储。我们的目的是将数据持久化，对应到业务角度的模型就是所谓的仓储层接口，仓储层接口与聚合/领域服务是一个维度的东西，所以仓储层接口是必然耦合的部分。而仓储层接口的实现，这就属于偶然耦合的部分，选择什么存储方式，在业务模型的角度并不关心。同理的还有实现事件发布接口的mq框架。 6.接下来说基础设施必然耦合的部分，比如透传traceId/全局异常处理/打印中间件调用出入参等等。这些都是与业务无关，与系统技术维护相关，属于功能增强的部分。当然，这一部分也可以进一步抽象出必然部分和偶然部分，然后保证必然部分的文档和偶然部分的灵活替换。但是，大部分时候这些功能增强基本不变，且就算变了改动成本也很低，可以认为它们相对稳定了很多。那么再进一步区分它们的必然偶然就显得有点多此一举，毕竟它的风险和运维成本都很可控。所以我觉得这部分直接认为是必然部分也并无不可。（spring不是做了必然部分的抽象吗？我的答案是，基础框架和应用项目决策的优先级是不同的，它必须保证你的兼容性，哪怕这个兼容性永远不发挥效果） 7.综上所述，业务相关的耦合，因为维护成本大，需要区分必然与偶然部分，做抽象保证业务模型的稳定。业务无关的耦合，维护成本有限，做必然偶然部分的区分属于过度设计，我认为直接识别成必然部分不用抽象亦可。