什么是架构 架构图

如何成为一名架构师,架构师成长之路_golang架构师成长之路_个人渣记录仅为自己搜索用的博客-CSDN博客

如何画架构图_个人渣记录仅为自己搜索用的博客-CSDN博客

如何画好一张架构图？（内含知识图谱） - 知乎

什么是架构？要表达的到底是什么？

Linus 03 年在聊到拆分和集成时有一个很好的描述：

I claim that you want to start communicating between independent modules no sooner than you absolutely HAVE to, and that you should avoid splitting things up until you really need to, because that communication complexity often swamps the complexity of the actual pieces involved in it.（让我们认识到一种现象，把 复杂系统拆分成模块，似乎并没有降低 整个系统的复杂度。它降低的只是 子系统的复杂度。而整个系统的复杂度，反而会由于拆分后的模块之间，不得不进行 交互，变得更加复杂。）

我理解这里描述的系统拆分就是架构的过程，基本出发点是为了效率，通过架构的合理拆分（无论是空间还是时间上的拆分），最终目的让效率最大化。那到底什么是架构，其实没有完全统一且明确的定义，如下三个定义可以参考。

在百度百科上的定义：

架构，又名软件架构，是有关软件 整体结构与组件的 抽象描述，⽤于指导⼤型软件系统各个方面的设计。

在 Wikipedia 上的定义：

Architecture is both the  process and the  product of planning, designing, and constructing buildings or any other structures.

ISO/IEC 42010:20072 中对架构有如下定义：

The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.　

这三个定义也是见仁见智，但是我们基本可以得出：架构体现的是整体结构和组件之间的关系。

IEEE对于软件系统架构的定义：

Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE 1471]

organization 是组织的意思，这里理解为组织结构。

直译：架构是一个系统在其组件层面的基本组织结构表现，包括系统内部组件之间的关系、组件与外部的关系以及决定其设计和演进的原则。

《系统架构-复杂系统的产品设计与开发》一书中用最简单的话来描述架构：

“对系统中的实体及实体之间的关系所进行的抽象描述。”

（第九页，出自Edward Crawley等人专著论文《The Influence of Architecture in Engeering Systems》）

以上两种表述，第一种措辞严谨精确，可用于书面定义；第二种更直白容易理解，可用于日常表达。

架构和抽象

Haskell 语言的设计者之一 Paul Hudak 曾说过一句略带夸张的话：编程中最重要的三件事是：抽象，抽象，抽象。

 抽象的本质其实是 抽出共同的(类似的)字段 + 分类 + 取名概念, 类比 界门纲目科属种概念的提出.

本质是：

• 抽象角度其实也是分类的角度，角度不同，会导致完全不同建模方向和结果；
• 抽象的角度就是建模的方向和目的（“屁股决定脑袋”）。

重新回到我们前边的两个问题，业务建模中我们谈到了归类，按什么去归类，答案呼之欲出，按我们的业务流程去归类、按客户的角色去归类，按不同流程复用的东西去分类( phil补充), 又回到了那个最初始的问题：客户是谁？核心诉求是什么？

 -----------------------------------------------------------------------------

--------------延申-----如何画软件架构图？--------------------------

 -----------------------------------------------------------------------------

软件架构图的目的是将设计表达出来，而一套设计包含多个维度，一个图基本上表达不完，那就需要多个图，需要哪些图？

画架构图目前有几种选择：

1、遵循一些标准体系，这些标准要求应该有哪些东西，我们就画哪些东西，这里列两个标准：

TOGAF: 企业架构领域的一个标准框架，定义了四种图，从不同维度来表现一套架构设计，包括业务架构、技术架构、数据架构、应用架构，以下引用摘自WIKI

开放组体系结构框架（英语：The Open Group Architecture Framework，缩写：TOGAF）是一个企业架构框架，它提供了一种设计，规划，实施和管理企业信息技术架构的方法[2]。TOGAF是一种高层设计方法。 它通常被建模为四个级别：业务，应用程序，数据，和技术。 它在很大程度上依赖于模块化，标准化以及已有的，经过验证的技术和产品。

RUP:  是由Rational Software公司开发的一套搞软件工程方法，其中有一块做软件架构设计的方法使用的是一篇论文中的内容——4+1视图，看了一圈，比较抽象，我也不太理解，就不说了，具体可以自行查询

我个人更倾向于TOGAF的四种图，因为容易理解：

软件架构的定义基本上就是说有哪些组件，他们之间的关系。但是组件这个定义比较泛，在不同的维度组件上表现为不同的东西，TOGAF的四种图就是从四个维度对软件架构定义的套用：

从业务维度上来说，至少要描述清楚有哪些系统，有什么功能，他们之间的关系是怎么样的等等

从技术整体维度上来说，由哪些 中间件/子系统/技术组件 组成，他们之间的关系是怎么样的等等

从单个应用程序维度上来说，里用到了什么开发技术，做了什么分层，它又会把数据存到哪等等

从数据维度上来说，有哪些数据，存在哪，如何存，他们之间如何转化、流转的等等

2、自己画，能说清意思就行

说实在的，我们画图的目的就是表达清楚自己设计的内容，对老板，对产品、对研发、对运维，只要能达到目的也没必要非得纠结这些目前还没达成统一的标准。自己画就行

最后，画图的时候不要想着把所有细节都能弄进去。对于一个庞大的系统，不要妄想几张图就说清所有的事情；也不要画几张图就撒手不管做起ppt架构师了，架构图固然重要（错误的设计会导致项目组很难受，甚至导致项目失败，试错成本相当高），引导团队进行架构的落地过程也相当重要，这是对你架构设计质量以及你个人技术能力的检验。

3、C4模型

C4模型是一种更为容易理解的模型，学习成本低，表达效果好，直接上链接

用于软件架构的C4模型_架构_Simon Brown_InfoQ精选文章

https://www.infoq.com/articles/C4-architecture-model/