The Software Architect's Profession ：An Introduction

通篇使用了一个类比，类比之所以是类比，就是因为事物本就不完全一样；如果后来事实证明这两件事物具有本质的不同，那么现在所有的类比都没有意义了

1，图纸

建筑中的图纸对应到软件中是什么呢？UML显然不足够精确；是建筑图纸反映的事物本来就简单，还是软件没有找到精确的概念和表示方法？

2，交流

设计师是怎样告诉不识字的人他想要把楼盖成什么样呢？是最终的建筑本来就很简单直观，还是软件缺乏交流的语言？

3，原理

建筑基于精确的力学，热学定理，能够在动工前就计算出怎样行，怎样不行，并且已有各种定式；软件呢？基于什么？开闭原则？依赖倒置原则？就算有人说行，在做出最终的产品前你是不会确信，就算有人说不行，你反而怀疑只是他的能力不行

4，接口

建筑少软件多？因为分层？

5，语汇

建筑有一套普及的，明确意义的词汇（语言），如：托梁，斜削接头，电路箱，管道，子墙，接地电源插头等；软件呢？现有的模式语言远远不够，无论数量，还是普及程度，还是语义的明确程度

6，分工

建筑职责角色清晰，每个人清楚的知道自己所能发挥的范围，每个人也都能在自己的范围内灵活发挥；软件通常一人身兼数职

7，环境

所 有人都生活在建筑中，每个人都见过上百种类型的建筑；在建造前，每个参与建筑的人，心中都能完整的想象出建筑完成后是什么样子，无论是设计师，工人，还是 客户，而且想象处来的样子几乎一致；软件？或许当所有人都生活在软件中，每个人都使用过上百种的软件，在构建前每个参与人员心中都能完整的想象出软件完成 后是什么样子，无论是设计师，程序员，还是客户，而且想象出来的样子几乎一致

8，基础

每 个建筑师都必须掌握建筑力学，材料特性等，即使仅掌握了建筑力学，材料特性，也能使他们设计出简单，但足够实用的建筑；软件？技术掩盖了真相，而真相难以 使用但几乎无所不能，技术却各有千秋；如DCOM，CORBA，RMI，WebService，真相近似是“编码传输解码”，DCOM，RMI语言相关， WebService效率较低，你可以使用真相开发自己的远程调用协议，但难度较大；通常你你碰到不能实现的功能，不是因为真相不许，而是你选用的技术不 允许

9，材质，组件，接口

当你用一种材质替换另一种材质，你不 需要重新了解它的用法，只需了解它的热学力学特性，因为它与原来的材料共享同一接口，完成同一功能，如都是一根钢管，合金管，都是一片楼板；软件，很少有 两个（类库，框架，组件）共享同一接口，你用一种替换另一种的时候，你需要重新熟悉它的接口，学习它的用法；J2EE标准，多种服务器实现的出现是向建筑 看齐的一个趋势，然而这种趋势目前只出现在框架上，而很少有任何业务组件享有同一接口，ODBC，JDBC算是一个例子，操作系统的驱动程序也是但它离企 业应用太远，我们需要相同接口不同实现的分页显示组件，日志组件，打印组件，表格组件；建筑有各种各样的窗子，可它们都共享同一接口：一块矩形区域；什么时候软件组件和框架的接口能简单到这种程度？

10，使用

建筑，几乎没有空闲的房间，闲置的设施；软件：无数从未用到的功能

11，约束

遗留下来的伟大的建筑通常不是用于经济目的的，并且建造过程较少的受到经济制约，可以精雕细琢，发挥各种伟大构想，不需做出妥协；软件，企业级应用几乎全是出于经济目的，受成本制约，不断的做出妥协

12，类比哪种？

传统的建筑架构“正在瓦解”，现代社会出于经济目的的建筑物，建筑群正在“失去架构”，变得大同小异；软件的发展，会像哪一种呢？还是系统软件像传统建筑架构，企业级应用像现代建筑群？

13，帕台农神庙

“除了将事物间正确的关系以简单的形式表达出来，没有任何杂质掺杂其间”

14，历史

在建筑发展的早期，其角色定义，分工等是否也像现在软件一样混乱，是否也经历过架构从无到有，分工从模糊到清晰的阶段？

15，工程师与架构师

软件工程师不能决定系统使用起来有多么容易，架构师设计系统的功能和可用性，即它如何被使用的，而工程师对可用性进行测试，从而使架构师的设计有效可行

16，层面

当软件工程师把自己称作“架构师”的时候，他们通常暗指在技术层面上的设计，而非真正的架构层面，工程师通常看不到客户，整个企业，或领域的传统架构优势

17，功能权力

软件业需要客户来掌控这个权力.......而是在自由市场上客户和消费者所做的成千上万的决定才使的这些理念得到不断的改进，有了长久的价值