软件架构（software architecture）是软件设计的高层部分，是用于支撑更细节的设计的框架。有些人对“架构”和“高层设计”加以区分----架构指的是适用于整个系统范围的设计约束，而
高层设计指的是适用于子系统层次或多个类的层次上的设计约束（但不是整个系统范围的设计）。
架构的典型组成部分
程序组织
系统架构首先要以概括的形式对有关系统做一个概述，架构应该定义程序的主要构造快，应该明确定义各个构造快的责任，应该明确定义各个构造快的通信规则。
主要的类
架构应该详细定义所用的主要的类，应该指出每个主要的类的责任，以及该类如何与其他类交互。瞄准80/20法则：对那些构成系统的80%的行为的20%的类进行详细说明。
数据设计
架构应该描述所用到的主要文件和数据表的设计，数据通常应该只有一个子系统或者一个类直接访问，架构应该详细定义所用数据库的高层组织机构和内容。
业务规则
如果架构依赖于特定的业务规则，那么他就应该详细描述这些规则，并描述这些规则对系统设计的影响。
用户界面设计
用户界面常常在需求阶段进行详细说明。如果没有，就应该在软件架构中进行详细说明。架构应该详细定义Web页面格式，GUI,命令行接口等的主要元素。
资源管理
架构应该描述一份管理稀缺资源的计划。稀缺资源包括数据库连接，线程，句柄等。
安全性
架构应该描述实现设计层面和代码层面的安全性的方法。在制定代码规范的时候应该把安全性牢记在心，包括处理缓存区的方法，处理非受信数据的规则，加密，错误信息的细致程度，保存内存中的秘密数据，以及其他事项。
性能
性能目标可以包括资源的使用。
可伸缩性
可伸缩性是指系统增长以满足未来需求的能力。
互用性
如果预计这个系统会与其他软件或硬件共享数据或资源，构架应该描述如何完成这一任务。
国际化/本地化
输入输出
错误处理
有人估计代码中高达90%的代码是用来处理异常情况，进行错误处理，或者薄记工作，意味着只有10%的代码是用来处理常规的情况，
容错性
架构的可行性
过度过程
健壮性是指“系统在检测到错误后继续运行”的能力。在软件中，链条的强度不是取决于最薄弱的一环，而是等于所有薄弱环节的乘积。