方法论设计的四个步骤

前一篇文章「微服务设计的十个步骤」，其实是我的一个技术架构方法论（methodology）再经过特定化和简化的结果。方法论是指为了达到某目标的一套做事情的逻辑。有了方法论，其他人就有了可以依循的规矩和流程，降低事情的难度。

关于「如何设计方法论」，我自己又有一套方法论（又抽象了一层），在这篇文章中分享给 iThome 的读者。既然这是「用来设计方法论的方法论」，这篇文章介绍的其实是 meta-methodology。

设计方法论，首先你必须要有一个参考模型（reference model）。请注意，参考模型本身就是模型，并不是 meta-model。

以我的微服务设计方法论来说，我先设计出了三维技术模型，这是一个「通用」的技术架构参考模型。这个模型是我多年来演化的结果，使用了三个维度，第一个维度是业务（Business）维度，第二个维度是技术（Tech）维度，第三个维度是维运（DevOp）维度。每个维度又分成数个层次，这三个维度以「笛卡儿乘积」，看起来就像是个魔术方块。

一个好的参考模型必须做到：1 尽可能通用于许多领域 2. 容易用程式码实现 3. 功能需求容易设计 4 不会阻碍非功能需求的设计 5. 可以降低后续调整的难度

参考模型和框架（framework）非常类似，但参考模型是虚的设计规範，而框架是实际的程式码系统半成品。也就是说，一旦你有了参考模型，你接下来就可以往实现框架的目标迈进。请参考本专栏的第六篇「架构能力的四个阶段」。

参考模型就像是一个样板（template），里面有许多格子，每个格子的分工以及格子之间的通道都已经提前设计好了，大家根据每个格子的描述，往格子里面填入东西。这就是设计方法论的第二个阶段：找出「填入格子」的方法。这个方法的关键在于：能够配合敏捷开发流程，通过迭代的方式递增式地设计和开发。

我看过的所有架构设计方法，都没有考虑到和敏捷的相容，这使得这些架构方法都太「笨重」，不太可行。现在的商业环境变化如此快速，除非你是垄断性质的产业，否则没人能够花一年两年的时间做详细设计，然后才去实现。只有敏捷才能够降低风险，敏捷是必须的。没有敏捷的技术架构，就没有敏捷的开发，就没有敏捷的业务，就没有敏捷的企业。

架构和敏捷真的不相容吗？我不认为，而且我试图证明这一点。在「微服务设计的十个步骤」方法，是以「场景」（scenario）作为驱动的，这符合敏捷以功能点或特徵驱动的作法，且场景更全面，更关心用户的目的，尤其场景也是我的「技术建模」和「商业建模」之间的一个衔接点。

设计方法论的第三个阶段是：建立自我优化的机制。比拟董事会（执行）、监事会（监察）、股东会（决议）的关係，我希望系统本身就像一个公司，也具备执行、分析、调整的循环，提供这样的机制来持续优化自己，甚至为未来的自动化和智慧化提供可能性。所以「微服务设计的十个步骤」中的第八和第十步骤，分别对业务和维运提供执行、分析、调整的机制。

设计方法论的第四个阶段是：降低难度。以「微服务设计的十个步骤」为例，我一开始只要求分解前端和后端这两层，接下来才继续分解前端和后端为五层，接下来才把这五层根据技术来分解，接下来才又把分解的结果根据运维来分解。这个过程大大地把难度降低了。

这篇文章介绍的是设计方法论的方法论，也就是所谓的 meta-methodology。「微服务设计的十个步骤」是实践这个方法论的结果，而我还有另一个方法论，是用来设计商业的，也是实践这个 meta-methodology 的结果。这两个例子的存在，解释了meta-methodology 的意义，它是用来设计方法论的方法论。