系统设计必备：逻辑架构图的概念、绘制与最佳实践

在系统设计中，我们经常听到“架构图”这个词，但很多团队画出的图要么过于技术细节（像部署图），要么过于模糊（像白板上的方框和箭头）。逻辑架构图（Logical Architecture Diagram）正是填补这一鸿沟的关键产物——它关注系统的职责划分、组件交互与层次关系，而不纠缠于具体的物理节点、操作系统或中间件版本。本文将深入探讨逻辑架构图的核心概念、绘制方法，并用 PlantUML 给出完整示例，帮助你构建既清晰又可扩展的系统蓝图。

为什么要画逻辑架构图？

逻辑架构图回答的是“系统由哪些逻辑部分组成？这些部分如何协作？”这个问题。它的核心价值在于：

抽象复杂性：隐藏物理部署细节，专注于业务能力和模块划分。
沟通桥梁：让业务方、开发、测试、运维在同一个抽象层次上讨论系统。
指导开发：明确服务/组件的边界，为微服务拆分、模块依赖管理提供依据。
演化基础：支持迭代重构，因为逻辑架构的变化比物理部署更频繁。

与物理架构图（Physical Architecture Diagram）不同，逻辑架构图不关心 IP、端口、容器实例数；与功能架构图不同，它强调组件间的协作和依赖关系。

逻辑架构图的核心要素

一个标准的逻辑架构图通常包含以下元素：

元素	说明	示例
组件	具有明确定义的职责逻辑单元，如服务、模块、库	`订单服务`、`支付模块`
连接	组件之间的交互关系，如调用、消息、数据流	`HTTP REST`、`异步消息`
边界	将相关组件聚合成一个逻辑分组，如层、域、子系统	`业务层`、`数据层`
层	常见分层架构中的抽象层（表现层、业务层、持久层）	`Web UI`、`Application`、`Domain`、`Infrastructure`

在绘制时请牢记：逻辑架构图是“关于什么”而非“在哪里”的图。不要画服务器、容器、IP 地址。

绘制逻辑架构图的步骤

1. 确定系统边界与上下文

首先使用上下文图（Context Diagram）界定系统与外部实体（用户、第三方系统）的边界。例如，一个电商系统外部有买家、卖家、支付网关、物流系统。

2. 识别核心业务能力

利用 DDD 或业务建模，找出系统中的核心业务领域，如订单、支付、库存、通知。每个领域可以成为一个逻辑组件。

3. 设计组件间交互

明确组件之间的依赖方向、通信方式（同步/异步）。这一步最容易出错：避免双向依赖，尽量形成单向调用或事件驱动。

4. 分层与分组

按照职责将组件分层。经典的四层架构：表现层 → 应用层 → 领域层 → 基础设施层。微服务架构中则按业务域分组。

5. 验证与迭代

与团队 review 图，检查是否有遗漏的职责、是否存在循环依赖、抽象层次是否一致。

工具推荐与 PlantUML 代码示例

PlantUML：文本化建模，易于版本控制，支持多种 UML 图形。推荐使用组件图（Component Diagram）或部署图（Deployment Diagram）的变形。
Draw.io / Diagrams.net：拖拽式，与 PlantUML 配合使用。
C4-PlantUML：若想遵循 Simon Brown 的 C4 模型，可以用 PlantUML 绘制容器图（相当于逻辑架构的容器级别）。

下面以微服务架构的电商系统为例，展示 PlantUML 绘制的逻辑架构图。该图属于 C4 模型中的 Container 图级别（在逻辑架构中常被称为服务级视图）。

@startuml 电商系统逻辑架构图
!include <C4/C4_Container>
!include <C4/C4_Context>

Person(buyer, "买家", "通过浏览器或App下单")
Person(seller, "卖家", "管理商品与订单")
System_Ext(payment_gateway, "支付网关", "处理第三方支付")
System_Ext(logistics, "物流系统", "配送与追踪")

