企业官网建设流程全解析

1. 项目概述：这不是画图，是构建可执行的系统逻辑骨架

“diagram-design”这个词组乍看像一个普通的设计动作，但在我过去十年带过的几十个跨领域项目里，它从来不是PPT里拖拽几个形状、加几条箭头就完事的装饰性工作。真正有价值的diagram-design，本质是一种结构化思维的具象化输出——它把模糊的需求、分散的模块、潜在的依赖关系，压缩进一张图里，让所有人——开发、测试、产品、甚至非技术决策者——能在30秒内对齐认知。我见过太多团队在需求评审会上反复争论“这个接口到底要不要校验token”，结果翻出三个月前的流程图才发现，当初设计时压根没定义鉴权环节的落点位置。这种低效，根源不在沟通，而在diagram-design从一开始就没承载起“可执行协议”的功能。

核心关键词“diagram-design”背后，实际指向三个不可分割的层次：语义层（图要表达什么）、语法层（用什么符号/规则画）、执行层（图如何驱动后续动作）。市面上大量工具只解决语法层——比如自动排版、主题切换、导出高清图；而真正吃力不讨好、却决定项目成败的，是语义层的严谨性和执行层的可落地性。举个最典型的例子：你画一个“用户登录流程图”，如果节点只写“输入账号”“验证密码”“跳转首页”，那它就是一张示意图；但如果你在“验证密码”节点旁标注“调用auth-service/v1/check-credentials，超时阈值800ms，失败返回HTTP 401+error_code=INVALID_CREDENTIALS”，这张图就具备了API契约的效力，前端可以据此写mock，后端可以据此写单元测试桩，测试同学能直接生成用例边界值。这才是diagram-design该有的分量。

它适合三类人深度参考：第一类是技术负责人或架构师，需要快速向新成员传递系统脉络，避免“靠口口相传理解架构”的高风险模式；第二类是资深开发，尤其在接手遗留系统时，一张准确反映真实调用链的sequence diagram，比读三天源码更高效；第三类是技术型产品经理，当ta能亲手用标准UML符号画出状态机图来定义订单生命周期，而不是写“用户下单后，状态会变来变去”，需求文档的歧义率能下降70%以上。这不是教你怎么用Visio，而是教你如何让一张图成为团队协作的“最小共识单元”。

2. 内容整体设计与思路拆解：为什么放弃“画得漂亮”，选择“画得精准”

2.1 拒绝视觉优先，拥抱语义驱动的设计哲学

很多初学者一上来就纠结“用PlantUML还是Mermaid？配色方案选深色还是浅色？箭头用实线还是虚线？”。这些细节当然重要，但它们属于“呈现优化”，而diagram-design的核心矛盾是“如何让图的内容本身具备可验证性”。我的做法是倒推：先明确这张图要回答哪三个关键问题，再反向选择最匹配的图类型和建模规范。

比如，要梳理微服务间的数据流向，我会强制自己问：

• Q1：数据从哪个服务产生？（源头服务）
• Q2：经过哪些中间处理节点？（转换、过滤、聚合逻辑）
• Q3：最终被哪些服务消费？（下游依赖）

这三个问题天然对应Data Flow Diagram（DFD）的核心要素。此时，花3小时研究SVG动画效果，不如花20分钟确认“支付服务产生的order_event消息，是否真的被库存服务和物流服务同时订阅”——这个事实核查，必须通过查代码里的Kafka topic配置、服务注册中心的消费者列表、甚至抓包验证，才能填进DFD里。图只是载体，背后的事实核查才是硬功夫。

提示：我给自己定了一条铁律——任何节点或连线，如果无法在5分钟内找到其对应的代码文件、配置项或日志片段作为依据，这张图就暂停绘制，先去补事实。

2.2 工具选型：文本即代码，版本即真相

十年前我用PowerPoint画架构图，改一个服务名要手动更新七八张幻灯片，最后交付物是一堆命名混乱的PNG文件，没人知道哪个是最新版。现在我的标准工作流是：所有diagram-design全部用纯文本描述语言编写，纳入Git仓库，与代码同分支管理。

为什么必须是文本？因为只有文本才能：

• 被diff工具识别：你能清晰看到“昨天这张图里，订单服务还调用着老版优惠券服务，今天已改为调用新版coupon-v2”；
• 被CI/CD流水线校验：我们曾配置过一条规则——当sequence diagram中出现“调用payment-gateway”的节点，但代码里找不到对应HTTP客户端实例化代码时，流水线直接失败并报错；
• 被自动化工具消费：用PlantUML写的类图，能一键生成TypeScript接口定义；用C4 Model文本描述的系统上下文图，能自动生成Confluence页面并嵌入实时服务健康状态。

