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

在「技术架构设计12原则（上篇）」一文中，我提到我目前的架构原则有12条，且该文还介绍了其中的六条。这篇文章接续介绍剩下的六条。

架构原则7：调用外部厂商的系统时必须只依赖SPI（Service Provider Interface，服务提供者界面），不依赖具体的系统。我所谓的SPI，和API的差异不大，主要是主客的视角差异。简单来说，API是我们设计好介面标準，且我们实现这个标準，其他系统依赖这个标準；而SPI是我们设计好介面标準，且其他厂商的系统要实现这个标準，我们依赖这个标準。当我们的SPI和厂商的API之间有差异，无法衔接上，这时候要靠Adapter。

架构原则7的目的是，要做到我们的业务逻辑和厂商系统之间有隔离，避免外部系统的各种状况（例如外部系统介面变更），并且保留更换外部合作厂商或同时有多个同类型合作厂商的可能。如果我们的系统本身就是容易变动的系统，那么就不需要遵守这个原则，因为这么做的工作量变多，但好处并不明显。

架构原则8：业务逻辑的程式码必须区分服务（service）和物件（object），服务没有状态，物件有状态，服务操作物件，物件的状态记录在资料库（和外部系统）。但容易变动的简单系统，不需要区分服务和物件，因为这么做工作量变多，但好处不明显。在「架构的意义」一文中提到，根据使用方式，模型可以分为二种：资料模型、程式码模型。服务单纯是程式码模型，但物件主要是资料模型，搭配一部分与资料密切相关的程式码模型。

架构原则9：服务不能直接读写资料（和外部系统）。资料（和外部系统）一定要通过物件的包装与解释，才能被服务操作。严守分层不跨层，有助于架构的简化。

架构原则10：物件状态的保存方式必须做出隔离，也就是提供资料隔离层。物件不需要知道状态是保存到资料库或外部系统，所以这里和架构原则7描述的SPI使用同一个隔离层即可。

架构原则 11：充血模型才是好的物件模型。且设计模型时，要考虑是否有强一致性的要求。充血模型有许多业务逻辑，让介面可以直接被调用，可以减少许多服务多此一举的包装。

架构原则 12：禁止循环依赖。只要有循环依赖的存在，几乎就预示着病灶，不是不发作，只是时候未到。就如同我在「大规模系统重构」一文中描述的那样，破除循环依赖是重构的要点。

上一篇和这一篇文章一共描述了我的12条架构原则。这12条架构原则有个神奇的地方：我把他们一起用上，设计出我第一版的架构参考模型，也就是我在「架构能力的四个阶段」一文中所提到的第三个阶段。

事实上，这个过程是反着来的。几年前，我对于经典的三层（3-tier）和四层（4-tier）架构不满意，觉得太粗糙，我想要更细化的模型，于是我自己开始推演，从一大坨的系统开始推演，开始切割，我把每次切割的理由都想清楚，并记录下来，就成了这12条原则。我曾经在我当时任职的金融机构内部开始培训课程，把这个推演过程讲出来，大家听了觉得神奇。所以到底是这十二条架构原则衍生出我的架构模型，或者是我的架构模型抽取出这十二条架构原则，这已经说不清楚了。就像鸡生蛋，蛋生鸡。

而我的第一版架构模型又继续演化，从一维、后来变成二维，三维（请阅读「方法论设计的四个步骤」一文的描述），还演化出一个通用的编程框架（请阅读「技术应用的艰辛探索」一文的描述）。在探索这一切的过程中，我发现知识是如此的曼妙。架构对我来说，已经不再是一种IT技术，而是一种思考方式。