学步园

第一部分  软件架构概念与思想篇 1
第1章  解析软件架构概念 3
1.1  软件架构概念的分类 3
1.1.1  组成派 4
1.1.2  决策派 5
1.2  软件架构概念大观 5
1.2.1  Booch、Rumbaugh和Jacobson的定义 5
1.2.2  Woods的观点 6
1.2.3  Garlan和Shaw的定义 6
1.2.4  Perry和Wolf的定义 6
1.2.5  Boehm的定义 6
1.2.6  IEEE的定义 6
1.2.7  Bass的定义 6
1.3  软件架构关注分割与交互 7
1.4  软件架构是一系列有层次性的决策 8
1.5  PM Tool案例：领会软件架构概念 10
1.5.1  案例故事 10
1.5.2  软件架构概念的体现 12
1.5.3  重要结论 14
1.6  总结与强调 14
第2章  子系统、框架与架构 15
2.1  子系统和框架在架构设计中的地位 16
2.1.1  关注点分离之道 16
2.1.2  子系统和框架在架构设计中的地位 17
2.2  子系统与软件架构 19
2.2.1  不同粒度的软件单元 20
2.2.2  子系统也有架构 21
2.2.3  子系统不同，架构不同 21
2.2.4  不同实践者眼中的粒度 23
2.3  框架与软件架构 23
2.3.1  框架的概念 23
2.3.2  架构和框架的区别 24
2.3.3  架构和框架的联系 25
2.3.4  框架也有架构 26
2.4  超越概念：立足实践理解架构 26
2.4.1  理解架构 26
2.4.2  回到实践 28
2.5  专题：框架技术 29
2.5.1  框架vs.类库 29
2.5.2  框架的分类 30
2.5.3  框架的开发过程 32
2.5.4  如何实现框架中的扩展点 33
2.6  总结与强调 36
第3章  软件架构的作用 37
3.1  充分发挥软件架构的作用 37
3.2  软件架构对新产品开发的作用 38
3.3  软件架构对软件产品线开发的作用 40
3.4  软件架构对软件维护的作用 42
3.5  软件架构重构 42
3.6  总结与强调 43

