关于java:工作两三年了整不明白架构图都画啥

作者：小傅哥
博客：https://bugstack.cn

积淀、分享、成长，让本人和别人都能有所播种！????

一、前言

很多程序员画架构图头疼，不晓得画什么、怎么画！

分享 、 评审 、 述职 、 问难，只有你在程序员这个行业，就简直离不开要画图。

一提到画图很多人就想站会起来喊，”内卷“、”内卷啦“、”PPT 工程师“，但程序代码自身就是一种数学逻辑的具体实现，如果没有一些图表配合文字的论述，讲真很难让所有人都能在独特的共识下进行交换。

这不像是理科，”八表流云澄夜色，九霄华月动春城“上来就能联想到它是在形容啥。然而偏文科代码逻辑或架构设计，只能把形象的内容用图表的模式展示进去，让大家在同一的共识下独特协同工作。

而咱们画的架构图、流程图、结构图、性能图、逻辑图等，都须要难看、好懂、好用、好搞，因为：

• 难看 是为了晋升沟通效率，
• 好懂 是为了晋升交换共识，
• 好用 是为了晋升交付品质，
• 好搞 是为了晋升施行速度。

这就像小人在谋求丑陋姑娘一样，难看就想被动撩一下、有操行和独特的三观很快让你闭口说 我懂你、接下来就是交付品质和施行速度了，那也是瓜熟蒂落的事。

好，别冲动，接下来咱们就开始分心钻研钻研架构图，都有哪些，该怎么画，有什么手法。

二、架构图有哪几种？

仅说技术架构图的话，通常咱们☞指的是选型各项技术组件来撑持整个服务建设的零碎架构。但用于不同人群范畴和不同场景下会有其余分类，如图 26-1 架构图分类

• 业务架构 ：需要初期业务的后果和过程形容个别比拟含糊，可能来自于某个老板、经营或用户的反馈。 客户说海尔洗衣机洗土豆会堵，海尔立马设计专门的土豆洗衣机 业务方向往往是定方向和后果的叫 策略，次要包含业务布局、业务模块和流程以及问题域的列表等。
• 利用架构：服务复用、跨组协同，简略、灵便、整合是利用架构必须思考的点，就像你要上线一个聊天性能，那么聊天内容的输入法、文字辨认、舆情监控以及视频服务、领取服务等，它们都是在利用架构分层下积淀到平台的产物，在供各个方应用。
• 产品架构：业务提需要，产品定计划，绝对于业务的粗放流程，产品架构会更加细腻以及思考各个模块的分层和边界。
• 数据架构：数据的获取、数据的寄存和数据的应用是数据架构要解决的三个问题，数据库寄存、大数据汇总、数据分析等。
• 技术架构：是离程序员最近的架构设计，它不仅是零碎搭建的架构图设计，还包含了构造、性能、流程、逻辑等内容。它的具体形容就是整个零碎如何落地的具体实现计划。

三、Zachman 框架是什么？

Zachman 框架，由约翰 扎科曼（John Zachman）在 1987 年创建的寰球第一个企业架构实践，其论文《信息系统架构框架》至今仍被业界认为是企业架构设计方面最权威的实践。

Zachman 框架（Zachman framework）是一种逻辑构造，它能够对企业信息依照不同分类和不同角度进行示意。

Zachman 框架，从横向六个角度对待企业，这个六个观点能够分为；什么内容、如何工作、什么地点、谁负责、为什么这么做（称为 W5H）。

框架的列由一组工件组成，分为规划者、拥有者、设计者（架构师）、建造者、分包者、产品，或者有时示意为视点：范畴上下文，业务概念，零碎逻辑，技术，物理，组件组装和操作类。整体如图 26-2 TOGAF Zachman 框架

表格横向六项 代表了用于形容信息系统的某一个方面，对于任何一个事物只有在这几个根本方面对其进行荡涤的解释就足够能够形容分明。

