GeoXMind

先确定系统语境与边界

从外部参与者、依赖和责任划分确定系统边界，避免把组织图或部署图误当成完整架构。

先确定系统语境与边界

架构讨论常从组件图开始，但图中的框如果没有说明系统对外承担什么责任，后续的接口、部署和质量分析都缺少共同对象。系统语境回答的是“这个系统处在什么环境中”，边界回答的是“哪些责任由它承担”。两者不是一次画图工作，而是决定需求归属、风险范围和团队协作方式的基础。

系统外部仍然影响系统设计

用户、其他系统、设备、数据供应方、运营人员和监管约束都属于语境的一部分。它们向系统提供输入、接收输出，或限制系统能够采取的行动。外部并不等于可以忽略：第三方身份服务不可用会影响登录，地图数据许可会限制分发方式，浏览器安全策略会约束前端加载资源。

ISO/IEC/IEEE 42010:2022 的公开目录把架构描述置于利益相关方和关注点的框架中。引用该标准时应以公开目录确认版本，不复述未取得的标准条文。对项目实践而言，先列出利益相关方和外部关系，可以检验架构视图是否覆盖了真正的关注点。

边界按责任划分而不是按机器划分

一个数据库位于本机，并不必然属于系统责任；一项云服务位于外部，也可能被系统承诺为整体能力的一部分。判断边界时要问：谁决定其版本，谁监测其运行，谁处理失败，谁对数据和结果负责。部署位置只能提供线索，不能代替责任判断。

边界还存在层次。产品边界说明向用户交付什么，软件边界说明哪些组件由团队维护，安全边界说明信任在哪些位置改变，事务边界说明一次状态变更覆盖哪些资源。这些边界可以不同，但必须彼此可解释。

用上下文关系暴露假设

上下文描述至少应标明外部实体、交互方向、交换的信息以及关键协议。对每条关系，可以继续核对身份依据、数据所有者、时效要求、失败行为和容量假设。仅写“调用外部接口”无法支持分析，因为同步或异步、可重试或不可重试、权威数据或缓存副本会导致完全不同的结构选择。

例如，一个地理平台从外部服务取得底图。若底图只是辅助显示，服务失败时允许隐藏图层；若业务判断依赖该底图的版本和覆盖范围，就需要固定来源、记录版本并设计替代路径。同一条网络连接因为责任不同，会产生不同的可用性要求。

边界变化意味着架构变化

把自建能力改为供应商服务，或者把人工审核变成自动决策，不只是实现替换。数据流向、失败模式、合规义务和操作权限都会改变。边界变化应产生架构决策记录，并重新检查质量属性场景。

系统语境也会随业务扩大。原本只服务内部用户的系统对公众开放后，身份、滥用防护、容量和可访问性都成为新的关注点。架构文档应记录当前边界和已知变化方向，不把早期假设永久化。

一个可核对的边界说明

边界说明无需复杂，但应能回答：系统提供哪些能力，依赖哪些外部实体，交换什么信息，哪些失败由系统吸收，哪些责任明确转交给使用者或供应方。CMU SEI 将软件架构视为有关整体结构和行为的重要设计决定；只有先确定决策对象，结构分析才有落点。

资料依据