演进的架构

作者：张克强    作者微博：张克强-敏捷307

本实践描写叙述重点在于演进，本文通过以下方面来说明“演进”的架构。

1， 架构的范围

2， 项目初次架构

3， 架构文档

4， 迭代中的架构

5。 推迟决策的架构

6， 其他说明

明白架构的范围

存在了有许很多多种架构，最著名的是与建筑和其他project相关的。甚至在软件project领域。我们常常会遇到不同形式的架构。比如，除了软件构架的概念，我们会遇到诸如企业架构，系统架构。组织架构，信息架构，硬件架构，应用架构，基础设施架构等，每种类型都定义了一个架构的详细范围。就算是在软件架构范畴下，眼下。软件业界并没有相互形式间的协定。所以导致了对软件架构同一词语的不同理解。软件开发架构考虑的范围随着不同项目、不同团队、项目的不同一时候间段而不同。

团队考虑进行架构时。值得首先就架构的范围进行讨论。并达成初步的共识，当然架构范围也不是从第一次达成共识后就不再变化。在架构演进时，团队能够就架构范围进行调整。

架构的范围并没有标准答案，以下是对于架构考虑范围的推荐。最推荐的给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？

另外可能变化方面是团队对于架构范围的理解可能变化，依据变化后的架构范围理解，增补架构文档的内容。

推迟决策的架构

在演进的架构中值得推迟决策，推迟决策并非指到最后才决定做什么,而是要尽量推迟冻结的决策,以更灵活的应对不确定性。

当出现架构决策时，考虑例如以下提问：

· 如今须要制定这个决策吗？

· 能够安全地推迟这一决策吗？

· 能做些什么使决策可逆？

· 能否够先进行些尝试，以帮助决策？

在演进的架构下，也为决策的推迟提供了便利。当前迭代涉及的架构问题是须要立即给出方案的，对于兴许的架构问题是有机会推迟决策的。当然这里是有长期考虑和短期考虑的权衡，并非说演进的架构下仅仅须要考虑本迭代的架构问题。但也不是说须要考虑全部兴许迭代的架构问题。

其他说明

在项目開始时，没有必要安排超过迭代周期的、专门的架构设计阶段或迭代。

在演进的背景下，预先花费大量时间的所谓设计阶段是多余的。

-------------------

本文同意在知识共享 署名-同样方式共享 3.0协议和GNU自由文档许可证下改动和再使用。