对架构的初步认识

软件架构（software architecture）是软件设计的高层部分，是用于支撑更细节的设计的框架。有些人对“架构”和“高层设计”加以区分----架构指的是适用于整个系统范围的设计约束，而

高层设计指的是适用于子系统层次或多个类的层次上的设计约束（但不是整个系统范围的设计）。

架构的典型组成部分

程序组织

系统架构首先要以概括的形式对有关系统做一个概述，架构应该定义程序的主要构造快，应该明确定义各个构造快的责任，应该明确定义各个构造快的通信规则。

主要的类

架构应该详细定义所用的主要的类，应该指出每个主要的类的责任，以及该类如何与其他类交互。瞄准80/20法则：对那些构成系统的80%的行为的20%的类进行详细说明。

数据设计

架构应该描述所用到的主要文件和数据表的设计，数据通常应该只有一个子系统或者一个类直接访问，架构应该详细定义所用数据库的高层组织机构和内容。

业务规则

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

用户界面设计

用户界面常常在需求阶段进行详细说明。如果没有，就应该在软件架构中进行详细说明。架构应该详细定义Web页面格式，GUI,命令行接口等的主要元素。

资源管理

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

安全性

架构应该描述实现设计层面和代码层面的安全性的方法。在制定代码规范的时候应该把安全性牢记在心，包括处理缓存区的方法，处理非受信数据的规则，加密，错误信息的细致程度，保存内存中的秘密数据，以及其他事项。

性能

性能目标可以包括资源的使用。

可伸缩性

可伸缩性是指系统增长以满足未来需求的能力。

互用性

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

国际化/本地化

输入输出

错误处理

有人估计代码中高达90%的代码是用来处理异常情况，进行错误处理，或者薄记工作，意味着只有10%的代码是用来处理常规的情况，

容错性

架构的可行性

过度过程

健壮性是指“系统在检测到错误后继续运行”的能力。在软件中，链条的强度不是取决于最薄弱的一环，而是等于所有薄弱环节的乘积。

关于是”买“还是”造“的决策

关于复用的决策

变更策略

架构的总体质量