一.什么是软件架构

在这一章我们主要从一个软件工程师的角度出发，来看软件架构对一个正在进行的工程有什么影响。

哪些是软件架构，哪些不是

对于有关软件架构的概念，我们推崇如下定义:

一个系统的软件架构(Software-Architecture)是指，在构建这个系统的过程中使用的一系列结构(Structure)的集合，包括软件中的元素，元素之间的关系以及元素和关系拥有的属性。

有些定义宽泛的认为软件架构就是系统"最初"或者"最主要"的设计决定，这是不对的，尽管对于大多数的架构决定的制定确实在系统开发的早期，但是在敏捷和螺旋增量开发的项目中，许多在系统初期做的决定并不是有关架构方面的。同时我们也很难有一个判断标准去衡量一个决定是否是最主要的，通常对重要与否的判断在时间而不是我们。鉴于，架构是结构的集合，对结构进行设计，会相对简单一些。

下面是对软件架构定义的一些推论

---

架构是一系列软件结构的集合

结构，是由一系列的元素和它们之间的关系组成，而软件系统就是由许多这样的结构组成，一个单独的结构不能被称为是一个架构，毕竟架构是一系列结构的集合，那么也可以这么理解，一个软件系统对应一个架构，而一个架构对应的是软件结构的集合，以下三种结构在对软件架构的设计，记录和分析中起到重要的作用。

• 第一类结构：把系统按照功能分为不同的实现单元，在这本书中，我们把这些实现单元称为"模块"(module)，模块有各自的任务并被分配给不同的任务团队去实现，同时，对于那些比较复杂的模块，还可以继续对模块进行划分，在模块内部产生划分结构，比如以类图，层等，并分配给子团队去实现。

• 第二类结构：这些结构被称为是动态的，它们更多的关注于元素在交互过程中产生的系统功能，在这本书中我们把这样的结构称为"组件-联系结构(component-and-connector,C&C)"，术语"组件(component)"理解为一个实体。

• 第三类结构：描述了软件结构和系统之间的映射，比如模块和系统硬件方面的映射，这些映射通常也被称为是分配结构(allocation structure)。

尽管组成软件的结构有很多，但不是任何一个结构的组合都可以被称为是架构的，当且仅当它们支持了系统的某些功能(重要干系人的需求)或者体现了系统的某些属性的时候才被称为是架构。

综上，组成架构的结构集合并不是固定或者被限制的，这个取决于你的系统真正需要的是什么。

架构是一种抽象

在前面我们有说，架构是结构的集合，而结构又是由元素和元素之间的关系组成。所以可以推出，架构是由软件元素和元素之间的的关系组成。架构站在系统的功能角度，只会关心元素中那些有用的细节而不会去关心那些对实现系统功能没有什么贡献的元素或者可有可无的元素信息。所以，架构就是对系统的抽象，选择一些细节和忽略另一些。在现代的模型中，元素之间依靠接口进行交互，接口把实现细节分为公有和私有部分，架构更多的关注公有部分，而不会去关注那些元素内部的实现，所以私有部分不属于架构。总的来说，抽象对于简化问题的复杂性来说非常重要。

每一个软件系统都存在一个软件架构

每一个软件系统都可以通过展示元素和元素之间的关系来说明系统支持的功能。

尽管每一个软件系统都有软件架构，但是没必要所有人都知道它，有可能当初设计架构的人已经离开了，但是文档和实现代码可能依旧存在，或者干脆当初就没有记录文档，代码也丢失了，只有一个可以运行的结果存在，但这都没有关系，架构可以不依赖他具体的描述和实现存在。

架构包含行为

行为(behavior)可以体现出元素之间是如何交互的达到说明系统的目的，从我们对架构的定义可以看出，行为是属于架构的。
对元素的行为的定义不能单纯的依靠专有名词，比如database...，虽然有些用户看到这个名词马上就可以联想到对应的功能，但是依靠用户的想象去定义是不科学的。相反，也不是说所有元素的功能和行为都需要被详细记录，而是那些会对其他元素产生影响的行为或者对整个系统产生影响的行为需要被记录，并作为软件架构的一部分存在。

不是所有的架构都是好的架构

当然，选择一个最好的架构，并用它来构建系统是我们需要做的，这就体现了在架构设计的重要性。