架构验证的原型法与框架法

不值得验证的架构，就不值得设计——架构设计包含了如何构建软件的最重要决策，这些决策能否让最终系统满足预期的运行期质量属性（性能、可伸缩性、持续可用性、鲁棒性、安全性）和开发期质量属性（可扩展性、可重用性、可理解性），在大规模开发展开之前始终是悬而未决的重大风险。因此在以架构为中心展开大规模开发之前，应该先把软件架构设计方案尽快实现为一个小的原型，通过测试和评审来评估架构是否合理——具体有原型法和框架法两种方法，适用场景不同。原型法适用于项目型开发：准确地说这是[[垂直演进原型的增量交付与发布级质量要求]]的应用——为了真实验证架构表现，必须把选定的功能特性完整实现；这不是验证单个技术可行性的垂直抛弃原型，而是要验证一组架构设计决策对系统非功能需求的满足程度，所以这个垂直原型必须是演进型的，直接作为后续分头开发的基础（RUP提到的”可执行架构”其实就是这里所说的垂直演进原型）；实现架构原型时代码要达到产品级质量，因为它不是抛弃原型，而是下一步开发的基础。架构原型所实现的有限功能需求需要精心挑选——应该是能”触发”主要设计机制参与执行的、或有较高技术风险的、或最影响用户满意度的功能，一句话，这些功能要么是用户”最关心的”、要么是架构师”最担心的”，测试的重点是质量属性测试而非功能测试。框架法适用于产品型开发，有更多优点：把架构设计方案用框架的形式实现，在此基础上进行评估验证——引入框架之后，整个”应用空间”的分割多了一个维度，框架实现的是与具体应用无关的通用机制和通用组件，这更利于支持产品型开发生命周期长、应用版本多的特点；但由于框架本身不提供任何具体应用功能，把架构设计思想框架化之后，还应该在框架基础上再实现一个小的垂直原型，才能进行实际的非功能测试和开发期质量评价。