目前我主力使用PlantUML（语法稳定、IDE插件成熟、社区模板丰富），辅以Mermaid（轻量级、GitHub原生支持好）。完全避开图形界面工具，不是为了标新立异，而是把“画图”这个动作，彻底还原为“写代码”——写错一个符号，编译（render）就报错；改一行描述，全图自动重绘。这种确定性，是鼠标拖拽永远给不了的。

2.3 图类型选择：不是越多越好，而是“一图一靶心”

网上教程常罗列十几种UML图，但实际项目中，我90%的diagram-design只用四类，且每类有明确的“靶心问题”：

你会发现，没有“类图”“活动图”“用例图”。不是它们没用，而是它们在多数工程场景中，信息密度太低或抽象度过高。比如类图，现代IDE的“Find Usages”功能比手动画图更能反映真实依赖；活动图则容易陷入“if-else”分支迷宫，不如直接写伪代码。选图的本质，是选择用哪种“思维透镜”去聚焦问题——贪多求全，反而稀释了diagram-design的杀伤力。

3. 核心细节解析与实操要点：从草稿到可执行图的七道工序

3.1 第一道工序：定义“图的宪法”——明确作用域与边界

很多人画图失败，第一步就错了：没想清楚“这张图到底为谁服务、解决什么具体问题”。我强制自己在动笔前，用三句话写下这张图的“宪法”：

1. 服务对象：这张图主要给谁看？（例：新入职的后端开发，用于理解订单履约链路）
2. 核心命题：它必须清晰回答哪一个问题？（例：“当用户点击‘确认收货’后，资金、库存、物流单据如何同步更新？”）
3. 有效边界：哪些内容坚决不画？（例：不涉及前端Vue组件结构、不展开Redis缓存淘汰策略、不包含数据库表字段详情）

这三句话不是形式主义。去年一个电商项目，我们曾为“支付回调处理流程”画过两版图：第一版面向运维，重点标注了Nginx超时配置、SLB健康检查路径、ACK重试机制；第二版面向开发，聚焦在Spring Boot中@RabbitListener消费消息后的事务边界、幂等校验逻辑、异常分支的补偿队列投递。两版图节点数相差无几，但连线语义、标注文字、甚至颜色编码都完全不同。没有“宪法”，就会画出一张谁都看不懂、谁都用不上的“四不像”。

注意：边界声明必须具体到技术名词。写“不涉及数据库细节”是模糊的，写“不展开MySQL 8.0的InnoDB行锁机制，但需标注SELECT ... FOR UPDATE语句所在方法”才是有效的边界。

3.2 第二道工序：符号即契约——严格遵循建模规范

UML、C4、SysML这些规范，不是学术摆设。它们存在的唯一价值，是让不同背景的人，看到同一个符号时，产生完全一致的语义联想。我见过最离谱的案例：某团队在架构图中，用红色虚线箭头表示“强依赖”，绿色实线表示“弱依赖”，结果半年后新人入职，按常规UML理解，虚线箭头本应代表“依赖关系”，而颜色并无标准定义——导致一次重大故障排查中，大家对着同一张图，对“强弱依赖”的解读完全相反。

因此，我的符号使用铁律是：

• 绝不自创符号：哪怕觉得“用闪电图标表示异步调用”很酷，也必须忍住。PlantUML里-->就是同步调用，->>就是异步消息，这是全球开发者默认的。
• 颜色仅作辅助，语义由形状和文字承载：红色只用于标注“阻塞点”“降级开关”“熔断器”，且必须在图例中明确定义；绝不单靠颜色区分服务类型（如“所有Java服务用蓝色”）。
• 文字标注必须可执行：节点名不能是“用户服务”，而要是“user-service:8080 (Spring Boot 3.1, JDK17)”；连线标注不能是“调用”，而要是“HTTP POST /v1/orders, timeout=2s, retry=2”。

实操中，我会用PlantUML的skinparam统一设置全局样式，确保整个项目所有图的字体、间距、箭头粗细完全一致。这种“机械式”的一致性，恰恰是建立团队信任的基础——当你看到第17张图里的虚线箭头，和第一张图里的虚线箭头行为完全一致时，大脑就不用再做额外翻译。

