Day28-26｜7.2.3 基于体系结构的开发模型：让架构成为开发、测试和演进的主线

本文对应《系统架构设计师教程（第2版）》第7章“系统架构设计基础知识”7.2.3“基于体系结构的开发模型”。基于体系结构的软件开发方法（Architecture-Based Software Development）把软件架构作为需求分析、设计、实现、测试、部署和演化的核心组织依据。它不是先画架构、再让开发人员自由实现，而是用架构驱动功能分解、质量验证、组件实现、团队协作和风险控制，使系统在持续迭代中保持整体一致。

一、学习目标与考试定位

完成本节后，应能够说明基于体系结构开发模型的基本思想、主要阶段和循环关系；理解架构需求、架构设计、架构文档、架构复审、架构实现和架构演化之间的关系；能够解释架构基线、架构跑道、组件实现、质量场景和风险驱动迭代；能够分析“架构与代码脱节”“功能完成但质量不达标”“架构评审只做一次”等问题；能够在案例题和论文中描述如何用架构组织软件开发。

软考高级题目经常要求指出架构开发模型各阶段的任务或排序，也可能给出项目逐步开发的情境，让考生说明为什么先做架构验证、如何建立基线、如何把架构约束落实到实现和测试。回答要体现迭代、反馈、风险和质量，而不是把模型写成机械的瀑布流程。

二、基本思想：架构是开发的骨架

普通开发可以从功能列表开始逐个实现，但大型系统若没有稳定的整体结构，局部功能会产生重复、冲突和不可控依赖。基于体系结构的开发先确定系统主要结构、边界、接口、数据和质量机制，再把功能增量映射到架构元素中。

架构既是设计结果，也是开发约束。组件应按架构职责实现，接口应遵循契约，数据应由明确的所有者管理，质量属性应有验证路径，部署和运维能力应随增量建设。架构不是限制创新，而是让创新发生在可控边界内。

这种模型强调“架构先行但不一次性冻结”。高风险和跨系统的决策先验证并建立基线，低风险细节可以在迭代中逐步细化；实现和运行反馈可以促使架构调整，调整必须经过影响分析、记录和验证。

三、开发模型的主要活动

这些活动不是只执行一次。每轮迭代都可能重新确认架构需求、细化设计、实现增量、验证质量并更新风险。架构基线在关键节点建立，但基线也可以通过受控变更演进。

四、架构需求

架构需求来源于业务目标、用例、质量属性、外部约束、组织能力和风险。架构需求关注那些影响整体结构、跨模块协作或生命周期成本的要求。比如“支持移动端”可能只是一个接入渠道需求，“支持多租户隔离和按租户扩展”则直接影响数据、权限、路由和部署。

质量属性要写成场景。性能场景包含负载、请求、环境、响应和指标；可用性场景包含故障、检测、切换、数据和恢复；安全场景包含主体、资产、威胁、控制和审计；可维护性场景包含变化、影响范围、部署和验证时间。

架构需求还要记录优先级、来源、假设、验收方法和冲突。例如强一致、低延迟、跨地域和高可用可能相互约束，要在需求阶段明确业务优先级和可接受取舍。架构需求与功能需求、测试、接口和决策建立追踪。

五、架构设计和架构基线

架构设计把架构需求转换为系统上下文、元素、连接件、数据、部署和质量机制。先定义边界和职责，再确定通信和数据所有权，最后选择具体技术和参数。对高风险部分采用原型、模型和实验。

架构基线是经评审和批准、可作为开发与测试依据的架构版本。基线应包含视图、接口、关键决策、质量场景、约束、未解决风险和验证结论。建立基线后，团队不能随意绕过流程修改架构，否则不同组件会依据不同版本开发。

基线不是阻止迭代。需求变化、验证失败或运行反馈可能需要更新基线；变更应提交请求，分析对组件、数据、接口、测试、计划和运维的影响，授权后实施、验证并发布新版本。

六、架构文档化

架构文档要服务于沟通、实现、评审和维护。内容通常包括目标和范围、上下文、架构原则、驱动因素、质量场景、逻辑和开发视图、运行和物理视图、数据视图、安全视图、接口契约、部署要求、决策、风险、测试和演进。

文档要说明每个视图的目的、元素、关系、假设和版本。图表与代码、配置、接口和实际部署保持一致。对复杂接口使用契约和示例，对状态使用状态机，对故障使用时序和恢复流程，对容量使用模型和指标。

文档不应成为实现之后的补写。架构文档要随着决策和增量同步更新，重要架构规则可以通过静态检查、依赖检查、配置校验和自动化测试执行，减少只依靠人工阅读的风险。

七、架构复审

架构复审检查架构是否满足驱动因素和质量目标，是否可实施、可测试、可部署和可维护。复审参与者应包括业务、产品、架构、开发、测试、安全、数据、运维和必要的供应商。

复审重点包括：边界和职责是否清晰；接口和数据所有权是否明确；质量场景是否有机制和指标；关键技术是否经过验证；故障、恢复、扩容、迁移和安全是否考虑；团队和计划是否可执行；是否存在单点、共享表、循环依赖、过度复杂和供应商锁定。

复审要基于证据。性能评审看压测和容量模型，安全评审看威胁和测试，灾备评审看切换演练，数据评审看模型、对账和迁移。评审发现的问题要分级、分派、跟踪和复核，不以会议结束为完成。

八、架构实现

架构实现是用模块、组件、接口、数据、平台、构建和部署把设计变成可运行系统。先建立可运行的架构骨架，验证主要链路、部署、日志、监控和健康检查，再逐步填充业务功能，有助于尽早发现结构问题。