第二部分  软件架构设计方法与过程篇 45
第4章  软件架构视图 47
4.1  呼唤软件架构视图 47
4.1.1  办公室里的争论 48
4.1.2  呼唤软件架构视图 48
4.2  软件架构为谁而设计 49
4.2.1  为用户而设计 49
4.2.2  为客户而设计 50
4.2.3  为开发人员而设计 50
4.2.4  为管理人员而设计 51
4.2.5  总结 51
4.3  引入软件架构视图 52
4.3.1  生活中的“视图”运用 53
4.3.2  什么是软件架构视图 54
4.3.3  多组涉众，多个视图 54
4.4  实践指南：逻辑架构与物理架构 55
4.4.1  逻辑架构 56
4.4.2  物理架构 57
4.4.3  从逻辑架构和物理架构到设计实现 58
4.5  设备调试系统案例：领会逻辑架构和物理架构 59
4.5.1  设备调试系统案例简介 59
4.5.2  逻辑架构设计 59
4.5.3  物理架构设计 61
4.6  总结与强调 62
第5章  架构设计的5视图法 63
5.1  架构设计的5视图法 64
5.2  实践中的5视图方法 66
5.3  办公室里的争论：回顾与落实 67
5.4  案例：再谈设备调试系统 67
5.4.1  根据需求决定引入哪些架构视图 68
5.4.2  开发架构设计 68
5.4.3  运行架构设计 69
5.5  总结与强调 71
第6章  从概念性架构到实际架构 73
6.1  概念性架构 73
6.2  实际架构 77
6.3  从概念性架构到实际架构 78
6.4  网络管理系统案例：从分层架构开始 78
6.4.1  构思：概念性架构设计 78
6.4.2  深入：实际架构设计 81
6.5  总结与强调 82
第7章  如何进行成功的架构设计 83
7.1  何谓成功的软件架构设计 83
7.2  探究成功架构设计的关键要素 84
7.2.1  是否遗漏了至关重要的非功能需求 84
7.2.2  能否驯服数量巨大且频繁变化的需求 86
7.2.3  能否从容设计软件架构的不同方面 86
7.2.4  是否及早验证架构方案并做出了调整 87
7.3  制定软件架构设计策略 87
7.3.1  策略一：全面认识需求 88
7.3.2  策略二：关键需求决定架构 89
7.3.3  策略三：多视图探寻架构 89
7.3.4  策略四：尽早验证架构 90
7.4  总结与强调 90
第8章  软件架构要设计到什么程度 93
8.1  软件架构要设计到什么程度 94
8.1.1  分而治之的两种方式 94
8.1.2  架构设计与详细设计 96
8.1.3  软件架构是团队开发的基础 96
8.1.4  架构设计要进行到什么程度 98
8.2  高来高去式架构设计的症状 98
8.2.1  缺失重要架构视图 99
8.2.2  浅尝辄止、不够深入 100
8.2.3  名不副实的分层架构 101
8.3  如何克服高来高去症 101
8.4  网络管理系统案例：如何将架构设计落到实处 102
8.4.1  网管产品线的概念性架构 102
8.4.2  识别每一层中的功能模块 102
8.4.3  明确各层之间的交互接口 103
8.4.4  明确各层之间的交互机制 104
8.4.5  案例小结 105
8.5  总结与强调 105
第9章  软件架构设计过程 107
9.1  打造有效的架构设计过程 107
9.1.1  一般的软件过程 107
9.1.2  架构师自己的架构设计过程 109
9.2  软件架构设计过程解析 111
9.2.1  架构设计策略应成为一等公民 111
9.2.2  架构设计过程中的工作产品 112
9.3  总结与强调 114
第10章  需求分析 115
10.1  软件需求基础 116
10.1.1  什么是软件需求 116
10.1.2  需求捕获vs.需求分析vs.系统分析 116
10.1.3  需求捕获及其工作成果 118
10.1.4  需求分析及其工作成果 118
10.1.5  系统分析及其工作成果 119
10.2  需求分析在软件过程中所处的位置 120
10.2.1  概念化阶段所做的工作 120
10.2.2  需求分析所处的位置 122
10.3  架构师必须掌握的需求知识 123
10.3.1  软件需求的类型 123
10.3.2  各类需求对架构设计的不同影响 127
10.3.3  超市系统案例：领会需求类型的不同影响 129
10.3.4  各类需求的“易变更性”不同 130
10.3.5  质量属性需求与需求折衷 132
10.4  PM Tool实战：需求分析 135
10.4.1  上游活动：确定项目愿景 135
10.4.2  第1步：从业务目标到特性列表 135
10.4.3  第2步：从特性列表到用例图 136
10.4.4  第3步：从用例图到用例规约 138
10.4.5  需求启发与需求验证 139
10.4.6  最终成果：《软件需求规格说明书》 140
10.5  总结与强调 141
第11章  专题：用例技术及应用 143
11.1  用例图vs.用例简述vs.用例规约vs.用例实现 143
11.2  储蓄系统案例：需求变化对用例的影响 148
11.3  用例技术应用指南 150
11.4  用例与需求捕获 152
11.5  用例与需求分析 153
11.6  用例与《软件需求规格说明书》 154
11.7  总结与强调 155
第12章  领域建模 157
12.1  领域模型基础知识 157
12.1.1  什么是领域模型 158
12.1.2  领域模型相关的UML图 158
12.2  领域建模在软件过程中所处的位置 159
12.2.1  领域建模的必要性：从需求分析的两个典型困难说起 159
12.2.2  领域建模与需求分析的关系 161
12.2.3  领域建模所处的位置 162
12.3  领域模型对软件架构的重要作用 163
12.3.1  配置管理工具案例：探索复杂问题、固化领域知识 163
12.3.2  人事管理系统案例：决定功能范围、影响可扩展性 165
12.3.3  在线拍卖系统案例：提供交流基础、促进有效沟通 168
12.4  领域模型 vs. 文字说明 170
12.5  PM Tool实战：建立项目管理的领域模型 171
12.5.1  领域建模实录（1） 171
12.5.2  领域建模实录（2） 174
12.6  总结与强调 176
第13章  确定对软件架构关键的需求 177
13.1  虚拟高峰论坛：穷兵黩武还是择战而斗 177
13.1.1  需求是任何促成设计决策的因素 178
13.1.2  很少有开发者能奢侈地拥有一个稳定的需求集 178
13.1.3  关键性的第一步是缩小范围 178
13.1.4  要择战而斗 178
13.1.5  功能、质量和商业需求的某个集合塑造了构架 179
13.2  关键需求决定架构 179
13.2.1  实践中的常见问题 179
13.2.2  关键需求决定架构 181
13.3  确定关键需求在软件过程中所处的位置 182
13.3.1  对架构关键的需求vs.需求优先级 182
13.3.2  关键需求对后续活动的影响 183
13.4  什么是对软件架构关键的需求 184
13.4.1  关键的功能需求 184
13.4.2  关键的质量属性需求 185
13.4.3  关键的商业需求 186
13.5  如何确定对软件架构关键的需求 187
13.5.1  全面整理需求 188
13.5.2  分析约束性需求 188
13.5.3  确定关键功能需求 189
13.5.4  确定关键质量属性需求 190
13.6  PM Tool实战：确定关键需求 190
13.7  总结与强调 191
第14章  概念性架构设计 193
14.1  概念性架构设计的步骤 194
14.2  鲁棒性分析 195
14.2.1  分析和设计之间的鸿沟 195
14.2.2  鲁棒图简介 196
14.2.3  从用例到鲁棒图 197
14.3  运用架构模式 198
14.3.1  架构模式简介 198
14.3.2  架构模式的经典分类 199
14.3.3  架构模式的现代分类 200
14.3.4  分层 201
14.3.5  MVC 201
14.3.6  微内核 202
14.3.7  基于元模型的架构 203
14.3.8  管道—过滤器 204
14.4  PM Tool实战：概念性架构设计 204
14.4.1  进行鲁棒性分析 204
14.4.2  引入架构模式 206
14.4.3  质量属性分析 207
14.4.4  设计结果 207
14.5  总结与强调 208
第15章  质量属性分析 209
15.1  质量属性需求基础 210
15.2  质量属性分析的位置 211
15.3  利用“属性—场景—决策”表设计架构决策 211
15.3.1  概述 211
15.3.2  “属性—场景—决策”表方法 212
15.3.3  题外话：《需求文档》如何定义质量属性需求 214
15.4  PM Tool实战：可扩展性设计 214
15.5  总结与强调 215
第16章  细化架构设计 217
16.1  架构细化在软件过程中所处的位置 218
16.1.1  我们走到哪了 218
16.1.2  运用基于5视图方法进行架构细化 219
16.2  设计逻辑架构 220
16.2.1  概述 220
16.2.2  识别通用机制 220
16.3  设计开发架构 223
16.3.1  概述 223
16.3.2  分层和分区 223
16.4  设计数据架构 226
16.4.1  概述 226
16.4.2  如何将OO模型映射为数据模型 227
16.5  设计运行架构 229
16.5.1  概述 229
16.5.2  运用主动类规划并发 230
16.5.3  应用协议的设计 234
16.6  设计物理架构 234
16.6.1  概述 234
16.7  注意满足所有约束性软件需求 235
16.8  PM Tool实战：细化架构设计 236
16.9  总结与强调 239
第17章  实现并验证软件架构 241
17.1  基础知识 242
17.1.1  原型技术及分类 242
17.1.2  验证架构的两种方法 245
17.2  实现并验证软件架构的具体做法 245
17.3  总结与强调 247

