演化架构与紧急设计：研究架构和设计

演化架构与紧急设计：研究架构和设计2011-05-18 IBM Neal Ford演化架构（evolutionary architecture）和紧急设计（emergent design）都是将重要的决策推迟到最后责任时刻（Last Responsible Moment）的敏捷技术。在本系列的第一期文章中，系列作者 Neal Ford 将定义架构和设计，然后指明了一些关于整个系列的基本概念。

软件架构和设计一直都没有一个明确的定义，因为软件开发作为一门学科，尚未完全理解其中的复杂度和内涵。但是要发表关于这些主题的论述，您必须从某个位置开始。本系列涉及演化架构和紧急设计，因此将从一些定义、注意事项和其他基础设置入手。

定义架构

软件中的架构是开发人员谈论最多但是最难理解的概念之一。在会议中，关于架构的对话及相关讨论频繁出现，但是我们仍然只具有含糊的定义。在讨论架构时，我们实质上是在谈论几个不同但是相关的方面，这些方面通常可以划分为应用程序架构和企业架构这两个主要类别中。

应用程序架构

应用程序架构描述组成应用程序的主要部分。例如，在 Java 世界里，应用程序架构都描述两个内容：用于构建特定应用程序的框架组合 — 我称其为框架级架构 — 以及更多传统的逻辑关注点分离，我一直称这些内容为应用程序架构。将框架架构作为一个独立部分，因为大多数面向对象语言的从业者已经发现单独的类不能实现良好的重用（您最后一次从 Internet 中下载一个单独的类以供某个项目使用是什么时候？）。目前面向对象语言中的重用部分都是库或框架。当您用提供丰富框架的语言（如 Java 语言）启动一个新项目时，首要的架构关注点之一就是应用程序的框架级架构。这种重用设计在 Java 世界中获得了巨大成功，以至于我已经开始认为我们应当停止把 Java 编程称为面向对象的语言，而应当称其为面向框架的语言。在许多方面，框架级架构代表特定构建块所描述的物理架构。

应用程序架构的另一个有趣的方面描述应用程序的逻辑部分如何整合在一起。这属于设计模式和其他结构描述的领域，并且因而趋向于更具抽象性和逻辑性，而非物理性。例如，您可以说 Web 应用程序遵循模型-视图-表示器（Model- View-Presenter）模式，而无需详细说明您使用哪个框架实现逻辑安排。这种逻辑安排是在开始处理应用程序的新组件时，最有可能增添到工作空间白板（whiteboard）中的内容之一。

企业架构

企业架构关注如何使企业作为一个整体（通常意味着在大型组织内运行的应用程序）来使用应用程序。关于企业架构与应用程序架构之间关系的常见比喻是把企业比作城市规划，把应用程序比作建筑结构。城市规划者必须考虑获得水、电、污水和其他服务才能使城市运转。一栋大楼使用的自来水不能多于提供给它的配额。企业架构需要为应用程序考虑同样的事情：您不可以允许一个应用程序使用所有网络带宽，而如果基础设施服务崩溃，就会出现大量问题。

企业架构在过去几年里得到了很多关注，这都是因为面向服务架构（Service -Oriented Architecture，SOA）。SOA 是一个独立的庞大主题，因此本系列未来几期文章将把它处理为特殊案例。它拥有自己的有趣方面，因为它在规定应用程序构造的特性时，它模糊了企业架构与应用程序架构之间的界限。

前面几段内容提供了这些重要概念的表面定义，但是它们可用作其他更有趣、更细致的架构定义的出发点（包括通过其他定义得到的一些定义）。

目前的定义

许多有才识的人都曾试着去定义软件架构，因此我将从他们的成果中获取一些思路。在 Martin Fowler 的经典白皮书 “Who Needs an Architect？”中，他讨论了几种定义。他引用了 Extreme Programming 邮件列表中的第一个定义：

“制定 IEEE 定义的 RUP 把架构定义为 ‘环境中最高级别的系统概念。软件系统的架构（在特定时间点上）是通过接口交互的重要组件的组织或结构，这些组件由越来越小的组件和接口组成。’”

如上所述，此定义在应用程序架构领域内非常恰当。虽然有些含糊，但是它捕捉到了架构职责的本质：最高级别的概念。

Fowler 随后引用了 Ralph Johnson 的话，Ralph Johnson 在此邮件列表的回复中对前面的定义提出了争议：

“更好的定义是：‘在大多数成功的软件项目中，从事该项目的专家开发人员对设计系统的设计存在共识。这种共识被称为 “架构”。这种共识包括如何将系统分为组件以及组件如何通过接口进行交互。’”

Johnson 提出了一个很好的观点，强调软件开发对通信的依赖要多于对技术的依赖，而该架构实际上代表关于系统的共识，而不是特定于语言、框架和其他短暂存在的技术。