程序组织:
系统架构首先要以概括的形式对有关系统做一个综述，如果没有综述，要想将成千上万的局部图片(或十多个单独的类)拼为一副完整的图画是相当伤脑筋的，如果你不能将它们拼接起来，那么就无法理解你正在开发的那个类对系统有何贡献！
如果在编写一个类的时候，对这个类在系统中的角色没有一个很清晰的构思，那么编写这个类就是一件十分令人灰心丧气的工作。需要对每个类进行慎重考虑！(功能->模块->类->模块->功能)
应该明确定义各个构造块的责任。每个构造块应该负责某一个区域的事情，并且对其它区域的事情知道的越少越好。通过使构造块对其他构造块的了解达到最小，你能将设计的信息局限于各个构造块之内。
应该明确定义每个构造块的通信规则，对于每个构造块，架构应该描述它能够直接使用哪些构造块，能间接使用哪些构造块，不能使用哪些构造块。
主要的类:
架构应该详细定义所用的主要的类。它应该指出每个主要的类的责任，以及该类如何与其它类交互(类的继承体系/状态转换/对象持久化等描述)，根据80/20 规则对系统内部那些构成系统80%的行为的20%的类进行详细说明。
数据设计:
架构应该描述所用到的主要文件和数据表设计。它应该描述曾经考虑过的其他方案，并说明选择的理由(理由也写一写，特别是方案变更选取的时候)。
架构应该定义所用数据库的高层组织结构和内容。指出与其他访问同一数据的程序的可能交互方式，说明会创建哪些数据视图等
业务规则:
如果架构依赖于详细的业务规则，那么就应该详细的描述这些规则，并描述这些规则对系统设计的影响。(比如客户信息过时时间不超过30秒，在此情况下，架构就应该描述这条规则对架构采用的“保持客户信息及时更新且同步”的方法的影响)
用户界面设计:
用户界面常在需求阶段进行详细说明.如果没有就应该在软件架构进行详细说明。
架构应该模块化，以便在替换为新用户界面时不影响业务规则和程序的输出部分。架构应该使我们很容易的做到:砍掉交互式的界面，插入一组命令行的类。
资源管理:
架构设计应该描述一份管理稀缺资源的计划。稀缺资源包括数据库连接/线程/句柄等。应该尝试估算正常和极端情况下的资源使用量。各个类或者各个对象空间和时间的预算。
安全性:
缓冲区/处理非受信数据规则，加密，错误信息的细致程度，保存内存中的秘密数据，以及其他事项。
错误处理:
最后也是最重要的:
错误处理是进行纠正还是仅仅进行检测？如果是纠正，那么程序可以尝试从错误中恢复出来，如果仅仅是检测，那么程序就可以像没发生任何事情一样继续运行，也可也退出，但是无论哪种情况都应该通知用户说检测到了一个错误！
错误监测是主动的还是被动的？
程序如何传播错误？(直接进行错误处理/等到所有处理完成，再通知说某个地方发现了错误!)
错误处理有什么约定?(架构应该有一套完整的错误消息约定)
如何处理异常?(架构应该规定代码何时能够抛出异常，在什么地方抛出异常，如何记录(log)这些异常以及如何在文档中描述这些异常)
每个类在验证其输入数据的有效性方面需要负何种责任？是每个类负责验证自己数据的有效性还是有一组专门的类负责验证整个系统数据的有效性？
容错性:
检查错误的时候倒退回去;
系统有一套辅助代码，已备在主代码出错的时候使用;
表决算法;
系统使用不会对系统产生危害的虚假值来替代这个错误值;