第三部分  程序员成长篇 249
第18章  MIME编码类案例： 从面向过程到面向对象 251
18.1  设计目标 251
18.2  MIME编码基础知识 252
18.3  MIME编码类的设计过程 252
18.3.1  面向过程的设计方案 252
18.3.2  转向面向对象设计 254
18.3.3  面向对象设计方案的确定 257
18.3.4  Template Method和Strategy模式的对比 260
第19章  突破OOP思维：继承在OOD中的应用 261
19.1  从一则禅师语录说起 261
19.1.1  见继承是继承——程序员境界 262
19.1.2  见继承不是继承——成长境界 262
19.1.3  见继承只是继承——设计师境界 262
19.2  从OOD层面认识继承 262
19.3  针对接口编程——隔离变化 263
19.3.1  相关理论 263
19.3.2  针对接口编程举例——用于架构设计 263
19.3.3  针对接口编程举例——用于类设计 265
19.4  混入类——更好的重用性 266
19.4.1  相关理论 266
19.4.2  混入类举例 266
19.5  基于角色的设计——使用角色组装协作 267
19.5.1  相关理论 267
19.5.2  基于角色的设计举例 268
第20章  细微见真章：耦合其实并不空洞 269
20.1  顺序耦合性简介 269
20.2  案例研究：顺序耦合性Bug一例 269
20.2.1  项目简介 270
20.2.2  新的需求 270
20.2.3  发现顺序耦合性Bug 271
20.2.4  跟踪调试 271
20.2.5  分析原因 273
20.2.6  解决策略 273
20.2.7  运用重构的“Extract Method”成例 273
20.2.8  运用重构的“Hide Method”成例 274
20.2.9  运用重构的“Introduce Parameter Object”成例 274
20.2.10  其他改进 274
第21章  敏捷设计：从理论到实践 277
21.1  换个角度考察依赖 278
21.1.1  依赖的概念 278
21.1.2  从会不会造成“实际危害”的角度考察依赖 278
21.2  良性依赖原则 278
21.2.1  依赖是不可避免的 278
21.2.2  重要的是如何务实地应付变化 279
21.3  案例：需求改变引起良性依赖变成恶性依赖 279
21.4  案例：隔离第三方SDK可能造成的冲击 281
21.5  案例：对具体类的良性依赖 283
21.6  总结：如何处理好依赖关系 285
第22章  基于角色的设计：从理论到实践 287
22.1  基于角色的设计理论 288
22.2  基于角色的设计与团队开发 288
22.3  基于角色的设计实践 289
22.4  基于角色的设计案例 291
22.4.1  项目简介 291
22.4.2  通过基于角色的设计组织子系统之间的协作 291
22.4.3  通过基于角色的设计组织同一子系统内不同模块之间的协作 292
22.5  基于角色的设计与面向对象分析 293
第23章  超越设计模式：理解和运用更多模式 295
23.1  关于模式的两个问题 295
23.2  模式的正交分类法 296
23.2.1  正交思维 296
23.2.2  正交思维用于模式分类 297
23.3  专攻性能：性能模式简介 299
23.4  模型驱动开发的方方面面：MDD模式简介 301
23.5  总结：拥抱模式 302
第24章  如此轻松：立足图论学UML 303
24.1  管窥UML中的OO思想 304
24.1.1  一道笔试题的故事 304
24.1.2  UML背后的思想 305
24.2  图的定义与UML应用 306
24.2.1  图的定义 306
24.2.2  图的定义的UML应用——UML的图论观点 307
24.2.3  图的定义的UML应用——关联类语法的理解 308
24.2.4  图的定义的UML应用——说说序列图 309
24.3  有向边与UML应用 310
24.3.1  有向边 310
24.3.2  有向边的UML应用——依赖关系 310
24.3.3  有向边的UML应用——泛化、实现和关联的依赖思想 312
24.3.4  有向边的UML应用——一个例子 312
24.4  着色顶点与UML应用 313
24.4.1  着色顶点 313
24.4.2  着色顶点的UML应用——通过颜色为图元分类 314
24.4.3  着色顶点的UML应用——UML彩色建模方法介绍 315
24.5  着色边与UML应用 317
24.6  图的同构与UML应用 317
24.6.1  图的同构 317
24.6.2  图的同构的UML应用——UML风格 318
第25章  理解软件过程：解析RUP核心概念 321
25.1  架构师必须了解软件过程 321
25.1.1  架构师的工作职责 321
25.1.2  架构师必须了解软件过程 322
25.2  RUP实践中的常见问题 322
25.3  RUP核心概念解析 323
25.3.1  一图胜千言 323
25.3.2  角色执行活动，活动生产工件 323
25.3.3  阶段和迭代：提供不同级别的决策时机 324
25.3.4  配置和变更管理支持迭代式的基于基线的开发 326
25.3.5  发布是什么，发布不是什么 327
第26章  海阔凭鱼跃：通盘理解软件工程 329
26.1  什么是软件工程概念模型 329
26.2  一个精简的软件工程概念模型 329
26.3  一个细化的软件工程概念模型 330
26.3.1  模型概述 331
26.3.2  方法论 331
26.3.3  过程 331
26.3.4  目标 332
26.3.5  项目 332
26.3.6  其他 333
26.4  软件工程概念模型的具体应用 333
26.4.1  搞清楚Agile是过程还是方法论 333
26.4.2  为CMM定位 334
26.4.3  理解RUP定制 335
26.5  总结：软件工程概念模型的启示 335
26.5.1  软件工程，一门实践的科学 335
26.5.2  软件过程，合适的才是最好的 336
26.5.3  对个人的启示 336
26.5.4  呼唤高层次人才 336

