技术架构设计12原则（上篇）

在「架构能力的四个阶段」一文中，我提到我把架构的能力分为四个阶段，分别是架构原则（principles）、架构模式（patterns）、架构建模（modeling）、架构框架（frameworks）。其中第一个阶段是「架构原则」。架构原则是在架构设计领域中基本要遵守的原则，通常不会有太多条，且每一条都很简单、用处很广泛、彼此独立。我自己目前就建立了12条技术架构设计指导原则，这篇文章的目的就是为了跟iThome的读者分享这些原则。

架构原则1：不要使用Stored Procedure，因为这会让业务逻辑难以维护。资料库管理系统（DBMS）里面可以直接执行PL/SQL等程式，这种程式叫做Stored Procedure。这些年我在许多金融公司的工作经验让我发现Stored Procedure的问题重重，导致业务逻辑难以维护，应该尽量避免使用Stored Procedure。当然，不排除有人能把Stored Procedure的程式码写得非常好，有很好的抽象隔离和模组化，使得系统容易维护，但我看到的实际状况都不是如此，且Stored Procedure让业务逻辑和资料的储存结构结合得太紧密，这在未来系统调整时也会一个巨大的风险。

有人认为Stored Procedure直接在资料库内处理资料，执行效率比较好。但任何选择都有机会成本和风险，Stored Procedure非常可能会带来业务逻辑难以维护的危害，比起它带来执行效率提升的利益，大多数的情况下我们会选择「让业务逻辑好维护」。效率当然重要，但在这个时代，执行效率的提升通常会透过弹性灵活的分散式系统来达成，而不是透过单一个庞大系统效率的垂直提升。

架构原则2：一个系统内部可以包含储存和程式码，但系统间不能共用资料库。一个系统应该完整地控制自己的资料库，所有对资料库的存取都必须透过系统本身，不能直接去读写资料库，不光是不允许其他系统「写入」此资料库，就连「读出」资料也不行。如此以来，系统之间的依赖只透过API，当系统根据需要调整自己的资料格式和资料解读方式时，其他系统并不会受到影响。

架构原则3：逻辑容易变动的程式码必须剥离成另一个系统，容易变动者（例如应用系统）可以依赖较不容易变动者（例如平台系统）。提前做好这个剥离的动作，后续在业务功能变化时，好处就很明显了：需要要修改和测试的部分就会最小化，範围可控。

架构原则4：任何系统都不能依赖容易变动的系统。这一条原则和上一条原则是有关联的。容易变动的系统可能API的规格不稳定，且内部功能的稳定性也比较低，依赖这样的系统就会导致你的系统也很容易受到影响。

架构原则5：被调用方必须提供清晰、文件化的API。当我做系统设计评审时，我非常关心API设计的良窳。好的API可以让使用者一目了然，且有说明清楚的文件。关于API的设计，我的经验是「核心系统」的API要做到弹性至上，API的数量少，但每个API的参数个数比较多，这么设计的好处是可以避免核心系统经常需要修改。比较靠近应用的系统要做到使用的方便性至上，API的数量多，但每个API的参数个数比较少（且尽量让参数有预设值，可以空缺不设定）。

架构原则6：使用者界面要被剥离出来，且使用者界面内尽量不要有逻辑。使用者界面内可以有布局（layout）和操作等和业务无关的程式逻辑，但只要和业务有关的逻辑，一定要剥离出来。这么做的好处是，可以在不同的终端设备之间共用业务逻辑。

这篇文章先介绍六条架构原则，下一篇再介绍剩下的六条架构原则。