设计会开完，架构图才开始画。画的人凭记忆把白板上的方框搬进工具里，连线随手一拉，箭头方向靠感觉。几周后有人问"这个服务为什么直连那个数据库"，没人答得上来。
问题不在画图工具，在顺序。需求文档里散落着集成方式、信任边界、非功能约束，而最终那张图只剩下整齐的方框，背后几乎没有证据支撑。
把顺序倒过来，情况会不一样：先从需求里抽出组件和关系，把事实和设计假设分开，评审模型，再导出成可编辑的架构图文件。图不是画出来的，是"长"出来的。
需求里到底藏着哪七类东西
不是每个名词都该变成一个组件。需求文档里真正与架构相关的证据，通常落在七类里：
- 参与者：用户、管理员、运维人员、外部机构。
- 能力：系统必须提供的服务或功能。
- 数据：记录、文件、事件，以及归属约束。
- 集成：接口、消息队列、回调、文件传输、身份提供方。
- 部署约束：云、区域、网络分区、本地依赖。
- 质量属性：可用性、延迟、吞吐、隐私、恢复能力。
- 控制措施：认证、授权、加密、审计、留存策略。
判断标准很简单：一个组件需要有明确的责任或运行时角色。"客户满意度"是目标，不是可部署的服务，它不该出现在部署视图里。
先想清楚这张图给谁看
一张图回答不了所有架构问题。生成之前先说明读者是谁、要回答什么问题。给管理层看的上下文视图，和给工程师看的部署视图，需要的细节层级完全不同。混在一起画，结果是两边都看不懂。
确定视图之后，才轮到抽取。抽取的第一步是划定范围：哪些文档是已批准的，哪些还是草稿，哪些章节具有权威性。同时记录产品版本或发布批次。互相冲突的文档不能被悄悄揉在一起——那样产出的模型看着完整，实际是矛盾的缝合体。
每个方框都要能指回一句需求
把需求交给工具，要求它给出组件、接口、数据存储、参与者、约束，以及尚未解决的设计决策。关键在于：每一个被提出的元素，都应该能引用到它的来源需求。
从这些需求出发，构建一个逻辑服务架构。抽取参与者、系统职责、外部依赖、数据存储、接口、安全控制和非功能约束。对每个组件和每条连接，标注支撑它的需求条目。把明确写出的需求和设计假设分开，把冲突项、缺失的协议信息、缺失的归属信息、缺失的信任边界信息都标出来。
模型先评审，再画图，最后导出。顺序不能反。
连线比方框更值得审
大多数人评审架构图时盯着方框看，其实线才是问题所在。对每一条连接，都该问清楚：
- 这条连接上传递的是什么信息或命令？
- 方向是哪边？
- 走的是什么协议或机制？
- 是同步还是异步？
- 适用什么身份和授权？
- 它是否跨越了信任、区域或归属边界？
一条没有标注的线，往往是一个没解决的接口，只是被视觉上的简洁掩盖了。图越干净，越要警惕。
假设要单独记账
需求很少把整个设计写全。数据库选型、消息中间件的取舍、重试策略，这些通常不在需求里。做法是给假设单开一份登记表，而不是把它们混进需求模型里冒充事实。
这样做的价值在评审时体现得最明显：哪些是需求明确要求的，哪些是团队自己补的，一眼可分。当需求变更时，也能快速定位哪些设计决策需要重新讨论。
架构图的价值不在于好看，而在于它能被追问。每个方框有出处，每条线有交代，每个假设有记录——这样的图才经得起半年后的一次回看。
热门跟贴