说点题外话01｜好耦和与坏耦和

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

能展开讲讲为啥CQRS是邪教吗？Event Sourcing呢？

基础设施属于是完成业务的必须，从业务上有必然耦合性；至于选啥实现，则是偶然耦合。 前面有提到过，对于基础设施层，可以通过封装借口提供能力解耦合。 作为小白，希望能够更多的看到如本章所讲的基础知识内容。对新手来说，这些内容在段时间能给我带来的价值是非常巨大。我感觉最欠缺的，就是这些基础的。

必然耦合和偶然耦合不是绝对的，反而会相互转化，并且在不同时期，看问题的角度不同，必然和偶然也不同。所以做项目决策才会这么难

基础设施层是偶然耦合，都是些具体实现。转换方法就是转换成实际的业务概念，这样从模型角度就屏蔽了细节，也就消除了偶然耦合。

“这种盲目地对具体实现的恐惧，以及盲目地将所有具体实现都归结为偶然耦合的一刀切的做法，其实是我们行业的一大病，同时也是很多具有迷惑性的烂代码的来源。看起来整整齐齐，所有变化点都考虑到了，实则并没能简化问题，也没能降低理解难度，只是写的人自己爽了而已。” 文中支付的例子，开始说是对支付宝微信“必然耦合”，后面又通过抽象出“在线支付能力”变成了对支付宝微信的“偶然耦合”。感觉这就是盲目的将所有具体实现都归结为偶然耦合的一刀切的做法了吧。毕竟在线支付发展到今天微信支付宝占市场90%以上，不可能不支持他们了。

感觉这个抽象业务能力也是一个玄学，支付宝和微信支付可以抽象为在线支付，也可以抽象为支付，到底抽象到啥地步可能取决于一个人的长时间的工作积累。抽象的过粗和过细可能都不利于后续的维护

老师，能力供应商模式是不是拟人化的防腐层，平时使用样式也差不多，在domain定义接口，在基础层实现，根据DIP，通过spring Ioc实现，看着的确很一样 “不要用解决方案去定义问题。而是问题定义解决方案”能不能再详细说说

基础设施层实现的接口是必然耦合，这些接口在领域层中应该体现为业务能力而不是业务能力的具体实现。基础设施层本身是对接口（业务能力）的具体实现，是偶然耦合。

太精彩了，现在的程序员对耦合还真是PTSD，但来源不同，一种是自己的确受到了伤害，一种是听人说会受伤害，想到了著名的“猴子实验”。这篇文章绝对是对面向接口编程以及ISP认知的重要基础 面向接口编程，在OO世界里这是上帝，放之四海皆准，所以看每个项目所有的service都有一个interface,一个impl，相当整齐，问为什么要这么做呢？面向接口编程，防止未来扩展性，但现实项目从始至终都不会有第二种实现，但不能不这么做，这是公约，谁都得这样，不然就变成那只被打的猴子 Martin Fowler有提出role interface和header interface的定义，技术还是得反馈到业务的本质，从业务上去寻找业务能力，得到必须耦合的能力，给调用方提供稳定依赖