组件实现要遵循职责、接口和依赖规则。禁止为了赶进度跨层访问、直接写其他组件数据、绕过统一认证或把外部调用放进长事务。通过代码评审、架构规则、依赖分析、接口契约和持续集成保护架构边界。

架构实现不只是代码，还包括数据库模式、消息、配置、基础设施、流水线、监控、告警、备份和运维手册。缺少这些内容，架构无法真正交付。

九、架构验证和质量门禁

每个关键架构决策都应有验证方式。分层依赖可以用静态规则检查，接口可以用契约测试，性能可以用压测，可靠性可以用故障注入，安全可以用威胁建模和漏洞测试，恢复可以用备份与切换演练。

质量门禁按增量和风险设置。进入集成前完成接口和单元验证，进入系统测试前完成主要链路和配置，进入生产前完成性能、安全、迁移、监控、回滚和恢复。门禁不是为了拖延，而是防止已知的结构性风险进入更昂贵阶段。

十、架构演化

架构演化由需求、质量、技术、组织、法规和运行反馈驱动。演化包括增加能力、替换组件、拆分单体、迁移数据、扩展容量、修复技术债务和退役系统。

演化要先评估现状、目标、差距、依赖、风险和迁移路径。可以使用适配器、旁路、绞杀者、双读、双写、事件同步、灰度和分阶段切换。数据迁移要有校验、对账、回滚和历史处理，接口要有版本和兼容窗口。

架构债务应进入待办和路线图，按影响、紧急性和偿还成本排序。临时例外有期限和退出条件，不能永久绕过基线。

十一、敏捷迭代中的架构开发

在敏捷项目中，可以先建设架构跑道：提供必要的边界、接口、数据、部署、测试和可观测能力，使业务增量能安全地交付。技术探索通过 Spike 或时间盒进行，结果进入决策和待办。

每次迭代都应包含架构验证和技术债务处理，避免“先把功能做完再统一重构”。架构师要与产品和团队共同排序质量、风险、迁移和功能，不把架构工作当作迭代之外的隐形劳动。

十二、案例分析：架构基线与实现脱节

某保险系统架构评审通过后，基线规定客户服务只能通过数据服务访问客户主数据，理赔服务采用事件通知。为赶进度，开发人员直接查询客户库并同步调用理赔服务；测试只验证功能，不验证架构规则。上线后客户数据变更无法及时同步，理赔高峰造成级联超时，架构文档仍然显示“服务自治和事件驱动”。

问题分析

架构基线没有转化为开发规则、契约测试和质量门禁，文档与实现脱节；共享数据库破坏数据所有权，同步调用造成时间耦合；测试缺少一致性、峰值和故障场景；架构复审和变更控制没有覆盖实现偏差。

改进方案

将客户数据服务和事件契约落地为访问权限、依赖检查、代码规则和集成测试，禁止新代码直接写客户库；理赔流程明确同步查询与异步通知的边界、超时、幂等和补偿；对高峰和外部依赖故障进行压测和故障注入，补充追踪、监控、降级和回滚；对偏离基线的实现提交变更或整改，更新架构文档和决策，建立持续架构一致性检查。

十三、综合知识练习与详细答案

练习一

为什么架构基线建立后仍然需要架构演化？

参考答案：基线反映某一时点经过批准的架构，需求、流量、技术、法规和运行反馈会变化，验证也可能发现原假设不成立。演化不是随意修改，而是通过变更请求、影响分析、评审、实施、测试和新基线保持受控，从而在稳定性与适应性之间平衡。

练习二

架构文档写得很完整，但代码和部署与文档不一致，说明什么问题？

参考答案：架构没有落实到实现和治理，文档成为事后说明。应将架构原则转化为依赖规则、访问权限、接口契约、配置检查、流水线和质量门禁；通过代码、部署、数据和运行审计发现偏差，更新文档或提交受控变更，确保架构描述和实际系统一致。

练习三

基于体系结构开发模型为什么要先建立可运行骨架？

参考答案：骨架能尽早验证边界、主要通信、数据访问、部署、配置、日志、监控和健康检查，提前暴露技术和集成风险；如果等所有功能完成后才集成，错误结构会导致大规模返工。骨架不等于完成业务，而是提供可验证的架构最小闭环。

十四、论文写作素材

论文中可以这样描述基于架构的开发：我先识别架构需求、质量场景、约束和风险，形成架构驱动因素；根据驱动因素设计系统边界、职责、接口、数据、部署和质量机制，通过候选方案和权衡形成架构决策；建立包含视图、契约、原则、风险和验证结论的架构基线。

我先实现可运行的架构骨架，验证主要链路、构建、部署、配置、日志、监控和恢复，再按架构元素和组件逐步交付业务；通过代码规则、依赖检查、接口契约、自动化测试和质量门禁保护边界。性能、并发、安全、故障、迁移和灾备等高风险属性在早期使用原型、压测和演练验证。

需求、运行反馈和技术变化出现后，我进行影响分析，采用适配、灰度、双读、双写、事件同步和分阶段迁移控制演进；所有架构变更更新决策、基线、文档、测试、部署和风险。将技术债务、例外和架构规则纳入迭代计划，确保架构与实际代码和运行系统保持一致。

十五、今日复盘

基于体系结构的开发模型以架构为开发主线：先识别架构需求和驱动因素，再设计、文档化、复审、实现、验证和演化。架构基线提供共同依据，运行骨架尽早验证结构，质量门禁把决策落实到代码和部署，架构演化通过受控变更和渐进迁移完成。架构不是文档，而是能被实现、测试、运行和持续检查的约束与能力。

记忆主线：

架构需求驱动设计，基线统一团队，骨架验证结构，组件落实边界，测试验证质量，反馈推动演化。

下一篇进入 7.2.4 体系结构需求，进一步学习架构需求的来源、分类、质量属性和需求获取方法。