谁需要架构（Martin Fowler）

    刚刚在走廊散步，看到我的同事Dave Rice，当时他心情特别的不好。刚一问他，他就反应激烈的说：我们就不应该面试任何在简历中有架构师经历的人。乍一听，他的措辞很奇怪，因为我们常常会介绍他是我们的著名架构师。导致他的话有点像精神分裂的原因，是基于这样一个事实，即便是在行业标准上来说, “架构师” 和 “架构” 也是非常相似的词。对许多人来说，“软件架构师” 就是《黑客帝国》结尾自命不凡的控制偶像。然而即使在最蔑视这种偶像的公司中，类似Dave这样的架构师也扮演了非常重要的技术领导的角色。
什么是架构？

当我还在为《企业应用架构模式》想标题而发愁的时候，每个看过的人都认为这书是属于架构范畴。然而对于定义这个词，我们都会感到不舒服。但由于这是我自己的书，我觉得有必要尝试着去定义它。我的第一个行动就是要暂时收敛我玩世不恭的个性，避免模糊的定义。从某种意义上来说，我把架构定义成一个词，一个在我们想要谈论设计并且想要吹嘘它，使他听起来很重要的时候使用的一个词。（是的，你可以想象到一个差不多的使用架构的环境）然而，常常就是这样的，在害人的愤世嫉俗里都有一小撮真实。在读了Ralph Johnson在极限编程邮件列表中的文章之后，我意识到这句话说的真好，我要引用它。有一篇以前的文章写到，“环境中最高级别的系统概念，软件系统的架构（在特定时间点上）是它的组织结构或者通过接口交互的主要组成部分的结构，这些组成部分由更小的组件和接口陆续组成”

Johnson回答道：

我是个使用IEEE标准的审稿人，不容争辩，这完全是个伪定义。没有所谓一个系统的最够层次的概念。对客户和开发者来说，他们的关注点是不同的。客户不关心主要部件的架构。因此，也许架构只是对系统开发者来说是最高概念。撇开这些一知半解的开发。 架构是专家级开发人员的最高层次概念。是什么让一个构件变得重要？它重要是因为专家说它重要。下面这个定义可能更好些：“在大多数的成功软件项目中，专家们对当前项目的系统设计都有一个共识，这个共识就叫“架构”。这个共识包括系统如何分成不同的构件，以及这些构件如何通过结构进行交互。这些构件常常由更小的构件组成。但架构只包括所有开发人员都能理解的那些构件和接口。”

    之所以说这个定义更好，是由于它清楚的表明架构是个社会结构（当然，软件也是，但架构更符合），也是因为它不仅仅依赖于软件，同时也依赖于软件中很重要的部分，即群体意识。当然，还有一些别的风格的架构定义，例如：“架构是在项目前期必须做的一系列设计决策。”。这个我也不同意，假使架构是你希望在项目前期做的设计决定，
I complain about that one, too, saying that architecture is the decisions that you wish you could get right early in a project, but
that you are not necessarily more likely to get them right than any other.

     无论如何，根据这个定义，对于大多数项目来说，编程语言也是架构的一部分。而对第一种定义来说，就不是。判断一个东东是否是属于架构范围，是通过开发心中它的重要程度来决定。

People who build “enterprise applications” tend to think that persistence is crucial.

When they start to draw their architecture, they start with three layers.

They will mention “and we use Oracle for our database and have our own persistence layer to map objects onto it.”

But a medical imaging application might include Oracle without it being considered part of the architecture.

That is because most of the complication is in analyzing the images, not in storing them.
Fetching and storing images is done by
one little part of the application and most
of the developers ignore it.