参考文献 337

如何设计架构？

Part 1 层
　　层（layer）这个概念在计算机领域是非常了不得的一个概念。计算机本身就体现了一种层的概念：系统调用层、设备驱动层、操作系统层、CPU指令集。每个层都负责自己的职责。网络同样也是层的概念，最著名的OSI的七层协议。

　　层到了软件领域也一样好用。为什么呢？我们看看使用层技术有什么好处：

　　● 你使用层，但是不需要去了解层的实现细节。
　　● 可以使用另一种技术来改变基础的层，而不会影响上面的层的应用。
　　● 可以减少不同层之间的依赖。
　　● 容易制定出层标准。
　　● 底下的层可以用来建立顶上的层的多项服务。 当然，层也有弱点：

　　● 层不可能封装所有的功能，一旦有功能变动，势必要波及所有的层。
　　● 效率降低。

　　当然，层最难的一个问题还是各个层都有些什么，以及要承担何种责任。

典型的三层结构

　　三层结构估计大家都很熟悉了。就是表示（presentation）层, 领域（domain）层, 以及基础架构（infrastructure）层。

　　表示层逻辑主要处理用户和软件的交互。现在最流行的莫过于视窗图形界面（wimp）和基于html的界面了。表示层的主要职责就是为用户提供信息，以及把用户的指令翻译。传送给业务层和基础架构层。 基础架构层逻辑包括处理和其他系统的通信，代表系统执行任务。例如数据库系统交互，和其他应用系统的交互等。大多数的信息系统，这个层的最大的逻辑就是存储持久数据。

　　还有一个就是领域层逻辑，有时也被叫做业务逻辑。它包括输入和存储数据的计算。验证表示层来的数据，根据表示层的指令指派一个基础架构层逻辑。

　　领域逻辑中，人们总是搞不清楚什么事领域逻辑，什么是其它逻辑。例如，一个销售系统中有这样一个逻辑：如果本月销售量比上个月增长10％，就要用红色标记。要实现这个功能，你可能会把逻辑放在表示层中，比较两个月的数字，如果超出10％，就标记为红色。

　　这样做，你就把领域逻辑放到了表示层中了。要分离这两个层，你应该现在领域层中提供一个方法，用来比较销售数字的增长。这个方法比较两个月的数字，并返回boolean类型。表示层则简单的调用该方法，如果返回true，则标记为红色。

例子

　　层技术不存在说永恒的技巧。如何使用都要看具体的情况才能够决定，下面我就列出了三个例子：

　　例子1：一个电子商务系统。要求能够同时处理大量用户的请求，用户的范围遍及全球，而且数字还在不断增长。但是领域逻辑很简单，无非是订单的处理，以及和库存系统的连接部分。这就要求我们1、表示层要友好，能够适应最广泛的用户，因此采用html技术；2、支持分布式的处理，以胜任同时几千的访问；3、考虑未来的升级。

　　例子2：一个租借系统。系统的用户少的多，但是领域逻辑很复杂。这就要求我们制作一个领域逻辑非常复杂的系统，另外，还要给他们的用户提供一个方便的输入界面。这样，wimp是一个不错的选择。

　　例子3：简单的系统。非常简单，用户少、逻辑少。但是也不是没有问题，简单意味着要快速交付，并且还要充分考虑日后的升级。因为需求在不断的增加之中。

