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》）

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

 —————————————————————————–

————–延申—–如何画软件架构图？————————–

 —————————————————————————–

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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