架构视图和模型选择：一张图无法同时表达所有问题
"应用→Redis→数据库"的一张图，让人误以为所有写都经 Redis 裁决——若实际数据库写主、Redis 查询投影，图与不变量已经矛盾。本页定义视图与模型的匹配方法，用同一积分系统的四个视图演示一致性审查。
模型服务于一个可检查的问题
质量属性场景描述刺激、环境、受影响模块、响应与度量值；数据流图显示数据来源、控制和信任边界；序列图描述时序和失败位置；状态机说明何时能推进或补偿。模型应服务于一个可检查的问题。若要验证容量，需要工作负载和队列模型；若要判断一致性，需要操作历史和副本模型；若要判断安全，需要主体、资产、信任边界和滥用路径。过度抽象会隐藏平台假设；过度细节会把视图变成实现清单。专家需保持模型可追溯到需求和代码，同时允许在需求变化时更新。
上下文视图表达参与者与外部依赖；数据视图表达所有权、版本与约束；运行视图表达调用、队列和资源；部署视图表达故障域与容量；迁移视图表达阶段与主权。它们描述同一系统的不同投影，箭头必须说明同步调用、事件、数据复制还是控制信号——调用、复制、事件和控制信号有不同延迟、确认与失败协议，混用会错误推导保证。
选模型而非堆术语
状态机适合审核轮次与订单生命周期；队列模型适合积压和等待；日志/水位模型适合CDC；故障树适合相关失效。用一个M/M/1公式描述突发、多优先级、强相关服务时间会越过假设，必须说明分布和稳态条件。教学画两种视图：订单写入事务域是账户/业务单/流水；通知运行链是Outbox→broker→渠道。把二者连起来能看清本地提交不覆盖外部发送。若画成一个大"事务"框则掩盖了UNKNOWN。
同一积分系统的四个一致视图
上下文视图先列用户、运营、积分服务、订单源和外部通知渠道，明确谁产生业务意图，谁只读取。数据视图再列account、operation、ledger、outbox及唯一键，框住一个数据库事务能约束的内容；余额与流水不变量不能只靠一个"积分服务"框表达。
运行视图画客户端提交、事务提交、响应丢失、同键查询、relay投递、重复消费和最终通知，把UNKNOWN放在响应丢失的位置。部署视图另标写主、同步/异步副本、可用区、共享认证/配置/网络，不把三副本图直接翻译为三个独立故障域。迁移或恢复流程用状态机补充"谁当前有权承诺写成功"，而非在正常调用图上堆更多箭头。
现在追问三件事：1）响应丢失后是否重复扣？从数据唯一约束和运行重试时序共同回答；2）失一区后是否丢确认写？从提交配置和部署故障域回答；3）恢复旧备份后能否立刻写？从恢复状态机和幂等账本保留回答。每个问题都需要不同视图协作，任何一张孤立图都不足以证明全部结论。
审查一致性时对照稳定身份、箭头语义、确认点和边界：部署图若宣称跨区写主，数据图却只给单库唯一键，就存在未解释的原子域；运行图若把通知包含在数据库commit内，也与真实资源边界冲突。优秀图不是框多，而是让这些矛盾可被发现。
可执行审阅
给另一个人三种问题：旧批准会不会发布新内容、失一区后能否承峰值、回填是否覆盖新数据。要求他从相应图中定位版本守卫、部署余量和水位；找不到就补该视图，不用画更多无信息框。方案A维护一张巨图，修改成本小但语义混杂；方案B维护少数按问题分离的视图，有一致性维护成本，却能独立审查。为每个节点和关键边保存稳定名称，更新数据主权时同时检查运行与恢复视图，避免文档互相矛盾。
视图一致性检查表：同一事实必须在五视图里能互相解释
本页用积分系统演示了四个视图，评审时还需要一张逐项检查表：同一关键事实在上下文、数据、运行、部署、迁移五个视图中是否一致。不一致不是"图画得不好"，而是某个视图缺少对原子域或故障域的交代。
检查表三问：（1）谁有权写？（2）写入在哪个原子域完成？（3）故障时谁恢复？每个视图都要能回答它负责的那一问，且答案互相兼容。反例：运行视图宣称"跨区写主、双活"，数据视图却只有单库唯一约束，部署视图只有 A 区一个主——三张图合起来是一个未解释的原子域。这不是措辞问题：如果按运行图实现，唯一键跨区无法原子裁决，重复扣款就是必然结果。
检查顺序：先从数据视图定原子域（唯一键、事务边界、水位），再看运行视图的调用是否跨越原子域，最后看部署视图的故障域是否与原子域对齐。迁移视图只在变更期加入。发现冲突时，修改的应是方案或数据视图，而不是把运行图的箭头改细。
执行 python3 labs/architecture_models.py view_consistency：模型给出五视图示例，预期输出两条冲突——运行视图宣称跨区写而数据视图只有单库约束、部署视图只有单区主而运行视图宣称跨区写。脚本只做文本规则检查，不解析真实架构图。
两个合理选择：A 维护一张大图覆盖所有视图，修改省事但语义混杂；B 按问题维护少数视图并保持一致性检查，维护成本高但可独立审查。本例选 B，并把"未解释的原子域"列为评审阻断项，与安全越权同级。
架构师变化条件
把积分写主从单库升级为跨区：部署视图变了，数据视图的唯一键与提交配置必须同步重画，否则出现"部署图宣称跨区写主、数据图只有单库约束"的未解释原子域。新增对账后台：上下文视图补参与者，运行视图补对账任务的水位读取。每次变化跑一遍三问审阅（旧批准/失一区/回填），检查哪个视图需要更新。
闭卷验收
本页 8 道闭卷题收进了下方自测面板：先回忆，再展开参考答案与评分点，最后给三档自评。