你是否曾被大厂那些清晰、专业的系统架构图所吸引？当需要向团队或合作伙伴介绍自己的业务系统时，是否面对空白画布感到无从下手？作为核心技术人员，你是否需要一张能让各方（产品、开发、运维、管理者）都一目了然的系统蓝图？
本文将介绍几种主流的架构图绘制方法论与分类体系，帮助你提升技术图纸的清晰度与沟通效率。
架构的定义
- 系统架构是概念的体现，是对物/信息的功能与形式元素之间对应关系的分配，是对元素间关系及其与周边环境关系的定义。
- 架构是对系统中实体及实体间关系的抽象描述，是一系列决策的集合。
- 架构是结构，也是愿景。
在经典的 TOGAF企业架构 理论中，架构是公司战略自上而下细化的关键环节：战略 -> 业务架构 -> 应用/数据/技术架构。管理者通常关注战略与业务架构，而研发团队则需要聚焦在应用、数据和技术架构的实现层面。
- 业务架构：由业务架构师或领域专家负责，属于顶层设计，其业务定义与划分直接影响组织架构和技术架构。
- 应用架构：由应用架构师负责。需根据业务场景设计应用层次结构，制定规范、定义接口与数据交互协议，在快速支撑业务发展的同时，控制复杂度，保障系统的可用性、可维护性及性能、安全等非功能性需求。
- 技术架构：描述需要哪些技术服务，选择哪些技术组件来实现，并明确服务与组件间的交互关系。
- 数据架构：描述数据模型、分布、流向、生命周期及管理关系。
架构图的分类
系统架构图旨在抽象地展示软件系统的整体轮廓、组件关系、约束边界、物理部署及演进方向。一幅优秀的架构图能够有效地将架构决策传递给利益相关者，用于：解决沟通障碍、达成共识、减少歧义。目前业界较为流行的分类方法包括4+1视图和C4模型。
3.1 4+1 视图模型
3.1.1 场景视图
用于描述系统参与者与功能用例之间的关系，反映系统的最终需求和交互设计，通常使用用例图表示。
3.1.2 逻辑视图
用于描述系统软件功能拆解后的组件关系、约束和边界，反映系统的整体构成与构建方式，通常由UML的组件图和类图表示。
3.1.3 物理视图
用于描述系统软件到物理硬件的映射关系，反映组件如何部署到计算机节点上，用于指导系统的部署实施。
3.1.4 处理流程视图
用于描述系统软件组件间的通信时序、数据输入输出，反映系统的功能流程与数据流程，通常用时序图和流程图表示。
3.1.5 开发视图
用于描述系统的模块划分、组成及内部包的设计，主要服务于开发人员，反映系统开发实施过程。
以上5种视图从不同角度刻画软件系统的特征，组合在一起便构成描述系统架构的完整蓝图。
3.2 C4 模型
C4模型通过容器（应用、数据存储、微服务等）、组件和代码来描述软件系统的静态结构，层次清晰，易于绘制。其核心价值在于明确了每种图的受众与意义。
3.2.1 系统上下文图
描述我们要构建的系统是什么，用户是谁，以及它如何融入现有的IT环境。受众可以是内部开发人员，也可以是外部的技术或非技术人员。
3.2.2 容器图
将系统上下文图中的待建系统展开，描述其高层次形态、技术选型、职责分布及容器间的交互。主要受众是内/外部的开发或运维人员。
3.2.3 组件图
将某个特定容器进一步展开，描述其内部的组成模块。主要为内部开发人员服务，说明代码的组织与构建方式，描述组件/服务的构成、关系与依赖。
如何绘制好的架构图
前述分类是经验的总结，示例图也仅供参考。关键在于我们不应机械地套用模板，而应理解其精髓。我们认为，绘制优秀的架构图需明确以下两点：
4.1 明确受众与意图
在动笔之前，首先要明确图的受众是谁，然后想清楚需要向他们传递什么核心信息。切勿为了画“物理视图”而画图，而应基于不同的受众和沟通目的，选择最合适的表达方式。评判图纸好坏的最直接标准就是：受众是否准确、高效地接收到了你想传递的信息。
4.2 清晰的视觉元素区分
架构图由方框、线条等基本元素构成。必须利用形状、颜色、线型（虚实、箭头）等视觉手段明确区分不同元素的含义，避免产生歧义。架构本身是复杂的，试图用单一图表表达所有信息极易导致语义混乱。一份好的架构图应当具备自描述性，保持上下文的一致性、准确性，并能与代码实现形成良好呼应。
发表于 3 天前
|
查看: 6|
回复: 0
