架构概述
“架构”作为一个名词：意味着一组工作，包括相蓝图和构建规范这样的文档，这些工作描述了要构建的对象
“架构”作为一个动词：用来描述创建这些工作的过程，包括由此而导致的工作
架构既是所构建系统的计划，确保由此得到期望的特性，同时也是所构建系统的描述
好的系统架构展示了系统完整性，也就是说，它来自于一组设计规则，这组规则有助于减少复杂性，并可以用于指导详细设计和系统验证，设计规则可能包含特定的抽象，
一个完美的架构必须具有以下特征
- 具备客户要求的功能
- 能够在要求的工期内安全的构建
- 性能足够好
- 可靠的
- 可用的，并且使用时不会造成伤害
- 安全的
- 成本是可接受的
- 符合法规标准
- 将超越前人及其竞争者
到目前为止，我没有见过一个复杂系统能够很好的满足上述特征，架构是一种折中，决定改进其中一个特征往往会对其他特征产生负面的影响，架构师必须确定怎么做是足够好的，方法就是发现特定系统的重要关注点，以及充分满足这些关注点的条件
架构观点中的最常见的思想是结构，每种结构都是由各种类型的组件及其关系构成，它们如何组合、相互调用、通信、同步以及进行其他的交互
面对不断增长的系统复杂性，以及他们内部和相同之间的交互，由一组结构形成的架构提供了对付复杂性的主要手段，目的是确保得到的系统具备所要求的特征，结构为我们提供途径，将系统化解为一些交互的组件
每种结构都是为了帮助架构师理解如何来满足特定的关注点，如可变性或者性能，展示某些关注点得到满足时，可能会影响到其他方面的关注点，但架构师必须能够说明所有关注点都已得到满足
网络架构：构成一个网络的通信设备、协议和传输链路以及他们的组织方式
架构与设计
架构师系统设计的一部分，它突出了某些细节，并通过抽象省略掉另一些细节，所以架构是设计的一个子集，关注实现 系统组件的开发者可能不会特别关心所有组件如何装配在一起，而是主要关注少数组件的设计和开发，包括他们必须遵守的架构约束和可以应用的规则，因此开发者和架构师面对的是系统设计的不同方面
创建软件架构
架构师的第一项任务，就是与利益相关人协作，理解这些品质关注点和约束，并为它们排列优先级。为什么不从功能需求开始?因为通常有许多种可能的系统分解方式
系统关键关注点
- 功能性： 产品向它的用户提供了那些功能
- 可变性： 软件将来需要哪些改变，哪些改变不太可能发生，不需要特别容易进行这些改变
- 性能： 产品将达到怎样的性能
- 容量： 多少用户将并发使用该系统，该系统将为用户保存多少数据
- 生态系统： 在部署的生态环境中，该系统将其他系统进行哪些交互
- 模块化： 如果将编写软件的任务分解为工作模块，特别是这些模块是可以独立地开发，并能准确而容易得满足彼此的需要
- 可构建性： 如何将软件构建为一组软件，并能独立实现和验证这些组件
- 产品化
- 安全性
架构结构
信息隐藏结构
组件与关系：主要组件是一些“信息隐藏模块”，每个模块都是针对一组开发人员的工作指派，每个模块都包含了一种设计决定，如果一项决定可以改变，同时又不影响任何其他模块，我们就说这项决定是一个模块的秘密，模块间的最基本关系是整体与部分关系， 第二种是基于程序与模块之间的包含关系，如果模块M的一部分工作指派是要编写程序P，那么M包含P