架构图怎么做 excel(ppt人员组织架构图怎么做)

作者:代码的颜色

1.前言

你是否被大厂展示的各种丰富多彩的建筑设计深深吸引？当我们想用几张图来介绍业务系统的时候，是不是不知道从画布的哪里开始呢？作为技术承载者，我们是否需要一张图来描述系统，让系统中的所有参与者都能理解？

如果有这样的困惑，本文就介绍一些画法，让技术图更清晰。

2. 架构的定义系统架构是概念的体现，是对物/信息的功能与形式元素之间的对应情况所做的分配，是对元素之间的关系以及元素同周边环境之间的关系所做的定义;架构就是对系统中的实体以及实体之间的关系所进行的抽象描述，是一系列的决策;架构是结构和愿景.

在TOGAF的企业架构理论中，架构是从企业战略层面自上而下细化的一部分，从strategy = & gt业务架构= & gt应用/数据/技术架构，当然老板关注的是战略和业务架构，我们搬砖需要重点关注应用/数据/技术架构。

业务架构: 由业务架构师负责，也可以称为业务领域专家、行业专家，业务架构属于顶层设计，其对业务的定义和划分会影响组织架构和技术架构;应用架构: 由应用架构师负责，需要根据业务场景需要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平，从而在快速的支撑业务发展的同时，在保证系统的可用性和可维护性的同时，确保应用满足非功能属性的要求如性能、安全、稳定性等。技术架构: 描述了需要哪些服务；选择哪些技术组件来实现技术服务；技术服务以及组件之间的交互关系;数据架构: 描述了数据模型、分布、数据的流向、数据的生命周期、数据的管理等关系;3.架构图的分类

系统架构图是对软件系统整体轮廓、组件之间的相互关系和约束边界的抽象表示，是软件系统物理部署和演化方向的整体视图。一个好的架构图可以让涉众理解并遵循架构决策，因此传达架构信息是必要的。然后，画架构图的目的是解决沟通障碍/达成共识/减少歧义。4+1观点和C4观点很受欢迎。

3.1 4+1视图

场景视图。

它用于描述系统参与者和功能用例之间的关系，反映系统的最终需求和交互设计，通常用用例图来表示。

逻辑视图

它用于描述系统软件功能分解后的组件关系、组件约束和边界，反映系统的整体构成和如何构建系统的过程。通常用UML的组件图和类图来表示。

物理视图。

它用于描述系统软件和物理硬件之间的映射关系，反映系统的组件如何部署到一组可计算的机器节点上，指导软件系统的部署和实现过程。

加工流程图

用于描述系统软件组件之间的通信时序、数据的输入输出，反映系统的功能流程和数据流，通常用时序图和流程图来表示。

发展观点

开发视图用于描述系统的模块划分和组成，以及内部包的组成设计，服务于开发人员，反映系统开发的实现过程。

五个体系结构视图从不同的角度代表了一个软件系统的不同特征，它们组合在一起，将系统体系结构描述为一个体系结构蓝图。

3.2 C4视图

以下案例来自C4官网，再补充一些作者的理解。

C4模型使用容器(应用程序、数据存储、微服务等。)，描述软件系统静态结构的组件和代码。这几类图很好画，也给出了画的要点，但最重要的是我们认为它明确指出了每一类图可能的受众和意义。

3.2.1上下文图(系统上下文图)

它用于描述我们想要构建什么样的系统，用户是谁，以及如何集成到现有的IT环境中。该图的受众可以是开发团队的内部人员、外部技术人员或非技术人员。

容器图

容器图是对要在上下文图中构建的系统的描述。主要受众是团队内部或外部的开发人员或运维人员。主要用于描述软件系统的整体形式，反映高层的技术决策和选择，系统中的职责如何分配，容器之间如何交互。

组件图

组件图是对一个容器进行扩展，描述其内部模块，主要是给内部开发人员看，如何组织和构建代码，描述系统由哪些组件/服务组成，描述组件之间的关系和依赖关系，为如何分解和交付软件开发提供了一个框架。

4.怎么画好架构图

以上分类是前人经验总结，图片也是从网上摘的。那么这些图片好看吗？我们是不是要按照葫芦画瓢来画这样的图？不管这些图好不好，我们都思考过，总结过。我们认为，一个好的架构图，在明确了这两点之后，不需要从观众的角度去解释。它应该是自描述的，足够一致和准确以回应代码。

4.1 视图的受众

在画一个好的架构图之前，我们首先要明确它的受众，然后想清楚要向他们传达什么信息。所以，我们不应该为了画物理视图而画物理视图，而应该为了画逻辑视图而画逻辑视图。而是要根据不同的受众和传达的不同信息，用图表准确地表达出来。最终的图表可能就是这样的类别。那么，画一幅好画的一个直接标准，就是观众是否准确地接收到了想要传达的信息。

4.2 视图的元素区分

可以看出，建筑视图是由方框、线条等元素构成的。要用形状、颜色、线条变化来区分元素的含义，避免混淆。架构是一项复杂的工作，只用单一的图来表示架构很容易造成莫名其妙的语义混乱。

大家一起来画一个好的架构图吧！

“做程序员，圈子和学习最重要”因为有了圈子，你可以少走弯路，拓宽人脉，拓展思路，学习别人的经验和学习方法！同时也想免费分享一下已经编译好的高级Java后端笔记和学习资料！需要信息的朋友会在私信中扣除【06】。