1. 焦头烂额
最近又遇到个焦头烂额的事情 ，老板有了新想法，业务有所转向，需要新的方案设计 ，架构设计，以进行后续实施。很快，第一次汇报来了， 由于前期准备时间短，模块拆分不清晰，有的部分又讲得过细节，表述的不太好，直接被打回了。
一时之间抓耳挠腮，怎么汇报，讲清其中的设计思路，争取到相应资源，是重点，也是难点。这时急需一组架构图，来辅助，拿下汇报！
2. 架构图
开始之前，问2个问题，
核心目的是什么?
业务架构图的核心目的是统一共识、减少沟通成本，无论是项目中的哪个角色大家都能讲一样的话
- 解决沟通障碍
- 达成共识
- 减少歧义
(超小声bb： 讲清楚， 让老板能听懂)
给谁讲，受众是谁?
要明确受众，再想清楚要给他们传递什么信息。
- 小白用户，甚至对于这部分业务也是一知半解
- boss，公司老板，高管
- 技术人员，相关业务人员，甚至后续直接负责开发
- 同事，公司的跨部门的团队，同事
所以你的受众是谁，决定他的关注点和理解能力，也决定他要看到什么样的架构图。
架构图种类
- 业务架构: 业务架构属于顶层设计，概览性强，high level，简洁易懂，又可以根据其展开，其对后续的业务定义和技术架构都有影响;
- 应用架构: 描述有哪些功能，其间的关系是什么样的。根据业务场景需要，设计应用的层次结构。一般由业务负责人或者产品负责人绘制。
- 技术架构: 描述了需要哪些服务；选择哪些技术组件来实现技术服务；技术服务以及组件之间的交互关系;
- 数据架构: 描述了数据模型、分布、数据的流向、数据的生命周期、数据的管理等关系;
方法论
论1: SOA
SOA 是缩写 Service-Oriented Architecture（面向服务的架构），十分经典的分层，设计模式。对应到 应用，服务，资源。
同时在规划云服务相关的架构时，还有种云计算的标准三层架构，即SaaS层，PaaS层，IaaS层。
- SaaS层：具体的应用；
- PaaS层：构建平台层服务能力；
- IaaS层：IT基础设施和虚拟化；
个人理解 ： SaaS层+PaaS层+IaaS层一定程度也可以映射到 ：应用+服务+资源，
即SaaS代表应用，PaaS层代表服务，IaaS层代表了底层依赖的资源。
论2: C4模型
C4指定是 Context 上下文场景、Container 容器、Component 组件和 Classes 类（或者 Code 代码），对应语境图 ，容器图，组件图 ，类图
- 语境图 ：业务示意
- 容器图 ：业务主要部分的展开
- 组件图 ：业务主要部分组件的描述
- 类图 ：如何实现组件（甚至都涉及到代码变量命名）
可以看出C4模型是逐层展开 ，细化的，从high level一直到细节的类设计。
这里有篇 【软件架构设计|C4模型】 介绍，写的比较详细这里不展开细述了。同时这边找了c4模型配套画图工具， 放在文末，见附录 - c4模型。
SOA 和 C4对比：这两种模型简单对比下，
- 个人觉得SOA更普适性，通用，整体比较high level，适合一些概览性的图例。也可以用于前期思路梳理，沟通汇报。
- C4模型，由浅入深，逐层展开，严格按照C4画，画完可以直接对应开发了（细化到了Class/Code层），更适合项目需求定型 比较明确了，或者十分严谨的项目 比如银行，金融相关项目。
论3: 三层架构
这里的三层架构特指 应用架构中的一种标准设计模式( PS: 没有找到其对应专属名称，有知道的小伙伴欢迎打在评论区 :抱拳 )，通常分为表示层（门户）、业务逻辑层（应用）和数据层（支撑）。
- 门户层（Presentation Layer）：这一层是系统的用户界面部分，用户通过它来访问和使用系统。它可以包括网站、移动应用、桌面应用等所有直接与用户交互的前端界面。主要职责是展示数据和捕获用户输入，通常不包含复杂的业务逻辑。
- 应用层（Application Layer）：这一层包含系统的核心业务逻辑和功能。它处理来自门户层的请求，并与支撑层交互以执行必要的操作。这一层确保业务规则得到执行，并且对外提供服务接口（例如API）。
- 支撑层（Support Layer）：这一层负责底层服务或数据存储支持。这一层为应用层提供必要的资源和服务支持，使得业务逻辑可以顺利执行。
至此，架构图的受众，目的，种类，方法论都说了。总结来看就是 ，先明确 受众，再找所需侧重点，最后选取不同方法/模板进行绘图。
下面再用几个具体示例，一起感受下，
3. 示例
参考1 - 滴滴： 业务架构 - SOA
从上到下 ，应用，服务，资源。
参考2 - web服务： 技术架构 - SOA
中间三层可以都认为是服务层 。
参考3 - 数据平台：技术架构 - SOA
参考4 - 非SOA ，纯纯技术架构图
悄咪咪插入一张技术架构图，但是这个不是基于SOA分层思路画的，也可以明显感觉到和之前的结构差异。
这张图的技术架构重点需要回答的就是你在进行软件架构设计过程中，究竟会用到哪些关键技术，哪些开源产品或工具等。
参考5 - 财务系统：应用架构图 - 三层架构
结构从上到下：门户， 服务，支撑。注意：应用功能架构完全是重点描述应用系统具备哪些功能，一个功能究竟是采用什么三层技术架构实现并不用关心。因此功能架构不应该体现数据层，逻辑层，技术点这些内容。
最后，一起扒一个架构图
看到最后，留一个开放问题，这是一张百度自动驾驶平台Apollo开放平台架构图，那么拆解下，可以理清这张架构图是基于什么思路绘制的吗？欢迎有懂行的小伙伴评论区留言。
结语
评判图的好坏
- 一张好的架构图不需要多余的文字解释！受众有没有准确接收到想传递的信息；如果它所导致的疑问比它能解释的问题还要多，那么它就不是一张好的架构图；
- 图中的信息与相应的抽象级别相关，且满足利益相关者(合作方)的需求；
- 内容术语一致、信息粒度大小一致，图例清晰，颜色类型统一，美观；
简单来说，对照文章最开始提到，画出的图好不好的一个最直接标准就是：受众有没有准确接收到想传递的信息。方法论，工具这些都是辅助，最最最重要的，无论是什么形式的架构图，能针对受众，表达清楚。 最后再稍微分享几句我的经验，
我的经验
1，学习：别人架构模板，SOA ，方法论。
2，模仿：看网上各种画的好的，最近发现个 亿图图示 里面有大量优秀图例，在文末附录 - 图例参考。
3，实践：我的笨办法 ，尽可能的枚举。不论绘制什么类型架构图，都先尽可能枚举，比如枚举场景，功能或者技术信息，尽可能多的列出相关信息 ，再整合抽象 。 也是有人说 书先读厚，再读薄的过程 。
文末彩蛋，多视角
架构图都是可以拆解和再展开的，比如对于应用层本身又可以考虑业务域进一步拆分，或者根据业务生命周期拆分为多个阶段域再展开描述。也可以说一个完整的架构本身就是多视角，可以从多个视角去描述。
最后感谢各位读者观看，创作不易 ，汇总梳理创作耗费大量时间。如果觉得有所帮助 或者 启发，还麻烦点赞，收藏，这是对作者的最大支持！:抱拳
参考
系统架构图怎么画
如何绘制漂亮的架构图，方法论+工具:
讲什么是SOC，分层
如何画好架构图1
如何画好架构图2
人人都是产品经理， 不同种类的架构图
c4模型
图例参考
绘制工具
绘制工具参考，个人推荐draw.io，免费开源，各个端都支持，还有网页版 多人协助也可以。
网友评论