大家好，我是IT孟德，You can call me Aman(阿瞒，阿弥陀佛的ē，Not阿门的ā)，一个喜欢所有对象（热爱技术）的男人。我正在创作架构专栏，秉承ITer开源精神分享给志同道合（爱江山爱技术更爱美人）的朋友。专栏更新不求速度但求质量（曹大诗人传世作品必属精品，请脑补一下《短歌行》：对酒当歌，红颜几何？譬如媳妇，吾不嫌多...青青罗裙，一见动心，但为佳人，挂念至今...），用朴实无华、通俗易懂的图文将十六载开发和架构实战经验娓娓道来，让读者茅塞顿开、相见恨晚...如有吹牛，不吝赐教。关注wx公众号：IT孟德，一起修炼吧！
专栏文章推荐：
告别16年IT生涯：一场关于内耗、健康和出路的反思
实战：混合云架构Nginx+Lua实现流量跨机房分发
系统性能评估：如何定义并发数、响应时间和吞吐量
架构师的职责是什么？程序员如何转型为架构师？
为什么要做架构设计？架构设计包含哪些内容？
什么是架构？架构如何演进？
Mysql数据库连接池druid、hikaricp优化实战
1、为什么要画图？
架构设计既然叫“设计”，就需要借助相关工具输出持久化文档。如果缺少工具辅助，大脑很难完整模拟复杂系统几十上百个组件之间的交互细节，没有可视化文档载体也不利于向团队传达意图。即使某六边形全能型架构师自己创业，一个人包揽产品、架构、开发、测试、运维所有活，所有的思路如果只存储在大脑里，可能睡一觉或者喝几杯茅台后就断片了。
那么架构文档如何呈现呢？不同的企业的有不同的规范和模板，重点是通过文字和图形把业务、逻辑和物理架构方案描述清楚。其中图形在设计文档中占比较大，如用例图、流程图、时序图、部署视图等。为什么要用图形呢？科学研究表明大脑对图像的处理速度是文字的6万倍，且不纠结这个数据的真伪，大家深有体会的是汇报演讲用图文并茂的PPT比DOC效果更好、《长安的荔枝》拍成电视剧和电影后确实比原本的小说受众更广。架构设计中图形能通过颜色、形状、布局快速传递复杂信息，比如通过颜色区分分层、箭头表示数据流向和依赖关系（复杂关系降维表达）。最重要的是图形可以实现跨语言、跨背景的无歧义沟通。假设交通标志用纯文字表示，国际化大都市的交通秩序估计就要乱套了，老外一下飞机就开始懵逼。当然这些标志也不能自由发挥、一味追求个性化，否则上个公厕都分不清男女。架构设计通过统一的图形突破技术语言壁垒，降低产品、测试、运维以及开发等不同技术背景的角色理解成本。
2、架构图怎么画？
图形在架构设计中发挥着重要的作用，那么如何画图呢？通常在保证清晰表达系统结构和设计理念的前提下，我们可以选择EA（Enterprise Architect）、StarUML、visio、drawio、亿图、ppt等任意工具绘制，无需盲目遵循某种方法论。比如轻量级、快节奏的项目中，C4模型、线框图更具效率。对于需要高精度表达或遵循严格规范的场景，UML（Unified Modeling Language）是最佳选择。UML提供了一套统一的图形化建模语言，能清晰表达系统的静态结构、动态行为和部署关系，减少团队成员因理解偏差导致的沟通成本。UML的优势主要体现在以下几方面：
标准化与通用性：UML是OMG（Object Management Group，简称偶买噶）采纳为国际标准认可的建模语言，具有统一的符号、语法和语义，便于团队协作和跨项目交流。UML的价值不在于视觉效果美化，而是一门“可执行的图形化语言”。它与普通图形的区别如同编程语言与自然语言的差异，编程语言（如Java、Python）由机器可解析的固定语法构成，能精准表达逻辑；自然语言（如中文、英文）用于直观沟通，存在一定的歧义和模糊性。在复杂软件系统中，UML 通过标准化建模，让图形从理解工具升级为工程设计工具。
多维度建模能力：最新版本UML2.5（2017年12月发布）通过静态结构、动态行为两大类14种标准图形覆盖多方面需求，适用于复杂系统的分析与设计。
工具支持成熟：有大量商业（EA、Astah、Visual Paradigm、StarUML，悄悄告诉大家：如果你写代码用的IDE没花钱，这些工具也可以不用花钱~~~）和开源（ArgoUML、PlantUML、BoUML）以及draw.io在线工具支持，可实现可视化建模、模型验证（如接口一致性检查）、代码生成与逆向工程（如从数据库、代码反向生成模型）。
工具
厂商
许可类型
跨平台支持
模型支持
易用性
适用场景
Enterprise Architect
Sparx Systems（澳大利亚）
商业
Windows
完整UML2.5模型、SysML （系统工程建模，UML扩展）、BPMN（业务流程建模）、ERD（实体关系图，数据库建模）、ArchiMate（TOGAF企业架构建模）、DoDAF/UPDM（国防与航空领域的架构框架）等
特点：功能全面、支持中文UI、性价比高，适合全生命周期管理和多领域建模的团队
功能强大但界面相对复杂，学习成本高
支持从需求分析到代码生成的全生命周期建模，适用于大型项目和复杂系统的设计
MagicDraw
达索系统（法国）
商业
Windows、Linux、MacOS
完整UML2.5模型、SysML、BPMN、ERD、DFD（数据流建模）、Model Transformation自定义建模语言能力
特点：SysML领域的标杆工具，专注于复杂系统工程（MBSE）和高精度建模（如国防、航空航天、汽车电子）
功能强大但界面复杂，学习成本高
Visual Paradigm
Visual Paradigm（香港）
商业
Windows、Linux、MacOS
完整UML2.5模型、BPMN、SysML、ArchiMate、DFD、ERD、SoaML（面向服务架构建模语言）、CMMN（案例建模）
特点：深度支持UML+EA+敏捷+BPMN，中文界面接地气
界面友好，适合快速上手，学习成本中
StarUML
MKLabs（韩国）
商业+开源（社区版本功能有限）
Windows、Linux、MacOS
完整UML2.5模型、SysML、C4 Model、4+1 View Model、BPMN、ERD、DFD等
特点：轻量级，社区插件丰富、开发者可自由定制功能
简洁直观，学习成本中
平衡功能与易用性，教学、敏捷团队、轻量级建模
Astah
Change Vision（日本）
商业
Windows、Linux、MacOS
完整UML2.5模型、SysML、DFD、ERD等
特点：轻量级，提供专业版个UML简化版
简单易用，学习成本中
ArgoUML
开源社区
开源免费
跨平台（Java）
仅支持到UML1.4
自2014年起，项目进入维护阶段，不再发布新功能，界面老旧
学习UML、小型项目、个人使用
PlantUML
开源社区
开源免费
跨平台（Java）
不对标具体UML版本特性（支持主要uml图）、C4 Model、甘特图（Gantt）、思维导图（Mindmap）等
特点：通过简洁的脚本语法生成各类软件设计图，支持集成到 IDE（如 IntelliJ、VS Code）
缺少可视化编辑，需熟悉语法，程序员友好
BoUML
开源社区
开源免费
Windows、Linux、MacOS X Intel
支持 UML 2.5 中的大部分核心图表类型，但部分高级特性或复杂语义未完全实现（如不支持交互概览图和时序图复杂时间约束）
特点：开源灵活性、多语言支持和高性能
界面相对传统，功能分散，新手可能需要较长时间熟悉
Visio
微软
商业
Windows
基础UML图（类图、用例图、活动图等）
高度集成Office，学习成本低
侧重图形绘制而非标准建模（同类型的还有亿图图示以及各种在线文档），适合流程或非工程场景
draw.io
JGraph
开源免费
Windows、Linux、MacOS、Web、IOS、Android
通过手动绘图功能模拟大部分UML图表类型、流程图、ERD、BPMN、网络拓扑、线框图
极简操作
3、画什么图？
了解了UML和相关建模工具，又该如何应用到架构设计中呢？为了便于理解，本文以众所周知的12306的票务系统（不含管理端）为例，分别从业务架构、逻辑架构和物理架构的维度展开分析和建模。所有分析纯属个人揣摩，并非实情，主要目的是传达思想和理念，建模工具VP、EA和StarUML都有试用。
3.1、业务架构建模
业务建模是架构设计的基础，通过结构化的方式描述业务需求、流程和约束，明确业务边界与范畴，为系统设计与开发提供输入。其价值在于分解业务复杂度、统一团队业务理解，确保技术实现与业务目标一致。
业务领域模型图
领域模型（Domain Model）是对业务领域核心概念、规则、逻辑和关系的抽象表达。它通过对象（实体、值对象）、行为（方法）、关系（关联、聚合）以及约束（业务规则）来描述现实世界中的业务规则、实体关系和操作逻辑，为后续的模块划分、数据库设计和代码实现等提供依据。在所有UML类型中，类图（Class Diagram）与领域模型的特征最匹配。作为天天与对象打交道的码农，类图中的实体、属性和方法并不陌生，这里介绍一下对象之间的关系。
关系类型
定义
符号
示例
关联
类之间的一种结构化关系，说明对象之间如何相互连接。可以是单向或双向的，包含多重性（如 1 对 1、1 对多）。
实线连接两个类，双向关联无箭头，单向关联用箭头指向被关联的类
学生与课程（双向关联）：一个学生可以选修多门课程，一门课程可以被多个学生选修
聚合
特殊的关联，表示“整体-部分”关系，但部分可以独立于整体存在。
空心菱形指向整体，另一端用实线连接部分
班级和学生 ：班级解散不影响学生，学生可以去别的班
组合
更强的聚合关系，“整体-部分” 关系中部分不能独立于整体存在。
实心菱形指向整体，另一端用实线连接部分
教学楼和教室：教学楼拆除，教室也随之销毁
泛化
父类与子类的继承关系，子类继承父类的属性和方法并可扩展特有行为。
空心三角形箭头指向父类
课程与选修课：选修课继承了课程的公共属性
实现
表示类对接口的实现关系，类实现接口中定义的方法。
虚线加空心三角形箭头指向接口
自习室、实验室、图书馆等类实现了“预约接口”
依赖
一种弱关系，表示一个类的变化可能影响另一个类。
虚线箭头指向被依赖的类
学生与教材：学生学习时依赖教材
了解了类图中的各种关系，我们再结合票务系统的实际需求，提炼业务领域中有实际意义的“类”，定义其属性和方法并分析类之间的业务联系，建立对应关系。
业务实体
属性
方法
关系
说明
用户（User）
用户ID、用户名、密码、手机号
注册（）、登录（）、修改（）
关联(1:n)乘客 关联(1:n)订单
一个用户可以添加多个常用乘客，创建多个订单
乘客（Passenger）
乘客ID、姓名、证件类型、证件号、类型（成人/儿童）、联系方式
添加乘客（）、修改乘客（）
关联(n:1)用户
乘客信息由用户添加和管理
车次（Train）
车次ID、车次号、类型（高铁/动车/特快/普快）、始发站（发车时间）、终点站（终到时间）、途径站（到时、发时）
查询车次（）
组合(1:n)座位 关联(n:m)车站 关联(1:n)车票
一个车次包含多个座位（座位的号码与类型等与车次是强绑定，脱离车次就不存在了），经过多个车站，对应多张车票
座位（Seat）
座位 ID、座位号、座位类型（商务座/一等座/硬卧）、所属车次、状态（已售、未售）
锁定座位（）、释放座位（）
组合(n:1)车次 关联(1:1)车票
座位属于特定车次，一张车票对应一个座位
车站（Station）
车站ID、车站名称、拼音、所在城市
关联(m:n)车次 关联(2:1)车票
一个车站可以有多趟车次停靠，一张车票包含出发站和到达站
车票（Ticket）
车票ID、车次号、出发站、到达站、发车时间、票价、车厢号、座位号、座位类型
计算票价（）、生成车票（）、退票（）、改签（）
组合(n:1)订单 关联(1:1)座位 关联(1:2)车站 关联(n:1)车次
关联(1:1)乘客
车票是订单的一部分（火车票属于“定制商品”，不可独立存在，订单取消或退款，车票也随之销毁），对应一个座位、一个乘客和两个车站，属于特定车次
订单（Order）
订单ID、订单号、下单时间、状态
提交订单（）、取消订单（）、支付（）、退款（）
关联(1:n)用户 组合(1:n)车票
订单由用户创建，包含多张车票
最后依据上述分析，我们可以快速完成领域建模，参考如下（图中未完全标记类的属性和方法）：
业务用例图
业务用例是描述业务流程中参与者（如用户、系统、外部实体）与业务目标之间交互的模型，用于捕捉业务需求的核心功能和流程。它聚焦于业务目标而非技术实现，用于清晰界定业务范围、参与角色及业务流程的期望结果。业务用例图可直接使用UML用例图（Use Case Diagram）表示。
元素
定义
示例
参与者（Actor）
明确与系统交互的外部实体（用户、系统或硬件）
普通用户、会员、管理员、第三方支付系统
用例（Use Case）
描述系统提供的功能或服务
查询车票、选择座位、提交订单、支付、查看订单、取消订单等
系统边界（System Boundary）
界定系统包含的功能范围，框定所有用例
购票系统的边界包含注册、查询、预订、支付等所有与购票相关的用例
关联关系（Association）
连接参与者与用例，表示交互关系
“会员” 与 “购票” 用例之间的实线连接
泛化关系（Generalization）
子用例继承父用例的行为和属性，并可覆盖或扩展其逻辑。
UML表示：空心三角箭头，箭头指向父用例
购票<--学生票购票
查询车票<--直达查询、中转查询
支付<--微信支付、支付宝支付、积分支付、云闪付
包含关系（Include）
基础用例必须执行被包含用例的行为，属于强制性依赖。
特点：被包含用例是必选的、可复用的。
UML表示：虚线箭头 + <
购票-->查询车票、选车次、选座位、选乘车人、提交订单、支付，如“查询车票”可以被“改签”复用
扩展关系（Extend）
扩展用例在特定条件触发时增强基础用例的行为，属于可选分支。
特点：扩展用例存在与否不影响基础用例的完整性
UML表示：虚线箭头 + <
购票<--候补，“候补”可单独存在，仅在余票不足时激活
依赖关系（Dependency）
基础用例的执行依赖另一用例的的实现或输出，但两者没有强制的调用关系，通常表示数据或状态依赖。UML2.x依赖关系逐渐被包含/扩展替代，需谨慎使用，避免过度关联导致模型复杂。
UML表示：虚线箭头，箭头指向被依赖用例
改签-->退票,改签需先退原票再购新票，依赖退票的成功状态
在12306票务系统中，购票功能强依赖查询车票、选车次、选车位等子用例，子用例之间存在严格的调用顺序，而非松耦合的依赖关系。又因查询车票属于一个独立的业务，用户可以主动触发，所以查询车票又直接与用户关联。票务系统用户购票必然还会涉及登录、积分管理等功能以及管理员角色，下图不一一列举，读者可自行分析。
业务流程图
业务流程图可视化业务流程的逻辑、参与者交互、决策节点和关键路径，支持业务规则验证，识别流程漏洞和异常，通常用UML活动图（Activity Diagram）绘制。
元素
定义
示例
动作（Action）
表示流程中的具体操作
查询车次、选择座位、提交订单、支付、出票
控制流（Control Flow）
连接动作节点，表示流程的顺序
箭头指向下一步
决策（Decision）
表示条件判断，到不同分支路径
是否有余票、支付是否成功
合并（Merge）
合并多个分支路径
不同支付方式后的统一处理
分叉（Fork）
将流程拆分为多个并行分支
如支付成功后同时出票、出保单
汇合（Join）
等待所有并行分支完成后，合并到后续流程
出票、出保单后合并流程，统一发送短信通知
泳道（Swimlane）
按角色或部门划分流程步骤
投诉、建议功能可拆分为用户和管理员（客服）两条泳道绘制流程图
开始/结束节点（Start/End Node）
标记流程的起点和终点
/
购票核心业务流程为查询车票→选择座位→提交订单→支付→出票，下图刻意将活动图Decision/Merge、Fork/Join元素都用上，所以稍显累赘,读者可自行优化、完善候补分支，整个流程面向用户和场景，不关注技术实现，应避免出现技术术语，如“OAuth2认证”可用“用户身份认证”代替。
3.2、逻辑架构建模
逻辑架构关注系统的功能组成、模块划分及其交互关系，所以逻辑架构图围绕功能边界、职责划分、交互流程和层次关系等维度展开，从不同的视角清晰展现系统的逻辑结构。UML提供的包图、对象图、类图、组件图、交互图等都适用于逻辑架构阶段精细建模，但过度使用UML可能会导致模型臃肿（如类图包含数百上千个类），增加沟通成本。所以通常我们会借鉴C4模型的思想，通过C4把控架构整体分层，用UML符号（如组件）补充细节，形成宏观和微观相结合的非标准UML视图。
C4模型通过四个递进层级描述系统架构。Context（上下文）描述系统与外部实体（用户、设备、第三方系统等）的关系；Container（容器）分解系统为可独立部署的单元（高层次组件分类，如Web应用、数据库、微服务、API等）及其通信协议（如HTTP、RPC）；Component（组件）进一步分解容器内部结构，展示组件/功能模块间的协作（如订单服务、认证组件等及其依赖关系）；Code（代码）细化到类、接口、函数等代码级结构。
维度
C4 Model
UML
定位
聚焦于系统结构的分层描述
提供通用的全生命周期建模语言
抽象方式
四层递进式静态结构（Context→Container→Component→Code）
多种图类型（类图、时序图、用例图等），无固定层级，支持静态结构（类图）和动态行为（时序图、活动图）
表达形式
不限制样式，强调可读性
严格的语法规范
适用场景
架构文档、团队沟通、系统概览
面向对象分析与设计、复杂系统行为建模
复杂度
简单直观，可借助任意制图工具快速绘制
复杂灵活，需掌握多种图类型和符号
系统上下文图
系统上下文以直观的图形化方式帮助团队快速理解系统的边界、用户角色和外部依赖（系统内部细节完全隐藏，仅作为黑盒展示）。12306票务系统的外部角色有普通用户和注册会员，依赖的外部系统可能有第三方支付平台、公安实名认证系统、运营商手机核验系统、学生资质核验系统、税务电子发票系统、保险系统、客服系统、SMS短信系统等。另外官方声明从未对外开放任何票务查询和订票API，个人猜测第三方火车票查询、预订主要通过模拟用户操作或者与地方火车站票务系统合作实现。
逻辑架构图
逻辑架构图整合了C4 Model中的Container和Component，概括系统分层逻辑、模块划分以及内外部依赖关系和通信机制。逻辑架构图的核心要素是组件，相比与标准的UML组件图，主要引入了分层，通过层级边界约束复杂度。至于如何分层、分多少层级依据业务复杂度和技术成本而定，简单场景用三层（表现层、业务逻辑层、数据访问层）快速落地，复杂领域用DDD构建护城河，分布式系统通过微服务分层应对高并发挑战，最终目标就是层内高内聚，层间低耦合，系统持续可演进。以下示例图可以根据实际业务场景不断调整优化，譬如数据库和中间件可以统一纳入基础设施层、监控层独立、增加外部依赖服务等，但需要注意的是，逻辑架构强调“抽象逻辑”，不涉及具体技术实现，非必要不要将api网关直接标注为apisix、数据库指定mysql、mongoDB。
系统流程图
系统上下文和逻辑架构图都属于静态结构视图，而系统流程图则从动态视角描述系统内部模块、组件间的数据流转与交互逻辑，与系统上下文和逻辑架构图形成互补。系统流程应与业务流程相呼应，可以用UML顺序图表示，描述消息在生命线间传递的时间顺序。生命线表示参与交互的对象（如用户、系统组件）；消息表示对象间交互的方式及内容（如方法调用），分为同步消息（需等待接收方响应，如查询车票需要及时返回结果）、返回消息、异步消息（如异步生成发票）、自调用消息等。生命线和消息的粒度可以根据业务复杂度把控，如下图可增加库存服务、数据库可细化为检索数据库和关系型数据库、支付前增加检查订单状态、出票前增加检查支付状态等。
3.3、物理架构建模
与逻辑架构关注功能抽象不同，物理架构强调系统的实际落地形态，聚焦系统的物理部署、硬件资源配置及运行时实体的分布关系。因此物理架构图以节点分布、网络拓扑、部署单元、资源分配等为核心要素，通过可视化方式从基础设施层、网络层、部署层等不同视角呈现系统的物理结构。
物理架构图
物理架构与逻辑架构对应，是逻辑抽象到物理实体的映射。与逻辑架构图对比，物理架构图中分层、组件划分布局总体不变，但此时业务组件已经有了精准的命名、技术选型也已经确认，需要进行更新。
部署架构图
物理架构图已经比较贴近于系统运行真实状态，但没有体现高可用、灾备等策略，不具备实操性。部署架构图将标准的UML组件图和部署图进行合并，约定了组件的分布情况和实例数、服务器规格和数量、所在机房等更加具体的软硬件资源分配，运维工程师依据部署架构图可以轻松实施。实际上大型分布式集群部署架构会非常复杂，会涉及到几百上千台服务器、多个数据中心以及容器编排，这种情况可以按业务拆分绘制部署图，也可以步步为营，先绘制组件部署图（组件如何组合），再绘制集群分布图（每个组合有多少个节点，节点之间如何通信）。为了让示例图显得不那么臃肿，下图并非完全与之前的架构分析相吻合，部分组件直接用云产品代替、节点数量也直接标注为数字。
UML是架构设计建模的有效工具，但并非唯一选择。关键在于根据项目需求、团队习惯和场景特点，挑选最能实现 “清晰沟通与高效设计” 的方式。如果业务非常简单或者团队临时熟悉UML专业建模工具成本较高，那么参照上述设计思想扒拉几个线框图也无可厚非。明知山有虎，绕过明知山，条条大道通罗马。
专栏文章推荐：
告别16年IT生涯：一场关于内耗、健康和出路的反思
实战：混合云架构Nginx+Lua实现流量跨机房分发
系统性能评估：如何定义并发数、响应时间和吞吐量
架构师的职责是什么？程序员如何转型为架构师？
为什么要做架构设计？架构设计包含哪些内容？
什么是架构？架构如何演进？
Mysql数据库连接池druid、hikaricp优化实战