软件架构（software archivtecture）是软件设计的高层部分，是用于支撑更细节的设计的框架。架构也称为“系统架构/system architecture”、“高层设计/high-level design”或“顶层设计/top-level design”。

为什么要把架构作为前期准备呢？

因为架构的质量决定了系统的“概念完整性”。后者继而决定了系统的最终质量。一个经过慎重考虑的架构为“从顶层到底层维护系统的概念完整性”提供了必备的结构和体系，它为程序员提供了指引——其细节程度与程序员的技能和手边的工作相配，它将工作分为几个部分，使得多个开发者或者多个开发团队可以独立工作。

架构的典型组成部分

很多组成部分是优秀的系统架构所共有的。

1.程序组织

系统架构首先要以概括的形式对有关系统做一个综述。

如果对某个类在系统中的角色没有一个清晰的构思，那么编写这个类就是一件令人灰心丧气的工作。描述其他组织结构，才能说明架构最后选定的这种关系组织结构的缘由并且表明各个类都是经过慎重考虑的。

架构应该定义程序的主要构造块（building blocks）。根据程序规模不同，各个构造块可能是单个类，也可能是由许多类组成的一个子系统。每个构造块无论是一个类还是一组协同工作的类和子程序，它们共同实现一种高层功能，诸如用户交互、显示web页面、解释命令、封装业务规则、访问数据等等。每条列在需求中的功能特性（feature）都至少应该有一个构造块覆盖它。如果两个或多个构造块声称实现同一项功能，那么它们就应该相互配合而不会冲突。

应该明确定义各个构造块的责任。每个构造块应该负责某一个区域的事情，并且对其他构造块负责的区域知道的越少越好。通过使各个构造块对其他构造块的了解达到最小，你能将设计的信息局限于各个构造块之内。

应该明确定义每个构造块的通信规则。对于每个构造块，架构应该描述他能直接使用哪些构造块，能间接使用哪些构造块，不能使用哪些构造块。

2.主要的类

架构应该详细定义所用的主要的类。

3.数据设计

架构应该描述所用到的主要文件和数据表的设计。

4.业务规则

如果架构依赖于特定的业务规则，那么它就应该详细描述这些规则，并描述这些规则对系统设计的影响。

5.用户界面设计

用户界面常常在需求阶段进行详细说明。如果没有，就应该在软件架构中进行详细说明。

架构应该模块化，以便在替换为新用户界面时不影响业务规则和程序的输出部分。

6.资源管理

架构应该描述一份管理稀缺资源的计划。稀缺资源包括数据库连接、线程、句柄（handle）等。

7.安全性

架构应该描述实现设计层面和代码层面的安全性的方法。如果先前尚未建立威胁模型（threat model），那么就应该在架构阶段建立威胁模型。

8.性能

如果需要关注性能，就应该在需求中详细定义性能目标。

9.可伸缩性

可伸缩性是指系统增长以满足未来需求的能力。架构应该描述系统如何应对用户数量、服务器数量、网络节点数量、数据库记录数、数据库记录长度、交易量等的增长。如果预计系统不会增长，而且可伸缩性不是问题，那么架构应该明确地列出这一假设。

10.互用性

如果预计这个系统会与其他软件或硬件共享数据或资源，架构应该描述如何完成这一任务。

11.国际化/本地化（Internationalization/Localization）

“国际化”是一项“准备让程序支持多个locales(地域/文化)”的技术活动。

12.输入输出（Input/Output）

输入输出（I/O）是架构中值得注意的另一个领域。

13.错误处理（Error Processing）

错误处理已被证实为现代计算机科学中最棘手的问题之一，你不能武断地处理它。

14.容错性（Fault Tolerance）

架构还应该详细定义所期望的容错种类。

15.架构的可行性（Architectural Feasibility）

设计师多半会关注系统的各种能力，例如是否达到性能目标，能够在有限的资源下运转，实现环境（运行环境）是否有足够的支持。架构应该论证系统技术的可行性。

16.过度工程（Overengineering）

详细定义一种过度工程（裕度工程）的方法尤其重要，因为许多程序员会出于专业自豪感，对自己编写的类做过度工程。通常在架构中明确的设立期望目标，就能避免出现“某些类异常健壮，而其他类勉强够健壮”的现象。

17.关于“买”还是“造”的决策（Buy-vs-Build Decision）

18.关于复用的决策（Reuse Decisions）

19.变更策略（Change Strategy）

20.架构的总体质量（General Architectural Quality）

架构应该是带有少许特别附加物的精炼且完整的概念体系。