利益相关方、关注点与架构视图

架构文档最常见的问题不是图画得少，而是没人说清这张图回答谁的问题。一张服务调用图可能帮助开发人员追踪依赖，却不能让运维人员判断故障域，也不能让数据负责人看出敏感信息怎样流动。架构描述要从需要作出决定的人和他们的关注点开始，再选择合适的表达。

ISO/IEC/IEEE 42010 的公开目录说明，该标准处理架构描述及其所涉及的实体，当前版本为 ISO/IEC/IEEE 42010:2022。标准正文受版权保护，本站不复刻其条款；这里沿用其公开术语范围，结合软件工程实践说明如何组织可用的架构描述。

谁会使用架构信息

利益相关方不只包括项目出资人和最终用户。开发人员、测试人员、运维团队、安全人员、数据治理人员、外部集成方、合规审查者以及后续接手系统的人，都可能因为某个决定受到影响。角色清单本身没有价值，重要的是他们需要判断什么。

产品负责人可能关心功能边界、交付节奏和成本；开发团队关心职责、依赖与修改影响；运维人员关心部署单元、容量、监控和恢复；安全人员关心信任边界、身份流转和数据暴露；数据库管理员关心所有权、一致性和迁移。一个人也可能同时代表多种角色，两个角色之间还可能有冲突目标。

“性能”“安全”“可维护性”仍然过于宽泛。关注点应贴近决策，例如“地图首屏在跨地域访问时能否达到响应目标”“单个租户的数据是否可能被其他租户读取”“修改一种内容类型会影响哪些服务和迁移”。可操作的关注点能够指导后续选择视图和证据。

视点说明怎样构造和使用一类视图：它服务哪些关注点，采用哪些模型和符号，允许出现哪些元素与关系，以及怎样检查一致性。视图则是依据某个视点，对当前系统形成的具体表达。把二者区分开，可以避免每次画图都临时发明符号，也便于不同版本之间比较。

逻辑或模块视图适合说明代码职责与依赖；运行时视图呈现进程、线程、消息和调用；部署视图连接软件单元与主机、容器、网络和区域；数据视图描述数据的所有权、存储、复制和生命周期；安全视图突出主体、资源、信任边界和控制。名称可以因团队而异，关键是明确它回答的问题。

同一元素在不同视图中可以有不同表现。例如一个“内容服务”在模块视图中是代码模块，在运行时可能有多个实例，在部署视图中分布于两个可用区，在数据视图中又与数据库和对象存储发生关系。不能把这些层次压进一张巨图后期待所有人都能读懂。

卡内基梅隆大学软件工程研究所的 Software Architecture 资料把架构与系统质量、分析和演进联系起来。视图不是为了文档完整，而是让关键结构能够被推理、沟通和检查。

多视图会带来一致性问题。模块视图声明服务没有状态，部署图却给每个实例挂载不可共享的本地数据；数据视图声称订单只有一个写入者，调用图却出现另一个直接更新数据库的组件。这些矛盾可能来自描述过时，也可能暴露真实设计问题。

可以建立少量明确的对应关系：服务对应哪些代码模块，运行实例部署在哪里，接口传递哪些数据，数据由谁拥有，外部依赖经过哪些网络边界。对应关系不必做成复杂建模平台，但应能从一个关键元素追到其他视图和实现证据。

版本管理同样重要。架构描述要标记所对应的系统版本或时间点，并记录尚未实现、准备废弃和仅适用于特定环境的部分。将目标架构和当前架构混在一起，会让读者无法判断哪些约束已经生效。

并非每个系统都需要固定数量的视图。一个内部批处理工具可能只需要模块、数据和部署说明；跨组织的平台还需要接口、身份、租户和运行治理。选择视图时可按以下顺序工作：

如果一个表格比图更清楚，就没有必要画图。接口契约适合用 OpenAPI 或消息模式，容量目标适合用场景和测试结果，依赖关系适合用矩阵或图。架构描述的质量取决于它是否减少决策歧义，而不是图形数量。

利益相关方、系统边界或关键约束变化时，应重新检查关注点与视图。新增外部合作方可能引入新的信任边界，部署到多个地区会改变数据和恢复问题，团队拆分也可能要求重新明确模块所有权。更新架构描述不是把旧图重新排版，而是确认原有问题和答案是否仍然成立。

ISO/IEC/IEEE 42010:2022，用于标准版本及架构描述术语范围的公开目录信息。
Software Architecture, Carnegie Mellon Software Engineering Institute，用于架构实践、分析和系统质量之间的关系。