大家好，我是IT孟德，You can call me Aman(阿瞒，阿弥陀佛的ē，Not阿门的ā)，一个喜欢所有对象（热爱技术）的男人。我正在创作架构专栏，秉承ITer开源精神分享给志同道合（爱江山爱技术更爱美人）的朋友。专栏更新不求速度但求质量（曹大诗人传世作品必属精品，请脑补一下《短歌行》：对酒当歌，红颜几何？譬如媳妇，吾不嫌多...青青罗裙，一见动心，但为佳人，挂念至今...），用朴实无华、通俗易懂的图文将十六载开发和架构实战经验娓娓道来，让读者茅塞顿开、相见恨晚...如有吹牛，不吝赐教。关注wx公众号：IT孟德，一起修炼吧！

--01--

架构设计为什么要画图？

架构设计既然叫“设计”，就需要借助相关工具输出持久化文档。如果缺少工具辅助，大脑很难完整模拟复杂系统几十上百个组件之间的交互细节，没有可视化文档载体也不利于向团队传达意图。即使某六边形全能型架构师自己创业，一个人包揽产品、架构、开发、测试、运维所有活，所有的思路如果只存储在大脑里，可能睡一觉或者喝几杯茅台后就断片了。

那么架构文档如何呈现呢？不同的企业的有不同的规范和模板，重点是通过文字和图形把业务、逻辑和物理架构方案描述清楚。其中图形在设计文档中占比较大，如用例图、流程图、时序图、部署视图等。为什么要用图形呢？科学研究表明大脑对图像的处理速度是文字的6万倍，且不纠结这个数据的真伪，大家深有体会的是汇报演讲用图文并茂的PPT比DOC效果更好、《长安的荔枝》拍成电视剧和电影后确实比原本的小说受众更广。架构设计中图形能通过颜色、形状、布局快速传递复杂信息，比如通过颜色区分分层、箭头表示数据流向和依赖关系（复杂关系降维表达）。最重要的是图形可以实现跨语言、跨背景的无歧义沟通。假设交通标志用纯文字表示，国际化大都市的交通秩序估计就要乱套了，老外一下飞机就开始懵逼。当然这些标志也不能自由发挥、一味追求个性化，否则上个公厕都分不清男女。架构设计通过统一的图形突破技术语言壁垒，降低产品、测试、运维以及开发等不同技术背景的角色理解成本。

--02--

架构图怎么画？

图形在架构设计中发挥着重要的作用，那么如何画图呢？通常在保证清晰表达系统结构和设计理念的前提下，我们可以选择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在线工具支持，可实现可视化建模、模型验证（如接口一致性检查）、代码生成与逆向工程（如从数据库、代码反向生成模型）。

--03--

画什么图？

了解了UML和相关建模工具，又该如何应用到架构设计中呢？为了便于理解，本文以众所周知的12306的票务系统（不含管理端）为例，分别从业务架构、逻辑架构和物理架构的维度展开分析和建模。所有分析纯属个人揣摩，并非实情，主要目的是传达思想和理念，建模工具分别试用了VP、EA和StarUML。

3.1 业务架构建模

业务建模是架构设计的基础，通过结构化的方式描述业务需求、流程和约束，明确业务边界与范畴，为系统设计与开发提供输入。其价值在于分解业务复杂度、统一团队业务理解，确保技术实现与业务目标一致。

• 业务领域模型图
  
  

领域模型（Domain Model）是对业务领域核心概念、规则、逻辑和关系的抽象表达。它通过对象（实体、值对象）、行为（方法）、关系（关联、聚合）以及约束（业务规则）来描述现实世界中的业务规则、实体关系和操作逻辑，为后续的模块划分、数据库设计和代码实现等提供依据。在所有UML类型中，类图（Class Diagram）与领域模型的特征最匹配。作为996与对象打交道的码农，类图中的实体、属性和方法并不陌生，这里着重介绍一下对象之间的关系。

了解了类图中的各种关系，我们再结合票务系统的实际需求，提炼业务领域中有实际意义的“类”，定义其属性和方法并分析类之间的业务联系，建立对应关系。

最后依据上述分析，我们可以快速完成领域建模，参考如下（图中未完全标记类的属性和方法）：

• 业务用例图
  
  

业务用例是描述业务流程中参与者（如用户、系统、外部实体）与业务目标之间交互的模型，用于捕捉业务需求的核心功能和流程。它聚焦于业务目标而非技术实现，用于清晰界定业务范围、参与角色及业务流程的期望结果。业务用例图可直接使用UML用例图（Use Case Diagram）表示。

在12306票务系统中，购票功能强依赖查询车票、选车次、选车位等子用例，子用例之间存在严格的调用顺序，而非松耦合的依赖关系。又因查询车票属于一个独立的业务，用户可以主动触发，所以查询车票又直接与用户关联。票务系统用户购票必然还会涉及登录、积分管理等功能以及管理员角色，下图不一一列举，读者可自行分析。

• 业务流程图

业务流程图可视化业务流程的逻辑、参与者交互、决策节点和关键路径，支持业务规则验证，识别流程漏洞和异常，通常用UML活动图（Activity Diagram）绘制。

购票核心业务流程为查询车票→选择座位→提交订单→支付→出票，下图刻意将活动图Decision/Merge、Fork/Join元素都用上，所以稍显累赘,读者可自行优化、完善候补分支，整个流程面向用户和场景，不关注技术实现，应避免出现技术术语，如“OAuth2认证”可用“用户身份认证”代替。

