C4 Model 架构建模、视图边界与评审手册
C4 Model 是一套架构表达方法，不是特定绘图产品。它用软件系统、容器、组件和代码四个缩放层级帮助读者逐步进入细节。团队常见误区是把四级理解为四张必画清单，结果每张图各自维护名称与关系，最终产生冲突。正确做法是先建立统一边界和词汇，再按受众选择必要视图。
从人和软件系统开始
系统上下文视图回答谁使用系统、系统承担什么责任、依赖哪些外部系统。这里不应出现 Pod、类或数据库表。容器视图再表达可部署或可运行单元，例如 Web 应用、API 服务、数据库和消息代理；“容器”是 C4 概念，不等同于 Docker 容器。
组件视图只在它能帮助开发或风险评审时展开某个容器。代码视图通常由 IDE、代码和自动生成关系承担，不必为了形式完整手工维护。架构师的价值在于控制抽象层级，而不是把所有技术名词塞进一张图。
建立最小模型合同
模型对象需要稳定名称、职责、技术、owner 和边界，关系需要方向、意图和必要的协议。箭头只写“调用”信息量太低，应表达为什么交互。下面的文本是概念样例，具体语法由所选工具决定。
Person Customer "发起结算并查询结果"
System Checkout "协调订单结算"
System_Ext Payment "完成支付授权"
Rel(Customer, Checkout, "提交结算请求", "HTTPS")
Rel(Checkout, Payment, "请求支付授权", "HTTPS/JSON")配置影响主要来自视图范围、元素过滤、布局和样式。样式只帮助辨认类型或状态，不能代替标签。颜色如果表达风险或所有权，必须有图例，并考虑灰度打印和色觉差异。
正向验证模型是否帮助判断
正向实验选择一个实际变更，让开发、运维和安全分别阅读对应视图。开发者应能找到受影响容器，运维应能看见运行依赖，安全应能识别信任边界和数据流。验证输出是问题是否被更快回答，而不是图是否“好看”。
项目接入时把模型源、视图输出、ADR 和代码入口放在相邻路径。PR 修改跨系统关系时同步更新模型或明确说明无需更新。CI 可以检查模型语法和链接，但事实正确仍需要 owner 评审。
反向证据揭示抽象混乱
反例可以故意在上下文图中加入类名，或让同一服务在两张图使用不同名称，再让读者解释边界。若解释依赖作者口头补充，模型合同就不充分。另一个失败模式是删除数据库关系但代码仍使用它；这说明语法门禁无法替代运行和代码证据。
排障先分清模型错误、视图过滤错误和布局错误。对象不存在或关系方向错误属于模型；元素未显示可能是视图范围；重叠和断线才是布局。不要通过复制一个新元素修复显示问题，否则会制造同名双事实。
权限、安全与容量视角
C4 图可能公开内部系统名、网络边界、数据流和第三方依赖。公开视图应从同一模型生成脱敏投影，而不是复制后长期分叉。模型源进入受控仓库，发布端只读取允许的视图；示例不包含真实 Token、主机名和客户数据。
大模型的容量问题不是元素数量本身，而是一个 workspace 试图服务所有受众。按业务域建立模型边界，通过稳定标识符或链接表达跨域关系。团队 owner 负责词汇表和跨域接口，各域 owner 维护本域事实，平台 owner 维护渲染与验证机制。
清理、回滚与工具退出
元素退出系统时不要立即从历史中抹除。先在当前视图标记迁移或废弃，关联 ADR 和替代关系，确认代码与运行资产已清理，再从活跃模型移除。错误变更可以通过 Git 回滚，但业务事实变化不能靠恢复旧图解决。
C4 Model 不绑定工具，因此迁移应优先保留对象、关系、视图范围和说明语义。导出图片只能作为阅读副本；恢复目标是目标工具能重新建立模型并生成关键视图。治理成熟度最终体现在模型是否持续贴近系统，而不是采用了哪款绘图软件。