架构的典型组成部分

程序组织
1、系统架构首先要以概括的形式对有关系统做一个综述。
2、应该定义程序的主要构造块，根据程序规模不同各个构造块可能是单个类，也可能是由许多类组成的一个子系统。
3、应该明确定义各个构造块的责任。每个构造块应该负责某一个区域的事情，并且对其他构造块负责的区域知道得越少越好。
4、应该明确定义每个构造块的通信规则。对于每个构造块，应该描述它能直接使用哪些构造块，能间接使用哪些构造块，不能使用哪些构造块。
主要的类
架构应该详细定义所用的主要的类，应该指出第一个类的责任，以及该类如何与其它类交互。
数据设计
架构应该描述所用到的主要文件和数据表的设计。它应该描述曾经考虑过的其他方案，并说明做出选择的理由。数据通常只应该由一个子系统或一个类直接访问。
业务规则
如果架构依赖特定的业务规则，那么它就应该详细描述这些规则，并描述这些规则对系统设计的影响。
用户界面设计
用户界面常常在需求阶段说明
资源管理
架构应该描述一份管理稀缺资源的计划。稀缺资源包括数据库连接，线程，句柄等。
安全性
架构应该描述实现设计层面和代码层面的安全性的方法。如建立威胁模型
性能
如果需要关注性能，就应该在需求中详细定义性能目标，如资源的使用以及速度，内存，成本之间的优先顺序。
可伸缩性
可伸缩性是指系统增长以满足未来需求的能力。
互用性
如果有与其他软件或硬件共享数据或资源，架构应该描述如何完成这一任务。
国际化/本地化
架构应该描述如何实现国际化。
输入输出
架构应该详细定义读取策略是先做、后做还是即时做，应该描述在哪一层检测I/O错误：在字段、流，或者文件的层次。
错误处理
应该定义错误处理的方式
容错性
架构还应该详细定义所期望的容错类。如果可能的话从错误中恢复，如果不能从错误中恢复，则包容不利影响。
架构可行性
是否能达到性能目标，能够在有限的资源下运转，实现环境是否有足够支持
过度工程
健壮性是指“系统在检测到错误后继续运行”的能力。
关于“买”还是“造”的决策
如果已经有符合项目的软件，尽量使用。如果架构不采用现货供应的组件，那么就 应该说明“自己定制的组件应该在哪些方面胜过现成的程序库和组件”
关于复用的决策
如果开发计划提倡使用业已存在的软件、测试用例、数据格式或其它原料，架构应该说明。
变更策略
架构应该清楚地描述处理变更的策略。列出已经考虑过的有可能会有所增强的功能，并说明“最有可能增强的功能同样也是最容易实现的”。
架构的总体质量
优秀的架构规格书的特点在于，讨论了系统中的类、讨论了每个类背后的隐藏信息，讨论了“采纳或排斥所有可能的设计替代方案”的根本理由。好的架构设计应该与待解决的问题和谐一致，在查看架构的时候，应该很愉快，因为它给出的解决方案看上去既自然又容易。架构的目标应该清楚地表述，应该描述所有主要决策的动机。谨防“我们向来这么做“这种自认为有理的说法。
架构应该踏在对系统”欠描述“和”过度描述“之间的分界线上。架构应该明确地指出有风险的区域。应该包含多个视角，最后，架构不应该包含任何对你而言很理解的东西，因为你就是那个实现架构的人，如果你自己都弄不懂，那怎么实现它？