1.2 软件架构

我们首先定义软件架构的实际含义。当你创建一个应用程序、库或任意软件组件时，你需要考虑你编写的元素看起来是什么样的，以及它们之间将如何交互。换句话说，你是在设计它们以及它们与周围环境的关系。就像城市建筑一样，重要的是要考虑更大的图景，以避免陷入一种无计划的混乱状态。在小范围内，每一栋建筑看起来都不错，但它们不能组合成一个合理的、更大的图景——它们不能很好地结合在一起。这就是所谓的意外架构（accidental architecture），这是应该避免的结果之一。然而，请记住，无论你是否用心构思架构，在编写软件时，你实际就是在构造架构。

那么，如果想认真地定义解决方案的架构，到底应该构造什么呢？软件工程研究所是这样说的：

系统的软件架构是分析系统所需要的一组结构，包括软件的组成元素、元素之间的关系以及两者的属性。

这意味着，为了彻底地定义一个架构，我们应该从几个角度来考虑它，而不是直接编写代码。

看待架构的不同方式

我们可以从以下几个层面研究架构：

❑企业级架构考虑的是整个公司，甚至是一组公司。它采取了一种整体的方法，关注整个企业的战略。在考虑企业级架构时，应该关注公司的所有系统是如何工作和相互协作的。它关心的是业务和IT之间的协调对齐。

❑解决方案架构不如企业级架构抽象。它介于企业级架构和软件架构之间。通常，解决方案架构关注的是特定的系统及其与周围环境的交互方式。解决方案架构师需要找到一种方法来满足特定的业务需求，通常通过设计一个完整的软件系统或修改现有的软件系统来实现。

❑软件架构则比解决方案架构更加具体。它专注于特定的项目、所使用的技术以及如何与其他项目交互。软件架构师对项目组件的内部结构很感兴趣。

❑基础设施架构，顾名思义，关注的是软件使用的基础设施。它定义了部署环境和策略、应用程序的扩展方式、故障转移处理、站点可靠性，以及其他面向基础设施的各方面。

解决方案架构同时以软件架构和基础设施架构为基础，这样才能满足业务需求。接下来的两个部分将讨论这两个方面，以便让你为小规模和大规模的架构设计做好准备。在讨论它们之前，我们还要回答一个基本问题：为什么架构很重要？