3.3 第三道工序：数据即证据——每个元素必须有出处

这是最容易被忽视、却最体现专业度的环节。一张diagram-design的价值，不在于它画得多精美，而在于你能否在5分钟内，指着图上任意一个节点，说出它的“身份证号”：

• 服务节点：对应Kubernetes中的Deployment名称、Docker镜像Tag、Git仓库Commit ID；
• 数据库节点：对应MySQL实例IP+Port、数据库名、主从角色（Master/Slave）；
• 消息队列节点：对应Kafka Topic名称、分区数、副本因子、ACL权限配置路径；
• 外部依赖：对应第三方API文档URL、SLA承诺的P99延迟、当前对接的版本号（如微信支付V3 API）。

我的做法是：在PlantUML代码中，为每个关键节点添加note right注释块，里面不是写“这是核心服务”，而是粘贴真实的kubectl get deploy user-service -o yaml输出片段（脱敏后），或curl -s https://api.xxx.com/v1/status | jq '.version'的返回值。这些注释在渲染图时默认隐藏，但打开源码就能看到。这相当于给每个图元素打了区块链式的“数字指纹”，杜绝了“这张图是半年前画的，现在早过期了”的尴尬。

去年一个金融项目，我们发现架构图中标注的“风控引擎服务”调用的是旧版规则引擎API，但实际生产环境已切到新版。问题就出在没人定期核对图中节点的“身份证号”。后来我们把这个核对动作固化为每周五的例行任务：用脚本自动提取图中所有服务节点名，批量调用curl http://$SERVICE_NAME:8080/actuator/info，比对返回的build.version是否与图中一致。不一致？立刻告警，责任人必须在2小时内更新图或回滚服务。

3.4 第四道工序：动态演进——图不是快照，而是时间序列

系统是活的，图也必须是活的。我见过太多团队把diagram-design当成“项目启动时画一次，之后束之高阁”的文物。正确的做法是：把图的每一次变更，都视为一次小型架构评审。

我的演进流程是：

1. 变更触发：当代码合并PR中包含@EventListener新增、RestTemplate新实例化、@KafkaListener新方法时，CI流水线自动触发图更新检查；
2. 差异比对：脚本自动比对当前PR修改的代码与现有PlantUML图，识别出“图中缺失的新调用关系”或“图中存在但代码已删除的旧依赖”；
3. 人工确认：开发者收到通知，必须在PR评论区中，用PlantUML语法写出新增/删除的图元素，并说明变更原因（例：“新增user-service → notification-service调用，因需在用户注册成功后发送欢迎短信，详见需求文档#RD-2023-087”）；
4. 自动合并：确认后，脚本将新代码块注入对应PlantUML文件，提交到同一PR。

这个过程看似繁琐，但它把“画图”从个人行为，升级为团队的架构契约签署仪式。每次合并，都是对系统现状的一次集体确认。我们不再问“架构图准不准”，而是问“最后一次架构评审是什么时候，谁签的字”。

4. 实操过程与核心环节实现：以“订单履约链路图”为例的完整复现

4.1 场景设定与目标锁定

假设我们要为一个B2C电商平台绘制“订单履约链路图”。这不是泛泛而谈的“下单-支付-发货”，而是聚焦一个具体、高频、易出错的场景：用户在APP端点击“确认收货”后，系统如何完成资金结算、库存释放、物流单关闭、积分发放四个动作，并保证最终一致性。

根据前文的“图的宪法”，我们明确：

• 服务对象：支付系统负责人、履约系统负责人、SRE值班工程师；
• 核心命题：当“确认收货”操作触发后，四个子系统如何协同，失败时如何补偿？
• 有效边界：不展开APP前端交互细节；不包含用户通知（短信/站内信）的具体实现；不涉及数据库SQL语句。

4.2 PlantUML代码逐行解析：从零开始构建可执行图

以下是我实际使用的PlantUML代码（已脱敏），我们将逐段解释其设计意图与实操技巧：