何时分层

　　这样的三个例子，就要求我们不能够一概而论的解决问题，而是应该针对问题的具体情况制定具体的解决方法。这三个例子比较典型。

　　第二个例子中，可能需要严格的分成三个层次，而且可能还要加上另外的中介（mediating）层。例3则不需要，如果你要做的仅是查看数据，那仅需要几个server页面来放置所有的逻辑就可以了。

　　我一般会把表示层和领域层/基础架构层分开。除非领域层/基础架构层非常的简单，而我又可以使用工具来轻易的绑定这些层。这种两层架构的最好的例子就是在VB、PB的环境中，很容易就可以构建出一个基于SQL数据库的windows界面的系统。这样的表示层和基础架构层非常的一致，但是一旦验证和计算变得复杂起来，这种方式就存在先天缺陷了。

　　很多时候，领域层和基础架构层看起来非常类似，这时候，其实是可以把它们放在一起的。可是，当领域层的业务逻辑和基础架构层的组织方式开始不同的时候，你就需要分开二者。

更多的层模式

　　三层的架构是最为通用的，尤其是对IS系统。其它的架构也有，但是并不适用于任何情况。

　　第一种是Brown model [Brown et al]。它有五个层：表示层（Presentation），控制/中介层（Controller/Mediator），领域层（Domain）, 数据映射层（Data Mapping）, 和数据源层（Data Source）。它其实就是在三层架构种增加了两个中间层。控制/中介层位于表示层和领域层之间，数据映射层位于领域层和基础架构层之间。

　　表示层和领域层的中介层，我们通常称之为表示-领域中介层，是一个常用的分层方法，通常针对一些非可视的控件。例如为特定的表示层组织信息格式，在不同的窗口间导航，处理交易边界，提供Server的facade接口（具体实现原理见设计模式）。最大的危险就是，一些领域逻辑被放到这个层里，影响到其它的表示层。

　　我常常发现把行为分配给表示层是有好处的。这可以简化问题。但表示层模型会比较复杂，所以，把这些行为放到非可视化的对象中，并提取出一个表示-领域中介层还是值得的。

　　Brown ISA
　　表示层 表示层
　　控制/中介层 表示-领域中介层
　　领域层 领域层
　　数据映射层 数据库交互模式中的Database Mapper
　　数据源层 基础架构层

　　领域层和基础架构层之间的中介层属于本书中提到的Database Mapper模式，是三种领域层到数据连接的办法之一。和表示-领域中介层一眼，有时候有用，但不是所有时候都有用。

　　还有一个好的分层架构是J2EE的架构，这方面的讨论可以见『J2EE核心模式』一书。他的分层是客户层（Client），表示层（Presentation），业务层（Business ），整合层（Integration），资源层（Resource）。差别如下图：

　　J2EE核心 ISA
　　客户层 运行在客户机上的表示层
　　表示层 运行在服务器上的表示层
　　业务层 领域层
　　整合层 基础架构层
　　资源层 基础架构层通信的外部数据

　　微软的DNA架构定义了三个层：表示层（presentation），业务层（business），和数据存储层（data access），这和我的架构相似，但是在数据的传递方式上还有很大的不同。在微软的DNA中，各层的操作都基于数据存储层传出的SQL查询结果集。这样的话，实际上是增加了表示层和业务层同数据存储层之间的耦合度。 DNA的记录集在层之间的动作类似于Data Transfer Object。

Part 2 组织领域逻辑

　　要组织基于层的系统，首要的是如何组织领域逻辑。领域逻辑的组织有好几种模式。但其中最重要的莫过于两种方法：Transation Script和Domain Model。选定了其中的一种，其它的都容易决定。不过，这两者之间并没有一条明显的分界线。所以如何选取也是门大学问。一般来说，我们认为领域逻辑比较复杂的系统可以采用Domain Model。

　　Transation Script就是对表示层用户输入的处理程序。包括验证和计算，存储，调用其它系统的操作，把数据回传给表示层。用户的一个动作表示一个程序，这个程序可以是script，也可以是transation，也可以是几个子程序。在例子1中，检验，在购物车中增加一本书，显示递送状态，都可以是一个Transation Script。

　　Domain Model是要建立对应领域名词的模型，例如例1中的书、购物车等。检验、计算等处理都放到领域模型中。

　　Transation Script属于结构性思维，Domain Model属于OO思维。Domain Model比较难使用，一旦习惯，你能够组织更复杂的逻辑，你的思想会更OO。到时候，即使是小的系统，你也会自然的使用Domain Model了。

　　但如何抉择呢？如果逻辑复杂，那肯定用Domain Model：如果只需要存取数据库，那Transation Script会好一些。但是需求是在不断进化的，你很难保证以后的需求还会如此简单。如果你的团队不善于使用Domain Model，那你需要权衡一下投入产出比。另外，即使是Transation Script，也可以做到把逻辑和基础架构分开，你可以使用Gateway。

　　对例2，毫无疑问要使用Domain Model。对例1就需要权衡了。而对于例3，你很难说它将来会不会像例2那样，你现在可以使用Transation Script，但未来你可能要使用Domain Model。所以说，架构的决策是至关紧要的。

