|上篇：技术架构的设计方法( 四 )

极限思考法在 review 技术架构方案风险相关的内容时，我都会特意问一下，如果出现 XX 问题最坏的业务影响是什么。为什么是问最坏的业务影响，是因为如果谈风险那肯定都是有一点点的，不利于大家去深究最关键的问题。通过极限设问，其实是激发大家去做最坏的打算，有了最终极的兜底手段才能够更乐观去做技术变更。
对称思考法在 review 代码或者逻辑结构时，在深挖细节和关键点后，我时常会拔出来看看整体的逻辑结构是不是饱满，是不是对称，是不是美。最简单的例子就是写了 if 我一定要有 else ，不然没对称结构就让我很不舒服。因为我相信对称的美就是一种生产力，因为美的东西一定是简洁且直达本质的。而我们写程序要的就是逻辑清晰简单直达业务本质，逻辑结构清晰的基本上没大问题，不清晰（如变量瞎命名，方法无语义）的深挖下去多半都能发现大问题。根源就是逻辑清晰代码才清晰，代码不清晰基本上就是逻辑混乱，逻辑混乱就会产生 BUG 。
M*N ---M+N
这个思考方法的含义是：当我们思考技术问题时，可以尝试从系统耦合的角度去思考，尝试找一些突破口。
我举一个实际的 CASE ，高速公路网的连接不是把所有目的地之间都修一条高速公路，而是会选择修建复用的高速公路主干道 + 分支道路的方式来组织这个网络。一条一条串联的方式就是耦合在一起的，这就是 M * N 。通过主干道 + 分支道路的方式就是解耦的， M + N 就能够组建这个高速网络。
在技术架构上如何运用解耦这个技法，我有如下几个提炼。
解耦上下游关联性在业务和技术架构发展的前期，把很多东西糅杂在一起是最快解决问题的方法。但随着业务和平台架构的进一步演进，势必是要做解耦，目的就是重新去界定各个模块的边界，平衡新的业务发展要求下各方发展快慢的诉求差异，通过解耦互相松绑快速发展。
这种技法在服务化的分布式架构中非常常见，基本上跨域的平台架构升级都有解耦的影子。
解耦各个角色的依赖解耦上下游关联性其实更多是在技术模型的抽象上，但在落入到技术模型范畴之前，还有就是我们在做更加抽象的解决方案探讨时要注意解耦各个角色之间的依赖。上述【架构考虑所有可能性但做有限明确实施】中提及的就是最好的案例。其实这里的本质表达就是，技术架构的设计应该要与商业选择，产品设计等解耦开来。
通过这一层的解耦其实能够多个角色之间基于 SLA 去交互，并且能够基于自身的专业思考给予对方更多的选项和可能性。很多时候的前瞻性和竞争力可能就是比别人多一个选择。
解耦思考法其实很有意思，几乎所有的大型平台架构升级都有这个思考法的影子，所以下次没啥思路的时候可以从这个角度做一个审视思考，说不定是有新的收获。
小结以上是我在做技术架构方案时沉淀总结的一些思考方法，这些思考方法不可能解决遇到的所有实际问题，只能算是一个思考提示，在遇到问题可以尝试从这几个方法去看看是否有灵感。基于方法论但是不局限于方法论才是方法论最大的意义和价值。接下来一篇文章，我会从技术 Leader 的视角谈谈我在实践中的一些思考。
作者简介：知明，蚂蚁金服国际事业群资深技术专家，全球资金平台技术负责人，负责了蚂蚁全球化进程中底层资金清结算、外汇等平台能力的搭建和迭代演进。
本文为阿里云原创内容，未经允许不得转载。