@startuml ' === 全局皮肤配置：确保所有图风格统一 === skinparam defaultFontSize 12 skinparam nodes { BackgroundColor<<Service>> White BorderColor<<Service>> #333333 FontColor<<Service>> #000000 } skinparam sequence { ArrowColor #2E8B57 ActorBorderColor #2E8B57 } ' === 参与者定义：严格对应真实服务实例 === actor "APP用户" as user participant "order-service:8080" as order <<Service>> participant "payment-service:8081" as payment <<Service>> participant "inventory-service:8082" as inventory <<Service>> participant "logistics-service:8083" as logistics <<Service>> participant "points-service:8084" as points <<Service>> ' === 核心交互流程：按真实调用顺序，标注关键参数 === user -> order: POST /v1/orders/{id}/confirm-receipt\n{userId:12345, orderId:"ORD-2023-XXXX"} activate order order -> payment: HTTP POST /v1/settlements\n{orderId:"ORD-2023-XXXX", amount:299.00}\nTimeout=3s, Retry=1 activate payment payment --> order: HTTP 200 OK\n{settlementId:"SET-2023-XXXX"} deactivate payment order -> inventory: HTTP POST /v1/inventory/release\n{skuId:"SKU-1001", quantity:1}\nTimeout=2s, Retry=2 activate inventory inventory --> order: HTTP 200 OK\n{releaseId:"REL-2023-XXXX"} deactivate inventory order -> logistics: HTTP POST /v1/logistics/close\n{waybillNo:"SF123456789"}\nTimeout=5s, NoRetry activate logistics logistics --> order: HTTP 200 OK\n{closeStatus:"SUCCESS"} deactivate logistics order -> points: HTTP POST /v1/points/award\n{userId:12345, points:100}\nTimeout=1s, Retry=3 activate points points --> order: HTTP 200 OK\n{awardId:"AWD-2023-XXXX"} deactivate points order --> user: HTTP 200 OK\n{message:"收货成功，奖励100积分已发放"} deactivate order ' === 关键补偿路径：用alt框显式标注失败分支 === alt payment settlement failed order -> order: Trigger Compensate\n{compensation:"rollback-settlement", refId:"SET-2023-XXXX"} activate order order -> payment: HTTP POST /v1/settlements/{id}/rollback\n{settlementId:"SET-2023-XXXX"} deactivate order end alt inventory release failed order -> order: Trigger Compensate\n{compensation:"restore-inventory", refId:"REL-2023-XXXX"} activate order order -> inventory: HTTP POST /v1/inventory/restore\n{skuId:"SKU-1001", quantity:1} deactivate order end ' === 图例说明：所有非常规符号必须在此定义 === note right of order <b>图例说明：</b> • Timeout=Ns：HTTP调用超时阈值（毫秒） • Retry=N：最大重试次数（不含首次调用） • alt框：表示条件分支，仅在对应错误发生时执行 • 所有服务端口基于K8s Service配置 end note @enduml

关键设计点解析：

• 服务命名直连生产环境：order-service:8080不是虚构名，而是K8s中Service的DNS名，运维可直接nslookup order-service验证；
• HTTP方法与路径精确到API网关路由：POST /v1/orders/{id}/confirm-receipt与Spring Boot@PostMapping("/v1/orders/{id}/confirm-receipt")完全一致；
• 超时与重试参数来自真实配置：Timeout=3s, Retry=1直接抄自FeignClient的@RequestLine注解或Ribbon配置；
• 补偿路径用alt框强制可视化：避免“理论上应该有补偿”的模糊表述，明确写出补偿API路径和参数；
• 图例是法律文书：所有非标准用法（如Trigger Compensate）必须在此定义，否则图无效。

4.3 渲染与交付：不止于一张图，而是一套协作资产

这张图的最终交付物，远不止一个PNG文件。在我的工作流中，它会自动生成三样东西：

1. 可交互的HTML页面：使用PlantUML Server渲染，支持点击节点跳转到对应服务的Swagger文档、Grafana监控大盘、Git仓库代码目录；
2. Confluence自动同步页面：通过Jenkins定时任务，每天凌晨扫描Git仓库，将最新PlantUML代码渲染为图片并更新至Confluence，页面底部自动显示“最后更新：2023-10-27 02:15:33，来源：git commit abc1234”；
3. Postman集合导出：脚本解析PlantUML中的HTTP请求，自动生成Postman Collection JSON，包含所有Header（Authorization: Bearer xxx）、Body示例、Pre-request Script（自动生成JWT Token）、Tests（验证HTTP 200 + 响应体包含settlementId字段）。

这意味着，当新同事第一天入职，他打开Confluence页面，看到的不仅是一张静态图，而是：

• 点击payment-service节点 → 跳转到该服务的Prometheus监控面板，查看最近1小时http_client_requests_seconds_count{uri="/v1/settlements"}指标；
• 点击POST /v1/settlements连线 → 下载预配置好的Postman请求，一键发起测试；
• 查看图例 → 明白Timeout=3s意味着什么，以及在哪里修改这个值（指向application.yml中feign.client.config.default.connectTimeout配置项）。

