架构师的十八般武艺：架构治理

本文是十八般武艺的最后一篇，可能也是最虚的一篇。架构治理是永恒的话题，也是永远没有正确答案的话题。所有的公司都希望自己的软件架构能在治理中日久弥新，但是几乎也没有公司能做到这一点。往往就在两个极端之间徘徊：强管控架构不灵活；高度灵活架构失去管控。

怎么做好架构治理，我们从目标、组织保障、实施原则和落地技巧四个方面进行阐述。

首先，我们需要明确架构治理的目标是啥。架构治理的目标是为了响应的系统、应用的架构不至于腐化，能在非功能性上满足容量、稳定性和可运维、可延展的诉求。架构治理落实到实施上，就是系统重构。

其次，要能做好架构治理，必须在组织层面有一定的保障。咨询行业是没有架构治理的，咨询业是项目机制，一个项目完成后相应的资源就释放了，在组织层面就不可能有架构治理的资源规划。所以，在做架构治理之前，需要在管理层面对架构治理的重要性达成认识，同时在日常预留一部分常规资源（10%～20%）投入架构治理专项工作。

第三，架构治理不是脑爆式的系统重构，架构治理也有事前、事中、事后三个阶段及相应的原则。

首先，最好的架构治理是架构管控，不让坏的架构设计进入到系统中。这个分成两个落地手段。第一，我们的架构需要有很好的架构设计，将架构的分层说清楚，将大面上的逻辑结构先预设好。这样的系统，在容量、稳定性和可延展性等方面基本上是不会出大的纰漏的。其次，要建立严格和可落的架构/代码评审机制，对于新设计开发的功能，要符合总体的架构设计原则和代码质量标准。评审一定不要落于形式，不要做评审机器人，该不过就不过，项目压力和架构质量是两个事情分开说。

第四，架构治理和系统重构不是万能的。我们永远预测不到业务需求的发展和 IT 技术的发展。如果一个系统对于业务的支撑差距较大，或者整体的技术框架已经落后于业界的平均水平了，要果断的放弃它。最好的架构治理和重构就是新建应用并切流。新衣服总要比打补丁看起来舒服。这个里面就是一个 ROI 的问题，是重构还是新建对业务的支撑效率高。

最后，在实施层面，提供几点架构管控和治理的小技巧。

1. 重点抓住模型：模型是现实世界的反应，如果模型对了，代码基本上不会有大的纰漏。

2. 严格管控分层：业务服务、领域服务、领域模型、集成等层次要分清楚。如果层次清楚，杜绝跨层次或者反层次的依赖关系，代码的结构大体不会太乱。

3. 集成契约高风险：对外提供的服务和对外依赖的服务，需要在契约层面讲字段、SLA、幂等、错误码等说清楚，并落实到契约中。这部分要反复 review 和不断回归，这里是风险的高发区。

4. 重视测试：如果测试写不好，或者测试覆盖不全面，一个系统的质量是不会高的。

5. 坚持长期主义：架构治理是一个没有终点的游戏，从系统上线到系统下线的全生命周期。所以放弃一蹴而就的思想，将架机构管控和治理落实到日常的工作中去。