　　除了这两种模式，还有其它中庸的模式。Use Case Controller就是处于两者之间。只有和单个的用例相关的业务逻辑才放到对象中。所以大致上他们还是在使用Transation Script，而Domain Model只是Database Gateway的一组集合而已。我不太用这种模式。

　　Table Module是另一个中庸模式。很多的GUI环境依托于SQL查询的返回结果。你可以建立内存中的对象，来把GUI和数据库分开来。为每个表写一个模块，因此每一行都需要关键字变量来识别每一个实例。

　　Table Module适用于很多的组件构建于一个通用关系型数据库之上，而且领域逻辑不太复杂的情况。Microsoft COM 环境，以及它的带ADO.NET的.NET环境都适合使用这种模式。而对于Java，就不太适用了。

　　领域逻辑的一个问题是领域对象非常的臃肿。因为对象的行为太多了，类也就太大了。它必须是一个超集。这就要考虑哪些行为是通用的，哪些不是，可以由其它的类来处理，可能是Use Case Controller，也可能是表示层。

　　还有一个问题，复制。他会导致复杂和不一致。这比臃肿的危害更大。所以，宁可臃肿，也不要复制。等到臃肿为害时再处理它吧。

选择一个地方运行领域逻辑

　　我们的精力集中在逻辑层上。领域逻辑要么运行在Client上，要么运行在Server上。

　　比较简单的做法是全部集中在Server上。这样你需要使用html的前端以及web server。这样做的好处是升级和维护都非常的简单，你也不用考虑桌面平台和Server的同步问题，也不用考虑桌面平台的其它软件的兼容问题。

　　运行在Client适合于要求快速反应和没有联网的情况。在Server端的逻辑，用户的一个再小的请求，也需要信息从Client到Server绕一圈。反应的速度必然慢。再说，网络的覆盖程度也不是说达到了100％。

　　对于各个层来说，又是怎么样的呢？

　　基础架构层：一般都是在Server啦，不过有时候也会把数据复制到合适的高性能桌面机，但这是就要考虑同步的问题了。

　　表示层在何处运行取决于用户界面的设计。一个Windows界面只能在Client运行。而一个Web界面就是在Server运行。也有特别的例子，在桌面机上运行web server的，例如X Server。但这种情况少的多。

　　在例1中，没有更多的选择了，只能选在Server端。因此你的每一个bit都会绕一个大圈子。为了提高效率，尽量使用一些纯html脚本。

　　人们选用Windows界面的原因主要就是需要执行一些非常复杂的任务，需要一个合适的应用程序，而web GUI则无法胜任。这就是例2的做法。不过，人们应该会渐渐适应web GUI，而web GUI的功能也会越来越强大。

　　剩下的是领域逻辑。你可以全部放在Server，也可以全部放在Client，或是两边都放。

　　如果是在Client端，你可以考虑全部逻辑都放在Client端，这样至少保证所有的逻辑都在一个地方。而把web server移至Client，是可以解决没有联网的问题，但对反应时间不会有多大的帮助。你还是可以把逻辑和表示层分离开来。当然，你需要额外的升级和维护的工作。

　　在Client和Server端都具有逻辑并不是一个好的处理办法。但是对于那些仅有一些领域逻辑的情况是适用的。有一个小窍门，把那些和系统的其它部分没有联系的逻辑封装起来。 领域逻辑的接口

　　你的Server上有一些领域逻辑，要和Client通信，你应该有什么样的接口呢？要么是一个http接口，要么是一个OO接口。

　　http接口适用于web browser，就是说你要选择一个html的表示层。最近的新技术就是web service，通过基于http、特别是XML进行通信。XML有几个好处：通信量大，结构好，仅需一次的回路。这样远程调用的的开销就小了。同时，XML还是一个标准，支持平台异构。XML又是基于文本的，能够通过防火墙。

　　虽然XML有那么多的好处，不过一个OO的接口还是有它的价值的。hhtp的接口不明显，不容易看清楚数据是如何处理的。而OO的接口的方法带有变量和名字，容易看出处理的过程。当然，它无法通过防火墙，但可以提供安全和事务之类的控制。

　　最好的还是取二者所长。OO接口在下，http接口在上。但这样做就会使得实现机制非常的复杂。

Part 3 组织web Server

　　很多使用html方式的人，并不能真正理解这种方式的优点。我们有各种各样好用的工具，但是却搞到让程序难以维护。

　　在web server上组织程序的方式大致可以分为两种：脚本和server page。

　　脚本方式就是一个程序，用函数和方法来处理http调用。例如CGI脚本和java servlet。它和普通的程序并没有什么两样。它从web页面上获得html string形态的数据，有时候还要做一些表达式匹配，这正是perl能够成为CGI脚本的常用语言的原因。而java servelet则是把这种分析留给程序员，但它允许程序员通过关键字接口来访问信息，这样就会少一些表达式的判断。这种格式的web server输出是另一种html string，称为response，可以通过流数据来操作。

　　糟糕的是流数据是非常麻烦的，因此就导致了server page的产生，例如PHP，ASP，JSP。