图，从此不再是文档，而是活的系统入口。

5. 常见问题与排查技巧实录：那些没人告诉你的坑

5.1 问题一：图越画越大，最后变成一张“信息黑洞”

现象：初始版本只有5个服务节点，两周后膨胀到32个，连线密密麻麻，打印出来A0纸都装不下，新人看一眼就放弃。

根本原因：混淆了“系统全景图”和“场景聚焦图”。试图用一张图回答所有问题，结果哪个问题都没答好。

我的排查与解决：

• 立即停画，做减法手术：打开图，用荧光笔标出所有与当前核心命题（如“确认收货”）无关的节点。去年我们删掉了7个“看起来相关但实际不参与本次流程”的服务，图瞬间清爽；
• 引入“视角切换”机制：在PlantUML中用show/hide指令，为同一份源码生成多张视图。例如：

  ' 主图：展示所有服务 show order, payment, inventory, logistics, points ' 简化图：仅展示核心服务，隐藏补偿服务 hide compensation-service, audit-service

  这样一份源码，可输出“全量视图”供架构师查阅，“简化视图”供开发快速上手；
• 物理隔离：为不同场景创建独立PlantUML文件，命名严格遵循[场景]_[图类型]_[版本].puml，如confirm-receipt_sequence_v1.2.puml。禁止在一个文件里堆砌所有场景。

实操心得：当图宽超过屏幕宽度的1.5倍时，就是重构信号。不要试图优化排版，要重构问题边界。

5.2 问题二：团队成员画的图，符号含义自相矛盾

现象：A同学用红色实线表示“强依赖”，B同学用红色虚线表示“异步消息”，C同学用红色箭头表示“需要重点监控”，三人对着同一张图讨论，结论南辕北辙。

根本原因：缺乏团队级的“图语法规则手册”，符号使用完全凭个人经验。

我的排查与解决：

• 制定《团队Diagram Design Style Guide》：一份5页PDF，明确规定：
  • 所有图类型适用范围（如“时序图仅用于描述跨服务HTTP/gRPC调用，严禁用于描述单服务内方法调用”）；
  • 颜色语义（红=阻塞点/熔断器，绿=健康/成功路径，黄=待观察/降级中）；
  • 线型语义（实线=同步调用，虚线=异步消息，点划线=定时任务触发）；
  • 文字标注规范（必须包含协议、路径、超时、重试，缺一不可）；
• 在IDE中集成校验插件：用SonarQube自定义规则，扫描PlantUML文件，对不符合Style Guide的写法（如未标注Timeout的HTTP调用）直接报错；
• 新人入职必考：笔试题有一道“指出下图中3处违反Style Guide的错误”，答错者需重学。

去年我们推行此规则后，跨团队协作会议中，因图理解偏差导致的返工减少了82%。规则不是束缚，而是让自由协作成为可能的基础设施。

5.3 问题三：图更新滞后，线上已跑新逻辑，图里还是老样子

现象：某次线上故障，SRE按图排查，发现图中显示“order-service直接调用payment-service”，但实际代码中已通过API网关中转，导致绕过网关的熔断配置失效。

根本原因：图更新未纳入研发流程，仍是“想起来就更新”的随机行为。

我的排查与解决：

• 将图更新设为PR准入门槛：在GitLab CI中添加检查步骤，当PR修改了/src/main/java/com/xxx/payment/下的代码，且未同步修改/docs/diagrams/下的对应PlantUML文件时，CI直接失败，并提示“请更新order-payment-flow.puml”；
• 自动化变更检测：用Python脚本定期扫描所有服务的@RequestMapping、@KafkaListener、@Scheduled注解，生成“服务调用关系快照”，与PlantUML图比对，差异自动发企业微信告警；
• 设立“图管家”轮值制：每两周由一名资深开发担任，职责不是画图，而是审核所有图的准确性、推动更新、组织双周图评审会。

注意：不要指望一个人记住所有服务的调用关系。把人脑记忆，转化为机器可执行的规则和自动化检查，才是可持续之道。

5.4 问题四：非技术人员看不懂图，认为“画得再好也没用”

现象：给产品经理讲解时，对方盯着时序图说“这些箭头我看不懂，能不能说人话？”

根本原因：把diagram-design当作技术人的自嗨，忘了它的终极目的是“降低认知成本”。

我的排查与解决：

