作者：张克强 作者微博：张克强-敏捷307
本实践描述重点在于演进，本文通过以下方面来说明“演进”的架构。
1， 架构的范围
2， 项目初次架构
3， 架构文档
4， 迭代中的架构
5， 推迟决策的架构
6， 其它说明
存在了有许许多多种架构，最著名的是与建筑和其他工程相关的。甚至在软件工程领域，我们经常会遇到不同形式的架构。例如，除了软件构架的概念，我们会遇到诸如企业架构，系统架构，组织架构，信息架构，硬件架构，应用架构，基础设施架构等，每种类型都定义了一个架构的具体范围。就算是在软件架构范畴下，目前，软件业界并没有相互形式间的协定，所以导致了对软件架构同一词语的不同理解。软件开发架构考虑的范围随着不同项目、不同团队、项目的不同时间段而不同。
团队考虑进行架构时，值得首先就架构的范围进行讨论，并达成初步的共识，当然架构范围也不是从第一次达成共识后就不再变化，在架构演进时，团队可以就架构范围进行调整。
架构的范围并没有标准答案，下面是对于架构考虑范围的推荐，最推荐的给5颗星，其次4、3、2。
· 支持的操作系统，比如 win7, Redhat9 ☆☆☆☆☆
· 支持的数据库 比如Oracle, DB2, Mysql ☆☆☆☆☆
· 支持的浏览器（如果是有Brower访问的）☆☆☆☆☆
· 依赖的运行时环境 --比如Java, Silverlight ☆☆☆☆☆
· 依赖的中间件--- 比如Java容器，tomcat, websphere, Tuxedo ☆☆☆☆☆
· 依赖的核心构件或者Frame, 比如struts, hibernate, 自定义的构件 ☆☆☆☆☆
· 层次划分，比如 典型三层架构、多层架构 ☆☆☆☆
· 识别进程，画部署图 ☆☆☆☆☆
· 划分组件，画组件图 ☆☆☆☆☆
· 开发语言 比如c#, java, c++ ☆☆☆☆☆
· 开发所用的工具 比如IDE，报表设计器 ☆☆☆☆
· 重要组件间的接口 ☆☆☆☆
· 核心类的设计 ☆☆☆
· 数据库设计 ☆☆☆ （存储数据和检索有其特点。在表达方面有其自身的特点。如数据集的提取，运算等, 要注意性能，完整性等。数据库设计也可做渐进设计）
· 核心流程的说明 ☆☆
· 部分核心类的类图 ☆☆
· 特别的性能要求带来的考虑 ☆☆☆☆
· 特别的可恢复性要求带来的考虑 ☆☆☆
· 特别的信息安全要求带来的考虑 ☆☆☆
一般而言，架构范围不包括需求细节、用户交互细节、类的细节。
项目很早的前期，比如第0次迭代，进行初次架构，团队需要理解项目的现状、范围、特征。
对于架构，需要了解在架构关注的范围内，哪些因素是硬性限制条件，哪些因素是可变限制条件，哪些因素是项目需要考虑解决的问题。一般地，全新开发项目的限制条件比较少，需要考虑解决的问题比较多。
所开发的系统将或者已经存在于环境中，那么其环境必然影响架构，所以需要考虑 “环境中的架构”。基本上，环境决定了系统运行的范围，这些又约定和限制了架构。影响架构的环境的因素包含架构所支持的商务环境，系统涉众群，内部技术限制（例如需要符合组织标准），和外部技术限制（例如对外部系统的接口或遵守外部规则的标准）。
在此期间，可以召开架构的头脑风暴会议，讨论系统的功能、性能等等特征，并思考实现这些特征的高层设计策略，甄别可行地技术策略。
根据这些了解、讨论和思考，形成初始的架构文档。
特别再次值得重复说明的是：多数的架构是在已有软件或系统上进行的。原有软件或系统将带来原有的架构，这并不意味着新项目可以不再考虑架构。原有的架构可能不再适应当前的情况，而恰恰是需要改进的地方；原有的架构也许非常好，不必修改，新开发只需要在其指定的架构下按部进行即可；原有的架构也许总体可以，局部需要调整。总之，需要了解原有的架构。
在起草初始的架构文档时，值得充分理解并复用原有架构方面的文档。
无论利用原有文档，还是新写，应当形成一套架构文档，说明团队架构范围内所关注的内容。这一套架构文档要得到配置管理。
这套架构文档的典型组成
1， 核心架构文档（必需）
2， 接口文档（可选）
3， 模块或子系统架构（可选）
4， 其它补充说明（可选）
在迭代进行中，核心架构设计文档始终保持是一个文件，这个文件随着种种新情况、变更而得到演进，但始终保持完整性和全局性。
避免出现把新增修改的内容写入特定版本号的架构文档，进而导致组合多个文件才能反映架构整体情况。具体而言，避免如下情况：
假设在第2个迭代结束后已经 形成了 ABC架构文档，在第3个迭代时，其中某部分有重要修改， 团队为了明确这些是第3迭代的任务，也为方便的阅读第3迭代的架构，把这部分修改另写为第3迭代架构文件。在第4个迭代时，又有某部分需要新增修改，然后有出现了第4迭代架构文件，依此类推，到第10个迭代时，需要阅读所有前面的架构文件才能了解全局，而不再有一份核心架构文档就能反映全局。短期迭代的方便处理将损害长期的架构演进。
因此，演进的架构建议利用版本控制工具（比如CVS，SVN，ClearCase等）来管理架构文档。
在项目进行的任何时间点，都能展现及时的一套架构文档。
在后续的迭代中，在每个迭代的前期，考虑对于架构的影响，如果对于原有架构文档有变化，就应当修订架构文档。在演进中，对于架构最常见的两大影响是1，模块的修改和新增；2由于时间推移所带来的容量方面的问题，一般最突出的是性能问题。值得密切注意模块之间的交互
推荐提问：
1， 这个迭代是否要新增模块？
2， 是否对已经存在的模块有修改，模块之间的交互是否有变化？
3， 与其它系统的交互是否有变化？是否需要与新系统通讯？
4， 是否能够支持容量方面的情况？比如访问量？比如硬盘容量？带宽？CPU？
另外可能变化方面是团队对于架构范围的理解可能变化，根据变化后的架构范围理解，增补架构文档的内容。
在演进的架构中值得推迟决策，推迟决策并不是指到最后才决定做什么,而是要尽量推迟冻结的决策,以更灵活的应对不确定性。
当出现架构决策时，考虑如下提问：
· 现在需要制定这个决策吗？
· 可以安全地推迟这一决策吗？
· 能做些什么使决策可逆？
· 是否可以先进行些尝试，以帮助决策？
在演进的架构下，也为决策的推迟提供了便利。当前迭代涉及的架构问题是需要马上给出方案的，对于后续的架构问题是有机会推迟决策的。当然这里是有长期考虑和短期考虑的权衡，并不是说演进的架构下只需要考虑本迭代的架构问题，但也不是说需要考虑所有后续迭代的架构问题。
在项目开始时，没有必要安排超过迭代周期的、专门的架构设计阶段或迭代。
在演进的背景下，预先花费大量时间的所谓设计阶段是多余的。
-------------------
原文地址：http://blog.csdn.net/zhangmike/article/details/38105329