• 数据（What，即什么内容）：什么是业务数据，信息或对象？
• 性能（How，即如何工作）：业务如何运作，即什么是业务流程？
• 网络（Where，即何处）：企业经营、部署在哪里？
• 人（Who，即何人负责）：什么人？什么是业务部门及其等级制度？
• 工夫（When，即什么工夫）：业务打算和工作流程是什么？什么时候执行？
• 起因（Why，即为什么做）：为什么抉择的解决方案？这是怎么产生的？

表格纵向六项 代表了在信息系统结构过程中所波及到的人在形容信息系统时所采纳的视角，包含：

• 范畴 / 规划者（Planner）：此视图形容了业务目标和策略，充当其余视图将被派生和治理的上下文。
• 业务模型 / 拥有者（Owner）：这是对信息系统必须在其中运作的组织的形容。
• 零碎模型 / 设计师（Designer）：该视图概述了零碎如何满足组织的信息需要。
• 技术模型 / 建造者（Builder）：这是零碎如何施行的示意，它使特定的解决方案和技术不言而喻。
• 具体表述 / 分包者（Sub-Contractor）：这些示意阐明了某些零碎元素的特定于实现的细节：在生产开始之前须要进一步阐明的局部。
• 性能零碎 / 产品（Functioning Enterprise）：在 1987 年的论文（《A framework for information systems architecture》）中并没有这一行的内容，实际上此行的内容也并不在架构形容的领域的之内，不过为了使得架构 Zachman 框架对于架构的表述更加齐备，这一行最终还是被加了进去。

依据 TOGAF 的定义，企业是具备一系列独特指标组织的汇合，而架构则是为了无效地实现这一系列指标。

在实现的过程中 定义了企业的构造和运作模式的概念蓝图（SearchCIO），以及形成企业的所有要害元素和其关系的综合形容（Zachman）。通过创立、沟通和优化用以形容企业将来状态和倒退的要害准则和模型以将业务愿景和策略转化成无效的企业变更的过程（Gartner）。

能够这一部分内容会比拟绕，但能够作为架构设计的常识扩大进行学习了解以及使用。

四、陪你画个架构图

简略来说，架构图就是为了达成交换共识的实现计划演示，并不一定非得拘泥于某种模式，只有你能画的分明，讲的明确就最合适不过了。

1. 架构选型图

• 难度：⭐⭐⭐
• 作用：通常在新我的项目开发初期，都要做一些技术选型工作。在负载、网关、架构、治理、框架、服务、数据以及环境和撑持服务上，要抉择适宜以后开发的技术。

2. 微服务架构

• 难度：⭐⭐⭐⭐
• 作用：技术选型结束后，接下来就是对于这些技术的使用。这个过程有点像搭积木一样，把每一个区域用适宜此地位的积木填充进去。如果是团队初建或者是技术升级，那么这个过程还是比较复杂的，须要大量的验证。不过其实互联网的技术分层和应用曾经绝对稳固，搭建一个这样的微服务并不会消耗太长的工夫。

3. 技术架构图

• 难度：⭐⭐⭐⭐
• 作用：技术架构图次要是对于研发层面做技术实现领导的，它能够把零碎分层和实现构造划分分明。另外个别也会把案例工程的构造拿进去一起解说，这样能够让团队搭档疾速的进入开发。

五、总结

• 本章节向大家解说了什么是架构图，架构图的分类和怎么画架构图，通过这样的内容能够让大家对架构图有一个全貌的认知。在当前本人画架构图了也能够十分明确的晓得面对的什么用户群体，要画的内容是什么。
• TOGAF有一套十分欠缺的企业架构实践，它形容了一种开发和治理企业体系结构生命周期的办法，并形成了 TOGAF 的外围。所波及到的常识十分丰盛，值得认真看一下。
• 难看，能把一件事做的难看十分重要，难看能让人提起趣味、难看能够使沟通老本升高。也激励大家尽可能把通过本人手里的货色，做的难看一些。

六、系列举荐

• 方案设计：基于 IDEA 插件开发和字节码插桩技术，实现研发交付品质主动剖析
• 技术扫盲：对于低代码编程的可持续性交付设计和剖析
• 数学，离一个程序员有多近？
• 半年招聘筛选了 400+ 份简历，通知你怎么写容易被撩！
• 90% 的程序员，都没用过多线程和锁，怎么成为架构师？