　　server page的方式适合回应（response）的处理比较简单的情况。例如“显示歌曲的明细”，但是你的决策取决于输入的时候，就会比较杂乱。例如“通俗和摇滚的显示格式不同”。

　　脚步擅长于处理用户交互，server page擅长于处理格式化回应信息。所以很自然的就会采用脚本处理请求的交互，使用server page处理回应的格式化。这其实就是著名的MVC（Model View Controller）模式中的view/controller的处理。

web server端的MVC工作流程示意图

　　应用Model View Controller模式首要的一点就是模型要和web服务完全分离开来。使用Transaction Script或Domain Model模式来封装处理流程。

　　接下来，我们就把剩余的模式归入两类模式中：属于Controller的模式，以及属于View的模式。

View模式

　　View这边有三种模式：Transform View，Template View和Two Step View。Transform View和Template View的处理只有一步，将领域数据转换为html。Two Step View要经过两步的处理，第一步把领域数据转换为逻辑表示形式，第二步把逻辑表示转换为html。

　　两步处理的好处是可以将逻辑集中于一处，如果只有一步，变化发生时，你就需要修改每一个屏幕。但这需要你有一个很好的逻辑屏幕结构。如果一个web应用有很多的前端用户时，两步处理就特别的好用。例如航空订票系统。使用不同的第二步处理，就可以获得不同的逻辑屏幕。

　　使用单步方法有两个可选的模式：Template View，Transform View。Template View其时就是把代码嵌入到html页面中，就像现在的server page技术，如ASP，PHP，JSP。这种模式灵活，强大，但显得杂乱无章。如果你能够把逻辑程序逻辑在页面结构之外进行很好的组织，这种模式还是有它的优点的。

　　Transform View使用翻译方式。例如XSLT。如果你的领域数据是用XML处理的，那这种模式就特别的好用。

Controller模式

　　Controller有两种模式。一般我们会根据动作来决定一项控制。动作可能是一个按钮或链接。所这种模式就是Action Controller模式。

　　Front Controller更进一步，它把http请求的处理和处理逻辑分离开来。一般是只有一个web handle来处理所有的请求。你的所有的http请求的处理都由一个对象来负责。你改变动作结构的影响就会降到最小。  

axing（转载自www.Linuxaid.com.cn）　　2003年05月04日

如何从开发人员走向架构师

很多架构师都是从好的开发人员逐步过渡而来的，但并非每个好的开发人员都希望成为架构师，而且他们并不是都适合做架构师。无论您是打算进行职业转型的开发人员，还是寻找能承担体系结构设计责任的合适人选的经理，都务必对此转型过程有个清楚的了解。本文将讨论从实现专家到架构师的过渡过程。

 

　　在寻找优秀的指挥的时候，您首先要找的是一名优秀的音乐演奏家。但并非每个音乐演奏家都能成为优秀的指挥。架构师的专业发展方面也与此类似。越来越多的 IT 组织开始认识到良好软件体系结构的重要性，架构师职业正迅速发展为 IT 内一个独立的门类。由于要从相当小的候选范围内招募架构师，因此这就给管理带来了一些新挑战。即使人力资源部门找到了候选者，针对经验进行的筛选也比其他门类更为严格。跨越这些障碍的最快方式是要认识到，大部分好的架构师同时也是好的开发人员，因此寻找架构师人才时可能首先应该从普通开发人员中找起。招聘人员在对候选者(内部或外部)进行详细审查时，应该考虑这个观点。不过，对此资源进行挑选可能比较麻烦，因为只有极少的优秀开发人员具有成为架构师的特征或愿望。

　　本文列出了开发人员成为架构师要进行的工作。我将从可能考虑进行此转型的开发人员和评估进行此转型的开发人员的经理这两个方面来探讨这一问题。我还将提供一系列在做出这些决策时要考虑的因素。

　　个人特征

　　软件开发团队和管理层之间的联系始终是 IT 中的一个关键所在。二者都倾向于以完全不同的方式考虑给定的问题。大部分相关技术都是讨论项目经理应如何跟踪和解释开发人员的进度和问题。但沟通不足的情况仍然非常普遍，而且这是项目失败的首要原因。好的架构师是解决这个问题的最有效办法。架构师的主要责任是提供开发人员和项目经理之间的共用沟通媒体。他们负责让业务规则及需求与工程实践及限制相适应，以确保成功。以下是成功架构师的一些主要特征。

　　愿意并有能力进行沟通：在开发人员中发现架构师的最有价值标准是有效的沟通。您需要技术娴熟、经验丰富的开发人员，这样的人员需要有就项目中的业务相关问题进行沟通的经历。架构师经常必须对理解方面的差距进行预计，然后才能有所贡献。他们必须愿意克服困难来确保技术和业务观点的融合。他们并不必对意见交换工作进行计划和协调;这仍然主要是项目经理的工作。他们的任务是确定表述系统设计时的最佳工具和构件，以促进有效的意见交换。他们必须能够判断当前方法显得不足而需要采用新方法的情况。写作技能也非常重要，还需要具有制作草图的技能或使用制图软件的能力。

