2.1 禁止或启用一个系统的质量指标

        系统是否允许展示其渴望的（或需求的）质量指标在很大程度上取决于其架构。
        本书的第二部分会对此进行更加详细地阐述。在此之前，请记住以下示例：
        (1) 如果你的系统需要高性能，那么你需要注意管理元素基于时间的行为，它们共享资源的使用，以及元素间通信的频率及容量。
        (2) 如果可变性很重要，则需要注意分解每个模块的职责，以保证系统的大部分变更都只会影响少部分模块（最理想的状态时，每个变更只会影响一个元素）。
        (3) 如果你的系统要求高安全性，那么你就需要管理和保护好内部元素通信和控制哪个元素允许访问哪些信息；同时也需要在架构文档中介绍这些特殊元素（例如权限管理机制）。
        (4) 如果你认为可扩展性是系统成功的关键，那么你需要仔细地本地化资源的使用，以便引入更高容量的替代物，且必须规避在资源中使用硬代码。
        (5) 如果系统需要能够支持增量交付，那么你必须小心地管理内部组件的使用。
        (6) 如果你希望你系统中的元素在其他系统中被复用，那你需要限制内部元素间的耦合，这样当你在其他系统使用这个元素时，不会需要引入太多其他的元素。
        这些或其他质量指标的策略是非常架构化的。但单凭架构不能确保系统的功能或质量需求。糟糕的下游设计或实施策略总是会破坏适当的架构设计。如我们所说（更多时候是玩笑话）：架构给予，实现带走。从架构设计到代码和实现的生命周期的每个阶段，决策都会影响系统的质量。因此质量不完全是架构设计的功能。
        好的架构对于确保质量是必要的，但还不够。交付质量指标必须在设计、实现和部署的时候都被考虑到。质量指标不完全依赖于设计，也不完全依赖实现或部署。令人满意的结果是获取全局（架构）以及细节（实现）的正确性。
        例如，可变性是由功能如何被拆分和耦合（架构化的）及模块中的代码技术（非架构化的）决定的。因此，如果变更涉及尽可能少的不同元素，则系统通常是可修改的。然而，尽管拥有理想的架构，但通过编写晦涩、混乱的代码，总是有可能使系统难以修改。