System_Boundary(ecommerce, "电商系统") {
    Container(web, "Web应用", "React + Nginx", "提供用户界面")
    Container(mobile, "移动App", "iOS/Android", "提供移动端界面")
    Container(gateway, "API网关", "Kong / Zuul", "认证、限流、路由")
    
    Container_Boundary(business, "业务逻辑层") {
        Container(order_svc, "订单服务", "Spring Boot", "订单创建、状态管理")
        Container(payment_svc, "支付服务", "Spring Boot", "支付处理与回调")
        Container(inventory_svc, "库存服务", "Spring Boot", "库存扣减与预占")
        Container(notification_svc, "通知服务", "Node.js", "发送短信、邮件、站内信")
        Container(message_bus, "消息总线", "Kafka / RabbitMQ", "异步事件传递")
    }
    
    Container_Boundary(data, "数据层") {
        Container(order_db, "订单数据库", "PostgreSQL", "存储订单与详情")
        Container(payment_db, "支付数据库", "PostgreSQL", "存储支付流水")
        Container(inventory_db, "库存数据库", "MySQL", "存储库存快照与日志")
        Container(cache, "缓存", "Redis", "热点数据缓存与锁")
    }
}

' 关系定义
Rel(buyer, web, "使用", "HTTPS")
Rel(buyer, mobile, "使用", "HTTPS")
Rel(seller, web, "管理", "HTTPS")
Rel(web, gateway, "请求", "HTTP/JSON")
Rel(mobile, gateway, "请求", "HTTP/JSON")

Rel(gateway, order_svc, "路由", "HTTP/REST")
Rel(gateway, payment_svc, "路由", "HTTP/REST")
Rel(gateway, inventory_svc, "路由", "HTTP/REST")

Rel(order_svc, order_db, "读写", "JDBC")
Rel(payment_svc, payment_db, "读写", "JDBC")
Rel(inventory_svc, inventory_db, "读写", "JDBC")

' 异步消息
Rel(order_svc, message_bus, "发布事件", "订单已创建")
Rel(payment_svc, message_bus, "发布事件", "支付成功")
Rel(inventory_svc, message_bus, "发布事件", "库存变化")
Rel(message_bus, notification_svc, "消费事件", "触发通知")

' 外部调用
Rel(payment_svc, payment_gateway, "调用", "HTTP/REST")
Rel(gateway, logistics, "调用", "HTTP/REST")

SHOW_LEGEND()
@enduml

代码说明：

使用 C4_Container 宏生成标准容器图样式，每个容器代表一个逻辑部署单元（服务）。
边界 System_Boundary 和 Container_Boundary 用于分层分组。
同步调用用 Rel 实线箭头，异步事件用 Rel 加文字标记（如“发布事件”）。
注意：这里未画出物理节点（如服务器 IP），角色是逻辑的（买家、卖家），外部系统也是逻辑抽象。

执行后的效果类似于：

逻辑架构图的最佳实践

保持抽象层次一致
不要在同一个图中既画微服务又画类和接口。逻辑架构图通常是组件层或容器层的视图。如果需要更细的类级别，请使用类图或组件内部图。
聚焦核心业务依赖
只画主要的、稳定的交互。不要试图画出所有数据库索引或健康检查端点，那属于物理/devops 图。
使用颜色区分角色
例如：蓝色表示业务服务，绿色表示基础设施，橙色表示外部系统。颜色要配合图例。
定期更新，与代码对齐
逻辑架构图容易过时。建议将其纳入 CI/CD 或文档检查流程（例如，使用 structurizr 等工具自动生成）。
避免孤岛设计
每个逻辑组件必须有明确的输入和输出，且不能与超过三个组件有直接依赖。如果出现“上帝组件”，则需要拆分。

逻辑架构图 vs 其他架构图

类型	关注点	抽象级别	典型元素
逻辑架构图	职责、交互、层次	中（组件/服务）	服务、模块、层、消息
物理架构图	部署、节点、网络	低（机器/容器）	服务器、负载均衡、数据库实例
功能架构图	业务功能、流程	高（业务活动）	用例、功能模块、数据流
数据流图	数据流动与存储	中（数据）	外部实体、数据存储、进程

总结

逻辑架构图是系统设计的通用语言，它剥离了物理实现的噪音，让团队聚焦于“系统如何处理业务”。通过明确组件边界、交互方式和分层策略，逻辑架构图能够有效指导微服务拆分、模块重构以及多团队协作。

本文给出的 PlantUML 示例可以直接复制到你的项目中，并基于实际业务调整。记住：好的架构图不是一次画完的，而是在持续演进中保持清晰和一致。现在，拿起工具画出你的第一个逻辑架构图吧！

posted @ 2026-06-23 11:40 XYu1230 阅读(20) 评论(0) 收藏举报

刷新页面返回顶部

XYu1230