第3章 恰到好处地把握架构中的重要方面
你把边界定好，看我怎么在里面大显身手。
第2章强调了一些理由，那些使我们确信：凡是要开发具有一定规模的系统，就必须要重视该系统的软件架构工作。看完该章之后，读者可能会去详细地了解各种架构视图和架构视点，或是去阅读不同的软件架构学派就软件架构中的其他一些方面所写的文章。现在，你可能会想：“架构中最需要关注的是哪些方面呢？我应该从哪里入手呢？面对下一次架构工作，我是否能有充足的准备呢？”能够想到这些问题，那是相当自然的事情。
这是一本注重实效的书，笔者尤其想要告诉大家，怎样才能找出软件架构中的重要领域，以及如何在每个领域中恰到好处地把握住当前任务的本质。请大家遵循PSA（实用软件架构）精神，发展和完善该理念，并且一起来运用它。
本章将要强调架构中的一些方面，笔者认为我们应该花费适当的时间和精力，并通过充分的努力，来恰到好处地把握住这些方面。在开发具有一定规模的IT系统时，如果我们能够做到这一点，那么就可以使自己的工作成果变得有价值。
3.1 软件架构中需要关注的一些方面
任何一种软件架构，都含有多个方面，而且其中某些方面可能还会变得令人畏惧，（从架构的角度来看，）这通常都是因为过分关注细节而导致的。要想避免这种情况，就必须选出一些合适的观察面，使得这些方面不仅能够涵盖解决方案中的诸多侧面，而且能够令我们可以与利益相关者进行有效的沟通。此外，对观察面所进行的选择，还取决于当前这个系统的固有复杂程度。当然，架构师的个人喜好，也是一个因素。
前面说过，本书的主题是怎样恰到好处地把握住架构工作，因此，笔者只会专门讲解那些自己认为对系统的成功会起到必要和充分作用的架构工作，即便面对特别复杂的系统，我们也依然应该把重点放在这些工作上。
本书要讲解下列几个方面：
系统环境（System Context）—描述IT系统（通常表示为黑盒）与外界实体（外界系统及终端用户）之间的交互情况，并确定系统与外部实体之间的信息流与控制流。它用来阐明、确认并捕获本系统的运作环境。这些外围系统及其接口，以及信息流与控制流的性质，都是我们在为本架构中的技术工件拟定下游规范时所应考虑的问题。
架构概述（Architecture Overview）—通过简洁而清晰的示意图，演示软件架构中的主要概念元素，以及这些元素之间的关系。架构概述图可以在不同的层级上绘制，也就是说，我们可以绘制企业级的视图、IT系统级的视图以及分层的架构视图。这些视图有助于展示出能够为IT系统提供支持的架构工件。这些工件都是宏观的符号，有待以功能模型和操作模型的形式做进一步的细化。此外，总览图还描绘了企业在构建IT系统（尤其是当前这个IT系统）时所遵循的战略方向。
架构决策（Architecture Decision）—提供一个坚固的工件，以捕获架构方面的相关决策。这些决策通常是围绕这几个问题而展开的：确定系统的结构，为满足集成方面的需求而确定中间件，把系统的功能与架构中的每个组件（或架构中的每个构建块，也就是ABB）对应起来，把各ABB安排到架构中的各层里，服从并遵守相关的标准，选定实现某个ABB或功能组件所用的技术等，除此之外，可能还有其他一些问题也需要做出决策。凡是对满足架构中的业务目标、技术目标和工程目标比较重要的决策，都应该捕获成架构决策。需要记录的内容包括：问题的确定过程，对各种解决方案及其优缺点的评估过程，解决方案的选择过程，选定某个方案时所依据的理由，以及对下游的设计和实现有所帮助的相关细节。
功能模型（Functional Model）—也称为组件架构或组件模型。它用来描述、定义并捕获软件架构的分解方式，使得架构可以分解为多个IT子系统，每一个子系统都是一个逻辑群组，用来容纳相关的软件组件。这种工件会从软件组件的角度来描述IT系统的结构，同时也会指出组件的职责、接口、静态关系以及协同运作机制。这些组件需要按照该机制进行运作，以便使系统能够具备预期的功能。此工件在迭代开发过程中，会经历多个阶段的细化（elaboration，精化）。
操作模型（Operational Model）—表示一个由计算机系统所构成的网络，此网络不仅会为某些非功能的系统需求（例如性能、可扩展性以及容错能力等）提供支持，而且还能够运行中间件、系统软件以及应用软件组件。此外，它还定义了计算机系统的网络拓扑结构及相互连接情况。与功能模型一样，操作模型在迭代开发过程中，也要经历多个阶段的迭代和细化。
集成模式（Integration Pattern，整合模式）—指的是一系列最为常见的可复用模式，这些模式专门用来对某些技术进行简化和整理，使得当前系统能够更加流畅地用这些技术与其他相关应用程序及系统进行连接与沟通。它可能会利用中介（mediation）、路由（routing）、转换（transformation）、事件探测（event detection）、信息代理（message brokering）及服务调用（service invocation）等架构模式。
基础设施架构（Infrastructure Architecture）—专注于基础设施的开发工作，这些设施包括服务器、存储设备、硬件、工作站、非应用程序型软件以及实体设备等，它们用来为应用程序的开发、测试、部署、管理及维护工作提供支持。
大家一定要意识到：只要系统能够适当地运转，它就具备可用性。然而对于基础设施方面来说，为了保持系统的这种可用性，我们必须把系统与用户交互时的延迟时间和周转时间（turnaround time）处理好，同时还要保证系统能够具备适当的运算能力，以支持功能和非功能方面的需求。