• 为每张图配“人话摘要”：在PlantUML文件顶部，用'开头的注释块，写一段不超过100字的白话说明。例如：

  ' 【人话摘要】用户点“确认收货”后，系统会：1) 给用户结款 2) 把商品库存加回来 3) 关闭物流单 4) 发放积分。任一环节失败，系统会自动回退前面已完成的动作。

• 制作“图-场景”映射表：在Confluence中建立表格，左列是业务场景（如“用户退货”“商家上架新品”），右列是对应的所有diagram-design链接，并标注“这张图解决了该场景下的哪个具体问题”；
• 开展“图解工作坊”：每月一次，邀请产品、运营、客服参加，不讲技术细节，只用图演示“当XX事件发生时，系统内部发生了什么”，并现场收集反馈：“这里哪个词让你困惑？我们把它换成你熟悉的说法”。

真正的专业，不是让别人适应你的表达，而是把自己的表达，适配到别人的认知频道上。一张图，如果不能让产品经理在5分钟内抓住重点，那它就还没完成自己的使命。

6. 进阶实践：让diagram-design成为系统演进的导航仪

6.1 从静态图到动态仿真：用图预测系统瓶颈

diagram-design的最高阶用法，是让它从“描述现状”升级为“预测未来”。我们曾用PlantUML+自研脚本，对“订单履约链路图”做了压力仿真：

1. 为每个节点注入性能参数：在PlantUML注释中，为payment-service添加' P99 Latency: 1200ms, Max TPS: 1500；
2. 为每条连线注入网络参数：为order -> payment连线添加' Network Latency: 15ms, Packet Loss: 0.02%；
3. 运行仿真脚本：脚本读取这些参数，模拟1000TPS请求流经整条链路，计算端到端P99延迟、各节点CPU负载、网络带宽占用；
4. 生成热力图报告：自动标出payment-service节点为红色（预测CPU将达92%），logistics-service连线为黄色（网络延迟将突破阈值）。

这个仿真结果，直接推动了我们在大促前两周，对支付服务进行垂直扩容，并优化了物流服务的网络调用方式。图，第一次成了容量规划的决策依据，而非事后的复盘材料。

6.2 图即文档：自动生成API契约与测试用例

我们进一步将diagram-design与API生命周期打通：

• 当PlantUML时序图中出现order -> payment: POST /v1/settlements时，脚本自动：
  • 在Swagger YAML中生成对应/v1/settlements的OpenAPI定义，包括requestBody示例、responses状态码、x-rate-limit扩展；
  • 在JUnit测试类中，生成testSettlementSuccess()和testSettlementTimeout()两个测试方法，其中@Test注解里已预置@Timeout(value = 3, unit = TimeUnit.SECONDS)；
  • 在Postman中，创建名为[Order] Settlement Success的请求，Body已填充{"orderId":"ORD-TEST","amount":99.00}。

这意味着，只要图更新了，API文档、单元测试、集成测试用例就自动同步。开发写完代码，跑一遍测试，发现testSettlementTimeout()失败——他立刻明白，不是代码错了，而是图中写的Timeout=3s与实际网络状况不符，需要调整图或优化服务。

6.3 个人经验沉淀：diagram-design的终极价值不在图，在人

干这行十多年，我越来越确信：diagram-design最珍贵的产出，从来不是那张PNG或SVG文件。而是在画图过程中，被迫进行的三次深度思考：

第一次，是结构化思考：把混沌的业务需求，拆解成可枚举的服务、可定义的接口、可验证的状态； 第二次，是批判性思考：当写下order -> payment时，必须自问“这个调用真的必要吗？能不能用事件驱动替代？如果payment挂了，order能降级吗？”； 第三次，是共情式思考：站在SRE角度，想“这个超时设置合理吗？监控埋点够吗？”；站在产品经理角度，想“这个状态流转，用户能感知到吗？需要增加什么提示？”。

这三次思考，把一个被动执行者，锻造成主动的系统构建者。所以，别再问“怎么画一张漂亮的图”，去问“这张图，逼我直面了哪些不敢面对的系统真相？”

我最近一次画图，是在一个即将下线的老旧系统上。明知它几个月后就要退役，我还是花了两天，把它所有的调用关系、数据流向、状态变迁，一丝不苟地画了出来。不是为了给别人看，而是为了在告别前，最后一次，看清它曾经如何呼吸、如何搏动。那一刻我忽然懂了：diagram-design，终究是一场与系统、与自己、与时间的郑重对话。