　　具有处理谈判细节方面的经验：架构师经常需要负责讨论系统开发的技术折衷方案。优先级的冲突可能会带来实践限制、风险规避或可能导致在各个不同业务组之间需求不同。优秀的架构师能够有效地评估技术可能性，并能在不损失项目的主要价值的前提下制订开发计划来处理各种利害关系和限制。这与前面讨论的沟通技能紧密相关，但同时也要体现架构师的技术能力。好的架构师候选者应该是经常帮助对有争议的讨论进行引导的人，能够使讨论得出新的想法，而不会使其在一个位置停滞不前。

　　自觉主动;积极解决设计问题：架构师的日常工作目标经常并不明确。很多开发人员直接参考功能规范来列出任务清单。架构师通常则是向这些开发人员提供所需结构的人员，以便尽可能提高工作效率。好的候选者不仅进行沟通方面的工作，而且也会预计各种设计问题并加以解决——通常在没有任何具体指示的情况下自觉进行。无论所分配的职责如何，积极参与项目的开发人员都有机会从一起工作的人员中脱颖而出。

　　抽象思维和分析：架构师必须能够理解表述模糊的概念并将其变成相关各方能够理解的项目构件。他们必须能够理解抽象概念，并以具体的语言对其进行沟通。开发人员中好的候选者经常要求或自己主动解释开发生命周期中容易混淆的问题。他们能迅速评估各种想法并将其纳入后续工作的操作建议中。

　　开发人员经常具有很强的数学能力，而好的架构师则倾向于表现出更强的口头表达能力。管理人员经常说开发人员具有“工程意识”，而这是一个用于评估架构师的非常有意义的方面。架构师应该具有很强的解决技术问题的能力，但还必须能够准确获知更为全面的人员如何与技术交互的信息。这要求具有某种形式的抽象思维(而不再是代码的细节)，这种思维能力可能较难形成。

　　有些人认为，某种级别的正式教育是成为优秀开发人员的必备条件之一，我并不同意这种精英论。我遇到了很多高中就辍学的优秀开发人员。不过，对于体系结构设计工作，我的个人经验以及我对所需能力的认识都让我相信，好的架构师通常至少获得了一个有挑战性的学士学位。

　　跟踪生命周期

　　好的架构师通常有在具备定义良好的软件开发生命周期(Software Development Life Cycle，SDLC)的组织工作的经验。架构师必须理解在其所属专业内最重要的操作过程。这并不意味着需要有其他前提，例如，并不需要高能力成熟度模型(Capability Maturity Model，CMM)级别的工作经验。好的架构师可能来自使用 SDLC 的多个小型迭代的极限编程(Extreme Programming，XP)方法的组织。务必注意各种传统软件开发操作，如 Michael A. Jackson
的方法：Jackson 结构编程(Jackson Structured Programming，JSP)和 Jackson 系统开发(Jackson System Development，JSD)。Jackson 的研究对架构师职业发展的意义就像 Donald Knuth 的研究对程序员一样重要。架构师可以偏爱任何经典的、经过时间考验的软件系统开发方法。

　　SDLC 也可以成为评估架构师合适人选的有用机制。每个 SDLC 阶段都具有能提供相关线索的特征。SDLC 包含很多小的变体，但在此部分，我将使用几乎所有方法的公共基础部分。下面的列表详细说明了 SDLC 的各个阶段，并列出了好的架构师候选者在每个阶段表现出来的特征。

• 　　分析：在分析期间，好的架构师会考虑非技术影响，以便了解需求和将在其中进行开发的环境。架构师可为风险评估任务带来广泛的软件经验供参考。寻找具有丰富经验的开发人员，以帮助业务部门理解技术人员正确解释需求所需的信息。寻找在开发的早期阶段能够预计可能遇到的问题的开发人员。
• 　　设计：在高级设计期间，好的架构师会收集问题空间的各个抽象元素，并就其进行沟通，以便开发团队草拟将要开发的系统的相关图表。架构师负责将需求谨慎地映射到所得到的系统体系结构的功能。在详细设计期间，他们所扮演的角色并不是核心角色，但为了根据整个系统的规则对特定模块的元素进行审查，仍然需要他们。寻找善于让团队能够预计设计决策对最终系统的影响的开发人员。寻找善于确定一些最佳构件来促进与技术和非技术受众沟通设计问题的开发人员。
• 　　实现：在实现期间，架构师对项目进行引导，以确保其符合系统体系结构。他们在一线评估技术更改请求，并确定如何对设计进行调整，以最好地处理此类请求。架构师还要密切了解开发人员的进度，特别要跟踪系统中模块间的集成点的状态。寻找经常对讨论进行引导来连接多个子系统的开发人员。寻找项目经理可以依赖其快速地进行与更改和出现的问题相关的风险评估的开发人员。
• 　　测试：架构师对系统集成和用户接受度测试进行指导，并负责评估进度的正确沟通的持续测试结果。寻找理解错误模式且善于将测试复查结果转换为行动计划的开发人员。
• 　　维护：在维护期间，架构师将发起关于系统集成的讨论。无论处理 IT 基础设施问题，还是确保部门之间的技术合作，架构师都必须完全理解应用程序，必须快速学习姊妹应用程序的体系结构，而且必须就集成点和风险进行有效沟通。寻找具有系统集成经验且表现出快速掌握全貌的能力的开发人员。系统集成是一项独特