本来想针对前灯的话题再展开一点的，不过想想觉得自己对于前灯的理解基本上没有什么问题，也挺认同这个观点的，还是继续下一个话题。解耦
解耦是我非常期待的一个话题，我们很多时候觉得代码不够清晰，很大的一个原因就是分子太多，又不必要的依赖。
我先说说对于解耦我的理解，从物理世界来看，从小小的原子到完整的生物体乃至整个世界，实际上都是基于高内聚低耦合的原则组合而存在的。
从最小的原子就遵循这个原则，原子内部存在相互作用，但是原子之间的相互影响就弱很多。
然后原子与原子组合成为分子，这是更上一层的组合，依然遵从了这个原则，分子内部的作用远大于分子与分子时间的作用。
分子在组合成细胞，
细胞在组合成器官，
器官在组合成生物体(人)，
人和人组成家庭，
家庭和家庭组成城市，
城市和城市组成国家，
国家和国家组成世界(星球)，
星球和星球组成星系，
星系和星系组成宇宙。
每一层的组合都非常默契的遵从了高内聚低耦合的原则。
也就是要是把高内聚低耦合的思路贯彻好，用程序构建一个宇宙也不是问题。
和上面分层解耦构建世界的方式相似，代码里也存在分层解耦的情况，比如一些编程语言自带的工具和方法，你可以把它们看成是原子，他们之间本身已经解耦了。在上面一层是你利用这些工具搭建出的有业务含义的方法，这些业务方法和类构建出一个小的细分领域，多个细分领域构建出完整的系统。
先说一下这个细分领域到系统这个层次的解耦，这个其实是挺难的，他比较像是物理世界中把器官搭建成人体这一个层次。这一个层次的划分就没有其他层次这么清楚，“上帝”在造人的时候虽然也遵从了这个原则，但并没有其他层次那么清晰。这就造成了有可能你感到手麻，实际问题却出现在颈椎。你觉得头能，可能真正的问题是血压高。
虽然难，但还是应该尽可能去做，那么在这一层次解耦的关键是什么呢？我觉得无非是两点，一是在哪里切入解耦，二是如何保证解耦。这两点分别对应到产品设计和代码实现两个层面。
产品设计要明确切在哪里，比如我们的订单，运单，运输安排，预约，应收，应付，进出款申请，这一个流程下来应该切成几块？哪些适合在一起？哪些适合拆开？
代码实现其中一种方式就是微服务了，他保证我们没有办法直接去调用模块内部的方法，比如订单和运单假设是两个微服务，那么订单要改变运单的内容只能是告诉运单要怎么改，而不能直接动手改。
告诉运单怎么改和直接改的区别就是前者是显然的契约式编程了，按照运单暴露的接口来修改运单内容，那么这个契约就可以定义的非常清楚，不论是调用方还是被调用方都是一种一切尽在掌握的感觉了。
待续
网友评论