架构的典型组成部分
一、程序组织：
1.系统架构首先要以概括的形式对有关系统做一个综述。假设没有这样的综述，要想将成千的局部图片拼成一幅完整的图画是相当伤脑筋的。
2.在架构中，应该发现对那些以前考虑过的终于组织结构的替代方案的记叙。找到之所以选用终于的组织结构。而不用其它替代方案的理由。
3.架构应该定义程序的主要构造块。
依据程序规模不同。各个构造块可能是单个类，也可能是有很多类组成的一个子系统。
4.应该明白定义各个构造块的责任。
每一个构造块应该负责某一个区域的事情。而且对其它构造块负责的区域知道得越少越好。
通过使各个构造块对其它构造块了解达到最小，你能将设计的信息局限于各个构造块之内。
5.应该明白定义每一个构造块的通信规则。
对于每一个构造块。架构应该描写叙述他能直接使用那些构造块，能间接使用那些构造块。不能使用哪些构造块。
二、基本的类
架构应该具体定义所用的基本的类。
它应该指出每个基本的类的责任。以及该类怎样与其它类交互。
它应该包括对类的继承体系、状态转换、对象持久化等的描写叙述。架构无须具体说明系统中的每个类，瞄准80/20原则。对那些构成系统80%的行为的20%类进行具体说明。
三、数据设计
1.架构应该描写叙述所用的主要文件和数据表的设计。
它应该描写叙述以前考虑过的其它方案，并说明做出选择的理由。
2.数据通常仅仅应该由一个子系统或一个类直接訪问。
3.架构应该具体定义所用数据库的最高层组织结构和内容。架构应该解释为什么单个数据库比多个数据库要好（反之亦然），解释为什么不用平坦文件而要用数据库，指出与其它訪问同一数据的程序的可能交互方式，说明会创建哪些数据视图等等。
四、业务规则
假设架构依赖于特定的业务规则。那么它就应该具体描写叙述这些规则。并描写叙述这些规则对系统设计的影响。
五、用户界面设计
1.用户界面经常在需求阶段进行具体说明。假设没有。就应该在软件架构中进行具体说明。
2.架构应该模块化，以便在替换为新用户界面时不影响业务规则和程序的输出部分。
六、资源管理
架构应该描写叙述一份管理稀缺资源的计划。稀缺资源包含：数据库连接、线程、句柄等。
七、安全性
架构应该描写叙述实现设计层面和代码层面的安全性的方法。
在定制编码规范的时候应该把安全性牢记在心，包含处理缓冲区的方法、处理非受信数据的规则、加密、错误消息的仔细程度、保护内存中的秘密数据。以及其它事项。
八、性能
1.假设须要关注性能，就应该在需求中具体定义性能目标。
2.架构应该提供预计的数据，并解释为什么架构师相信能达到性能目标。假设某些部分存在达不到性能目标的风险，那么架构也应该指出来。假设为了满足性能目标，须要在某些部分使用特定的算法或数据类型。架构也应该说清楚。
架构中也能够抱括各个类或各个对象的空间和时间预算。
九、可伸缩性
可伸缩性是指系统增长以满足未来需求的能力。
架构应该描写叙述系统怎样应对用户数量、server数量、网络节点数量、数据库记录数、数据库记录的长度、交易量等的增长。
十、互用性
假设估计这个系统会与其它软件或硬件共享数据或资源，架构应该描写叙述怎样完毕这一任务。
十一、国际化/本地化
对交互系统，国际化问题值得在架构中关注。大多数交互式系统包括几十上百条提示、状态显示、帮助信息、错误信息、等等。应该估算这些字符串所用的资源。
假设这是一个在商业中使用的程序。架构应该表现出已经考虑过典型的字符串问题和字符集问题，包括所用的字符串类型。假设无须更改代码就能维护这些字符串，怎样将这些字符串翻译为还有一种语言而又尽量不影响代码和用户界面。
十二、输入输出
架构应该具体定义读取策略是先做、后作还是即时做。并且应该描写叙述在那一层測I/O错误：在字段、记录、流，或者文件的层次。
十三、错误处理
错误处理已被证实为现代计算机科学中最棘手的问题之中的一个。错误处理牵连到整个系统，因此最好在架构层次上对待他。
1.错误处理是进行纠正还是只进行检測？假设是纠正，程序能够尝试从错误中恢复过来。
2.错误检測是主动的还是被动的？系统能够主动滴预測错误。
3.程序怎样传播错误？程序一旦检測到错误。它能够立马丢弃引发该错误的数据；也能够把这个错误当成一个错误，并进入错误处理状态。或者能够等到全部处理完毕，再通知用户说在某个地方发现了错误。
4.错误消息的处理有什么约定？假设架构没有具体定义一个一致的处理策略，那用户界面看起来很糟。
5.怎样处理异常？架构应该规定代码何时可以抛出异常，在什么地方捕获异常。怎样记录这些异常，以及怎样在文档中描写叙述异常，等等。
6.在程序中，在什么层次上处理错误？
7.每一个类在验证其输入数据的有效性方面须要负何种责任？
8.是希望执行环境中内建的错误处理机制。还是想建立自己的一套机制？
十四、容错性
架构还应该具体定义所期望的容错种类。容错是增强系统可靠性的一组技术，包含检測错误；假设可能的话从错误中恢复；假设不能从错误中恢复，则包容其不利影响。
十五、架构的可行性
设计师多半会关注系统的各种能力。比如是否达到性能目标，可以在有限的资源下运转，实现环境是否有足够的支持。
架构应该论证系统的技术可能性。假设在不论什么一个方面不可行都会导致项目无法实施，那么架构应该说明“这些问题是怎样经过研究的”——通过验证概念的原型、研究、或其它手段。必须在全面开展构建之前解决掉这些风险。
十六、过度project
健壮性是指“系统在检測到错误后继续执行”的能力。
通常架构具体描写叙述的系统会比需求描写叙述的系统更健壮。理由之中的一个是，假设组成系统的各个部分都仅仅在最低限度上满足健壮性要求，那么系统总体上是达不到所要求的健壮程度的。在软件中。链条的强度不是取决于最薄弱的一环，而是等于全部薄弱环节的乘积。架构应该清楚地指出程序猿应该“为了慎重起见宁可进行过度project”。还是应该做出最简单的能工作的东西。
具体定义一种过度project的方法尤其重要，由于很多程序猿会处于专业自豪感。对自己编写的类做过度project。
通过在架构中明白地设立期望目标。就能避免出现“某些类异常健壮。而其它类勉强够健壮”的现象。
十七、关于“买”还是“造”的决策
採购IP进行整合还是自己进行设计，都应该给出具体的分析。
十八、关于复用的决策
关于开发计划提倡使用已存在的软件、測试用例、数据歌会或其它原料。
架构应该说明：怎样对复用的软件进行加工，使之符合其它架构目标。
十九、变更策略
要面对开发过程中产品的变化，软件架构师所遇到的挑战是，让架构灵活，可以适应核能出现的变化。
架构应当清楚地描写叙述处理变更的策略。架构应该列出已经考虑过的有可能会有所增强的功能，并说明“最有肯能增强的功能相同也是最easy实现的”。假设变更非常可能出现输入输出格式、用户交互的风格、需求的处理等方面。那么架构就应该说明：这些变更已经被预料到了，而且不论什么单一的变更都仅仅会影响少数几个类。
二十、架构的整体质量
1、架构的目标应该清楚地表述。
2、架构应该描写叙述全部主要决策的动机。
3、优秀的软件架构非常大程度上是与机器和编程无关的。
4、架构应该踏在对系统”欠描写叙述“和”过度描写叙述“之间的那条分界线上。
5、架构应该明白地指出有风险的区域。他应该解释为什么这些区域是有风险的，并说明已经採取了哪些步骤以使风险最小化。
6、架构应该包括多个视角。
7、不应该担忧架构的不论什么部分。
它不应该不论什么对你而言非常难理解的东西。