架构验证的完整步骤：测试运行期质量、评审开发期质量

架构原型对功能性需求的实现非常有限，那么架构验证到底在验证什么？答案是要验证架构对质量属性需求的支持程度，而这又要分两条腿走路。一是测试运行期质量：在”放手”实现功能需求之前，必须通过实际测试来验证架构对运行期质量属性的支持程度是否达标，因为这些质量属性不单纯和某个具体功能有关、而是由系统架构的大局规划决定的——比如一旦测试发现性能或可伸缩性达不到要求，就必须尽快调整架构设计，而不是等到功能开发完毕才发现问题、付出更大的返工代价。二是评审开发期质量：架构设计方案对开发和维护工作影响深远，所以必须尽早验证架构在开发期质量属性方面的表现，具体方法是让参与架构原型开发的人员进行评估——比如架构设计方案的可理解性如何、基于此架构开发出的应用（此时还只是原型）的可测试性、可重用性如何。这两条验证路径合在一起，构成了架构验证的完整步骤：首先把架构设计方案付诸实现，得到架构原型（可以是纯粹的垂直演进原型，也可以是基于架构框架的原型）；然后分头进行运行期质量的测试和开发期质量的评审，分别得到两组独立的结果；最后综合两组结果判定架构设计是否合乎要求——如果不合格，要决定下一步对架构的哪些方面进行重新设计。只有通过这套验证的架构设计方案，才可以作为大规模开发的基础，这时候投入大量资源才是合适的，因为重大的技术风险已经在架构验证阶段得到了解决和验证，而不是被带进了大规模开发之后才暴露出来。

结构图：

flowchart TD
    A["架构设计方案付诸实现\n（垂直演进原型 或 基于框架的原型）"] --> B["测试运行期质量\n性能/可伸缩性/持续可用性/鲁棒性/安全性"]
    A --> C["评审开发期质量\n可理解性/可测试性/可重用性"]
    B --> D{"架构是否合格？"}
    C --> D
    D -->|不合格| E["决定对架构哪些方面重新设计"]
    E --> A
    D -->|合格| F["作为大规模开发基础\n此时投入大量资源是合适的"]