01前言你是不是被大厂展示的各种五光十色的架构设计图深深吸引了，当我们想用几张图来介绍业务系统的时候，你是不是知道从哪里开始画布？做技术leader的难道不需要一张图来描述这个系统，让系统中的所有参与者都能看懂吗？如果有这样的困惑，本文将介绍一些绘图方法，让技术绘图更清晰。02体系结构的定义系统体系结构是概念的体现，是对象/信息的功能和形式元素之间的对应关系的分配，元素之间的关系以及元素与周围环境的关系。定义;体系结构是对系统中实体和实体之间关系的抽象描述，是一系列的决策；架构是结构和愿景。在TOGAF企业架构理论中，架构是从公司的战略层面出发，从上到下细化的下一部分是从战略=>业务架构=>应用/数据/技术架构。当然boss层关注的是战略和业务架构。我们需要关注应用/数据/技术架构层。业务架构：由业务架构师负责，也称业务领域专家、行业专家，业务架构属于顶层设计，其对业务的定义和划分会影响组织架构和技术架构；应用架构：由应用架构师负责，根据业务场景的需要，设计应用的层次结构，制定应用规范，定义接口和数据交互协议等，并尽量控制应用的复杂度在可接受的水平上，从而快速支持业务发展，同时保证系统的可用性和可维护性，确保应用满足性能、安全、稳定性等非功能属性的要求。技术架构：描述了哪些服务是必要的;选择哪些技术组件来实施技术服务；技术服务和组件之间的交互；数据架构：描述数据模型、分布、数据流、数据生命周期、数据管理等关系；03架构图的分类系统架构图是抽象表示软件系统的总体轮廓、各组成部分之间的相互关系和约束边界，以及软件系统物理部署和演化方向的总体视图软件系统。一个好的架构图可以让利益相关者理解和遵循架构决策，架构信息需要传递。那么，画架构图的目的是：解决沟通障碍/达成共识/减少歧义。比较流行的是4+1视角和C4视角。3.14+1视图3.1.1场景视图用于描述系统参与者和功能用例之间的关系，反映系统的最终需求和交互设计，通常用用例图表示；3.1.2逻辑视图用于描述系统软件功能分解后的组件关系、组件约束和边界反映了系统的整体组成和系统构建的过程，通常用UML组件图和类图表示。3.1.3物理视图用于描述系统软件和物理硬件之间的映射关系，反映系统的组件如何部署在一组可计算的计算机节点上，用于指导系统的部署和实施过程软件系统。3.1.4处理流视图用于描述系统软件组件之间的通信顺序、数据的输入输出，反映系统的功能流和数据流，通常用时序图和流程图表示。3.1.5开发视图开发视图用于描述系统的模块划分和组成，以及内部包的详细组成设计，为开发人员服务，反映系统开发和实施过程。五个架构视图从不同的角度代表软件系统的不同特性，组合在一起作为架构蓝图来描述系统架构。3.2C4视图下面的案例来自C4官网，然后加入了一些笔者的理解。C4模型使用容器（应用程序、数据存储、微服务等）、组件和代码来描述软件系统的静态结构。这几种图比较容易画，也给出了画图的要点，但最重要的是，在我们看来，它清楚地指出了每幅图可能的受众和意义。3.2.1SystemContextDiagram用于描述我们要构建的系统是什么，用户是谁，需要如何集成到现有的IT环境中。此图的受众可以是开发团队内部的人员，也可以是技术人员或非技术人员的外部人员。3.2.2容器图容器图是在上下文图中对要构建的系统的扩展描述。主要受众是团队内外的开发人员或运维人员。主要用于描述整个软件系统的形式，反映高层的技术决策和选择，系统中的职责如何分配，容器之间如何交互。3.2.3ComponentDiagram组件图是对某个容器进行扩展，描述其内部模块。主要是让内部开发者看到如何组织和构建代码，描述了哪些组件/服务组成，定义了组件之间的关系和依赖关系，为软件开发如何分解交付提供了一个框架。04如何画好架构图上面的分类是对之前经验的总结，图也摘自网络。那么这些图表好吗？画这样的图一定要照葫芦画瓢吗？不管这些图好不好，我们都想过这些图的分类和作用。综上所述，我们认为在明确了这两点之后，从观众的角度来看，好的架构图是不需要解释的，它应该是自我描述的、一致的、准确的，足以与代码相呼应。4.1视图的受众在画好架构图之前，首先要明确它的受众，然后再思考要向他们传达什么信息。所以，不要为了画物理视图而画物理视图，而要画逻辑视图。要画出逻辑视图，要根据不同的受众、不同的传达信息，准确地用图表表达出来。最终图表可能属于此类。那么，画出的画面好坏的一个直接标准就是：观众是否准确地接收到了他们想要传达的信息。4.2视图元素的区分可以看到，架构视图是由框、线等元素组成的。需要用形状、颜色、线条的变化来区分元素的含义，避免混淆。架构是一项复杂的工作，仅用一张图来表示很容易导致莫名其妙的语义混乱。
