依赖关系图示例

这些示例展示团队如何在修改系统前把软件关系可视化。它们特别适合那些自然演进多年、风险依赖已经不明显的架构。

真实案例

使用场景: 规划后端重构的工程团队

表现层：Web App、Mobile App

接口层：BFF/Gateway、Public API

领域层：Auth、Billing、Catalog

数据层：Primary DB、Redis Cache、Search Index

关键路径：Web App → BFF → Billing → Primary DB

可选路径：Web App → Public API → Catalog

这样组织的原因: 按层级组织后，很容易发现前端是否绕过了预期网关，或者多个服务是否依赖了同一个数据存储。

使用场景: 决定先抽取哪个模块的技术负责人

单体模块：Auth、Orders、Catalog、Notifications

共享数据库表：users、orders、products

外部依赖：Stripe、SendGrid、Search

候选抽取：Notifications 入站依赖最少

高风险抽取：Orders 涉及支付和库存

这样组织的原因: 依赖关系图应该揭示拆分顺序。最适合先抽取的模块通常是边界清晰、写耦合低的模块，而不一定是看起来最重要的模块。

使用场景: 排查故障的 SRE 或工程经理

症状：checkout API 延迟升高

上游调用方：Web checkout、Mobile checkout、Admin order tool

下游依赖：Payment API、Inventory Service、Primary DB

共享依赖：Redis cache miss rate 升高

影响范围：所有创建订单路径受影响

这样组织的原因: 故障中，依赖图帮助团队区分症状和依赖。团队可以快速看出哪些调用方受影响，以及哪个下游系统最可能导致失败。

使用场景: 在环境之间迁移服务的平台团队

当前环境：旧 VM 服务和共享 PostgreSQL

目标环境：Kubernetes 服务和托管数据库

网络依赖：防火墙规则、服务发现、私有端点

临时桥接：旧 API Gateway 同时路由到两个环境

切换顺序：先迁移无状态服务，再迁移有状态存储

这样组织的原因: 迁移图需要同时展示当前依赖和目标依赖。如果不画临时桥接和切换顺序，架构图会隐藏项目里最难的部分。

回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。