1.4 好的架构由什么组成

        实际上并不存在一定好或者不好的架构。每个架构都或多或少地适用于某些场景。三层面向服务架构可能只是一个大型的基于B2B企业系统的入门架构，但对于航空应用来说则足够了。为实现高可修改性而精心设计的架构对于一次性原型并没有意义（反之变然）。本书的一则消息是，架构事实上是可以被评估的——重视架构的最大收益之一——但只在特定状态目标的背景下。

        然而，当设计大部分架构时，还需要遵守一些经验法则。如果不应用任何一项经验法则，并不意味着架构有致命缺陷，但至少应该作为一个警告信息，应该进行调查。

        我们将观察结果分为两类：过程推荐或产品推荐（或称结构化推荐）。过程推荐是指：

        (1) 架构可以作为单个架构师或一个小的拥有技术集团的架构团队的产品。这种方法为架构提供了概念完事性及技术一致性。过程推荐适用于敏捷项目、开源项目及“传统”项目。架构师和开发团队应该保持强联系，以规避不切实际的象牙塔设计。

        (2) 架构师（或架构团队）应持续不断地将架构建立在明确规定的质量属性需求的优先列表上。质量属性和架构总在进行权衡，在这个过程中，功能反而不那么重要。

        (3) 架构应该使用视图进行记载。视图应设法解决最重要干系人对于项目时间线的担忧。这就意味着最初应提供最小文档，后续再补充上详细阐述。这些担忧通常是跟系统的结构、分析、维护，以及新的干系人对于系统的了解程度有关。

        (4) 每个架构都应该评估其交付系统重要质量指标的能力，且应该在确定可以获得最大收益，且适当重复时，在整个生命周期的早期进行评估，以确保架构（或预期的环境）的变更不会使设计过时。

        (5) 架构应该支持增量变更，避免不得不同时集成所有内容（这几乎不起作用），这跟尽早发现问题一样重要。有一种实现增量变更的方法是创建一个鱼骨图系统，并在其中包含演练过的通信路径和最小化的功能集。在需要时，该鱼骨图系统可以用于对系统进行增量演化与重构。

        结构经验法则如下：

        (1) 架构应该具有定义良好的模块，其功能职责根据信息隐藏和影响隔离的原则进行分配。信息隐藏模块应封装可能产生的变更，从而使软件免受这些更改的影响。每个模块都应该拥有定义良好的封装或隐藏了易变功能的接口，以便于其他软件调用。这些接口应该允许它们各自的开发团队独立进行工作而不互相影响。

        (2) 除非你的需求是前所未有的——可能，但不太可能——否则你的质量指标应该使用众所周知的架构模式和特定于每个指标的策略来实现。

        (3) 架构不应该依赖于商业产品或工具的特定版本。如果必须依赖的话，它应该结构化，以确保可以简单方便地变更到商业产品或工具的其他版本。

        (4) 生产数据的模块应该与消息数据的模块分离开来。这是为了加强可变性，因为更改常常局限于数据的生产或消费端。如果新增了新数据，生产方和消费方都必须变更，但将生产者和消费者分离开来可以使得变更变得增量化或者阶段化。

        (5) 别去期待模块和组件是一对一关联的。例如，在并发系统中，可能同时会有组件的多个实例在运行中，而这些组件都是同一个模块创建的。在多线程并发系统中，每个线程都可能使用多个组件的服务，而每个组件是由不同的模块创建的。

        (6) 每个进程都应该被编写，以便它对特定处理器的分配可以很容易地更改，也许甚至在运行时也可以。

        (7) 架构应该保障组件间的互相影响是最小化的。即，整个系统应该以相同的方式做相同的事情。这会更加易于理解，能减少开发时间，提高可靠性，提高可变性。

        (8) 架构应该包含特定的（且是小的）资源竞争区域，而冲突解决办法就是清晰的规定和维护。例如，如果网络利用率是一个值得关注的领域，架构师应该为每个开发团队生成（及落地）指导方针，从而将网络流量降至最低。如果性能是一个值得关注的领域，架构师应该为主线程生成（及实施）时间预算。