架构的道与术-软件架构设计

何为道，何为术

方法论，即是架构的道。
具体来说，对于技术问题，主要指高并发、高可用和一致性方面；
对于业务问题，主要指业务的需求分析和业务建模。这些方法论来自大量的业务系统实践，并在实践的基础上进行了思考和总结。
道的东西往往会比较虚，可能说了半天对方还是不知道你说的是什么。但越是“虚”，越是“抽象”，就越有必要阐释清楚，而这也正是本系列文章要解决的一个问题：把抽象玄幻的业务建模方法论、晦涩难懂的分布式一致性理论，用通俗的语言表达出来。
但要讲道，首先得讲术，因为得先有“地基”。术方法的东西大家比较容易理解，就是某种具体的语言、框架或者中间件的使用技巧。术的东西比较具体，具有实操性，容易描述，不会陷入“不知所云”的局面。

道与术的辩证关系

在武侠小说中，练就一门顶级武功，会同时涉及两个东西：一是内功心法，二是外部招式。前者是道，后者是术。但凡武林中的顶级高手，一定具有深厚的内功。那些招式花哨但内功不深厚的人，在江湖上通常只能在平常人中耀武扬威，一旦跟高手过招，往往只需几个回合就好原形毕露。
这样比喻道与术的关系很容易理解。但这样又有夸大内功心法、轻视外部招式的嫌疑，让人觉得内功心法比外部招式重要，导致外部招式被忽视。
在中国哲学中，一直有一个核心思想：“知行合一”。个人觉得用这个来表达道与术的关系会更为贴切。知，是理论，是套路，是解决问题的方法论；行，是实践，是操作，用于解决一个个实际问题。先有实践，然后总结出理论，用理论指导新的实践，在新的实践中再总结出新的理论。如此循环往复，即是归纳和演绎循环往复的过程，也是螺旋式上升的过程。
具体到软件架构，就是道和术都不能偏废，一方面需要不断实践，在实践中深究原理；一方面要把实践的东西抽象、总结出来，形成方法论。但在实际中，为什么很多人热衷于术，而不是道呢？因为短期能看到术的结果，想要看到道的效果却要长期地修炼，必须到了一个顿悟的拐点，才能发出惊人的能量。
除了从“知”和“行”的角度去看待，还可以从“问题”和“方案”的角度去看待。术偏重于“方案”，是工具，是锤子；道偏重于“问题”，是钉子。可能是拿着锤子去找钉子，也可能是遇到钉子在去想找个锤子或者造个锤子。