3.2 逻辑架构建模

逻辑架构关注系统的功能组成、模块划分及其交互关系，所以逻辑架构图围绕功能边界、职责划分、交互流程和层次关系等维度展开，从不同的视角清晰展现系统的逻辑结构。UML提供的包图、对象图、类图、组件图、交互图等都适用于逻辑架构阶段精细建模，但过度使用UML可能会导致模型臃肿（如类图包含数百上千个类），增加沟通成本。所以通常我们会借鉴C4模型的思想，通过C4把控架构整体分层，用UML符号（如组件）补充细节，形成宏观和微观相结合的非标准UML视图。

C4模型通过四个递进层级描述系统架构。Context（上下文）描述系统与外部实体（用户、设备、第三方系统等）的关系；Container（容器）分解系统为可独立部署的单元（高层次组件分类，如Web应用、数据库、微服务、API等）及其通信协议（如HTTP、RPC）；Component（组件）进一步分解容器内部结构，展示组件/功能模块间的协作（如订单服务、认证组件等及其依赖关系）；Code（代码）细化到类、接口、函数等代码级结构。

• 系统上下文图

系统上下文以直观的图形化方式帮助团队快速理解系统的边界、用户角色和外部依赖（系统内部细节完全隐藏，仅作为黑盒展示）。12306票务系统的外部角色有普通用户和注册会员，依赖的外部系统可能有第三方支付平台、公安实名认证系统、运营商手机核验系统、学生资质核验系统、税务电子发票系统、保险系统、客服系统、SMS短信系统等。另外官方声明从未对外开放任何票务查询和订票API，个人猜测第三方火车票查询、预订主要通过模拟用户操作或者与地方火车站票务系统合作实现。

• 逻辑架构图

逻辑架构图整合了C4 Model中的Container和Component，概括系统分层逻辑、模块划分以及内外部依赖关系和通信机制。逻辑架构图的核心要素是组件，相比与标准的UML组件图，主要引入了分层，通过层级边界约束复杂度。至于如何分层、分多少层级依据业务复杂度和技术成本而定，简单场景用三层（表现层、业务逻辑层、数据访问层）快速落地，复杂领域用DDD构建护城河，分布式系统通过微服务分层应对高并发挑战，最终目标就是层内高内聚，层间低耦合，系统持续可演进。以下示例图可以根据实际业务场景不断调整优化，譬如数据库和中间件可以统一纳入基础设施层、监控层独立、增加外部依赖服务等，但需要注意的是，逻辑架构强调“抽象逻辑”，不涉及具体技术实现，非必要不要将api网关直接标注为apisix、数据库指定mysql、mongoDB。

• 系统流程图

系统上下文和逻辑架构图都属于静态结构视图，而系统流程图则从动态视角描述系统内部模块、组件间的数据流转与交互逻辑，与系统上下文和逻辑架构图形成互补。系统流程应与业务流程相呼应，可以用UML顺序图表示，描述消息在生命线间传递的时间顺序。生命线表示参与交互的对象（如用户、系统组件）；消息表示对象间交互的方式及内容（如方法调用），分为同步消息（需等待接收方响应，如查询车票需要及时返回结果）、返回消息、异步消息（如异步生成发票）、自调用消息等。生命线和消息的粒度可以根据业务复杂度把控，如下图可增加库存服务、数据库可细化为检索数据库和关系型数据库、支付前增加检查订单状态、出票前增加检查支付状态等。

3.3 物理架构建模

与逻辑架构关注功能抽象不同，物理架构强调系统的实际落地形态，聚焦系统的物理部署、硬件资源配置及运行时实体的分布关系。因此物理架构图以节点分布、网络拓扑、部署单元、资源分配等为核心要素，通过可视化方式从基础设施层、网络层、部署层等不同视角呈现系统的物理结构。

• 物理架构图

物理架构与逻辑架构对应，是逻辑抽象到物理实体的映射。与逻辑架构图对比，物理架构图中分层、组件划分布局总体不变，但此时业务组件已经有了精准的命名、技术选型也已经确认，需要进行更新。

• 部署架构图

物理架构图已经比较贴近于系统运行真实状态，但没有体现高可用、灾备等策略，不具备实操性。部署架构图将标准的UML组件图和部署图进行合并，约定了组件的分布情况和实例数、服务器规格和数量、所在机房等更加具体的软硬件资源分配，运维工程师依据部署架构图可以轻松实施。实际上大型分布式集群部署架构会非常复杂，会涉及到几百上千台服务器、多个数据中心以及容器编排，这种情况可以按业务拆分绘制部署图，也可以步步为营，先绘制组件部署图（组件如何组合），再绘制集群分布图（每个组合有多少个节点，节点之间如何通信）。为了让示例图显得不那么臃肿，下图并非完全与之前的架构分析相吻合，部分组件直接用云产品代替、节点数量也直接标注为数字。

UML是架构设计建模的有效工具，但并非唯一选择。关键在于根据项目需求、团队习惯和场景特点，挑选最能实现 “清晰沟通与高效设计” 的方式。如果业务非常简单、来不及熟悉UML专业建模工具，那么参照上述设计思想扒拉几个线框图也没问题。明知山有虎，绕过明知山，条条大道通罗马。