业务与边界
价值 · 角色 · 流程- 业务动机与目标
- 核心角色与场景
- 范围内外与上下游
一套标准，
把业务意图贯穿
前端、服务与数据
每个业务模块都用同一组视图回答：为什么存在、如何运行、由什么实现、凭什么可信。
- 统一视角
- 降低跨角色沟通成本
- 端到端架构
- 打通业务与技术实现
- 可追溯证据
- 每项判断都能回到事实
- 模块化复用
- 支持同结构持续扩展
INTENT业务意图
体验与前端
渠道 · 页面 · 交互- 用户与渠道
- 页面结构与导航
- 组件与客户端状态
服务与后端
API · 服务 · 集成- 服务职责与编排
- 契约、幂等与错误
- 内外部系统协作
数据与状态
模型 · 状态 · 一致性- 实体关系与所有权
- 生命周期与状态机
- 引用、快照与一致性
控制与运行
规则 · 安全 · 质量 · 演进- 权限、规则与审计
- 质量目标与可观测性
- 差距、决策与路线图
EVIDENCE可信证据
01
先区分层级，再复用模板
业务域总览与业务模块详解不是同一张页面。总览负责组织能力，模块页负责证明一个能力如何完整运行。
业务域总览
回答“这个业务域由哪些稳定能力构成，它们如何共同完成客户价值”。
- 观察尺度
- 领域 / 限界上下文
- 核心图形
- 能力地图、价值流、Context Map
- 主要读者
- 业务负责人、产品与架构师
- 不应该出现
- 逐接口实现细节与页面组件清单
选择一个完整业务能力向下钻取
业务模块详解
回答“这个独立业务能力如何跨角色、页面、服务、数据和运行形成闭环”。
- 观察尺度
- 一个可独立交付的业务能力
- 核心图形
- 高保真界面、泳道、状态机、服务图、ER 图
- 主要读者
- 产品、前端、后端、数据、测试与运维
- 不应该出现
- 把内部小功能再次拆成目录模块
划分原则只有同时具备独立业务目标、清晰边界、完整生命周期和可独立演进能力，才是目录级业务模块；页面 Tab、表单分组和内部数据对象不是模块。
02
十项视图，不多不少地讲清一个业务模块
顺序固定，内容随业务事实变化。每项视图都必须同时交付图形、说明和证据，禁止只有漂亮图而没有真实依据。
架构平面#视图名称一句话目的必备图形必备说明必备证据
模块契约
明确模块价值定位、核心职责、边界范围和当前成熟度。
- 价值图
- 边界图
业务语境
厘清参与者、典型用例、上下游关系及触发到结果。
- 参与者图
- Context Map
渠道体验
呈现移动端、PC 端和管理端的真实界面与功能差异。
- 高保真界面
- 功能矩阵
流程状态
让主流程、跨角色交接、状态迁移和异常回退都可追踪。
- 流程图
- 泳道图
- 状态机
前端架构
说明页面结构、路由、组件职责、客户端状态和端侧约束。
- 页面结构图
- 路由与状态图
服务架构
定义 API、BFF、领域服务职责，以及集成、幂等和错误契约。
- 服务构成图
- API 契约图
数据架构
梳理实体关系、事实所有权、读写路径、引用与快照语义。
- ER 图
- 数据流图
规则治理
定义权限、校验、不变量、安全、隐私、审计与最终裁决点。
- 规则决策树
- 权限矩阵
质量运行
给出性能、可用性、容量、可观测性、恢复和降级要求。
- SLO 图
- 观测与恢复图
证据演进
区分当前态与目标态，登记差距、决策、证据和演进路线。
- 证据地图
- 演进路线图
03
不是十段文字，而是十组可复核制品
每张图都必须带结论、图例与事实来源；每段说明必须能指向代码、数据、测试或明确登记的目标态。
业务制品
- 价值与边界图
- 参与者与用例图
- 上下游 Context Map
- 能力范围说明
体验制品
- 多端高保真界面
- 端侧功能矩阵
- 关键交互流程
- 前端组件与状态图
服务制品
- 跨角色泳道
- 服务职责图
- API / 错误契约
- 幂等与集成语义
数据制品
- 领域对象与 ER 图
- 状态机与生命周期
- CRUD 数据流
- 引用 / 快照 / 一致性
控制制品
- 规则与权限矩阵
- SLO 与观测架构
- 异常恢复路径
- 证据、差距与路线图
谁和谁协作、什么先后发生、状态如何变化、事实归谁所有。
为什么这样设计、边界为何成立、哪些选择是明确决策。
精确到页面、接口、服务、表、测试或已批准的目标态记录。
禁止用设计稿、字段或“计划支持”伪装成已经落地的能力。
04
标准不是目录，而是一条可验证的证据链
只有业务意图、跨端体验、服务契约、数据事实和运行证据能够互相追溯，模块才算真正完成。
业务意图
解决什么问题
创造什么价值
跨端体验
多端一致体验
关键场景可用
服务契约
API 与服务定义
边界与依赖清晰
数据事实
数据来源、流转
与质量可验证
运行证据
上线、监控、告警
与实际运行记录
四道交付门槛
- A边界完整
能说清范围内、范围外、用户边界、系统边界和上下游关系。
- B链路闭合
主流程、异常、回退、状态迁移及用户反馈全部可追踪。
- C实现可证
前端、API、服务、数据和测试均有真实、可定位的实现证据。
- D演进可控
当前态、目标态、已知差距、架构决策与变更历史分离记录。
05
架构描述与变更历史，必须分开治理
稳定知识解释“为什么这样设计”；高频记录说明“何时改了什么”。二者相关，但不能在同一正文中混成时间流水账。
架构描述
稳定 · 面向当前与未来维护模块契约、业务语境、跨端体验、流程状态、前后端实现、数据模型、规则、质量与演进判断。
- 何时更新
- 业务边界、流程、模型、规则、契约或质量目标发生实质变化
- 不记录
- 普通缺陷修复、无架构影响的样式与文案调整
独立制品相互引用
变更历史
高频 · 面向审计与追溯记录每次版本变更的动因、内容、影响、验证证据和是否触发架构复核。
- 何时更新
- 每次可交付变更、缺陷修复、依赖调整和风险处置
- 回写架构
- 仅当变更影响标准十项视图中的任何一项
开始下一个模块前
复制标准骨架，逐项填充真实事实；无法提供证据的内容明确标为目标态或缺口。