架构之美-读书笔记之一
每次读第一章都觉得不是很好懂，这些概念在别的地方都见过，唯一让我觉得新颖的和流连忘返的就是品质关注点与功能需求的论述，先后关系。一般写程序，首先考虑的是功能分解，模块分解，实现，然后根据实际场景，再做出一些隐含的、默认的品质需求决定，无书面的思考和确认，而本书明确提出的品质关注点，并理顺其中的关系，让设计三思而后行。
架构之美 第一章
什么是架构？
架构应该是一组结构，来源于一组设计规则，能减少复杂性。常见定义是，每种结构由各种类型的组件和关系组成，它们如何组合、相互调用、通信、同步、及其其他交互。
以我的理解，简单讲：组件及组件间的关系。
架构存在的目的是什么？
确保利益相关人员的关注点能够得到满足，而在构想、计划、构建和维护系统时，系统架构能够处理复杂性。
为了对付复杂性，系统被分解为一些交互的组件。
而每种结构都有特定的关注点，如可变性和性能。各种关注点需要相互妥协、折中。
而架构师的工作就是：
1）满足客户需要
2）整个系统应用相同的设计原则
3）满足法规和安全性需求
架构与需求的关系？
外部行为的描述，展示了产品如何与它的用户、其他系统和外部设备之间的交互，这应该表现为需求。
结构描述，展示了产品如何划分为多个部分，以及这些部分的关系
内部行为描述，用于描述组件之间的交互接口
需求一般理解为系统的功能，但其隐含的品质性要求，也需要架构考虑。
架构与设计的关系？
这个是针对架构师和开发者的工作区别而言。
架构是系统设计的一部分，架构忽略了系统的一些细节，更侧重于系统如何组装起来。而开发者更侧重中部分组件的设计，不用太注意系统组件的装配问题。
如何创建一个架构？
两个优秀的实践：
1. 让利益相关人参与
2. 同时关注功能和品质
典型的利益相关人员：
1. 投资人、老板： 项目需要的资源、能否在工期内完成
2. 项目经理： 团队、项目计划、项目进度
3. 架构师、开发、测试人员： 项目的构建、以及维护和演进
4. 市场人员： 品质特点，超越竞争者
5. 用户（包括最终用户、安装、管理等人员）： 可用性
架构师需要与利益相关人员协作，理解他们的品质关注点，然后考虑折中，排列优先级。
如：
1. 安全性和性能。如对信息加密将加强安全性，但会损失性能。
2. 可变性与可用性。如利用配置文件，可以增加可变性，但会降低可用性。以及如何创建配置文件的格式。
为什么要首先给品质关注点排优先级？而不是从功能需求开始？
因为系统的功能分解通常有很多种方式，如从数据模型出发，和从业务模型出发会得到不同的系统架构，极端情况下，系统无分解，被开发成单一的软件，可能会满足所有需求，但不满足品质关注点。如可变性、可扩展性、可维护性、可伸缩性等。
1. 可变性。将系统内的参数，转移到配置文件中，便于修改。
2. 可以伸缩性、性能。将系统从单机迁移到分布式部署，从单线程转移到多线程。
产品要像他们的用户提供哪些功能？
2）可变性（Changeability）
软件将来可能需要哪些改变？哪些改变不太可能发生，不需要特别容易进行这些改变？
3）性能（Performance）
产品将达到什么样的性能？
4）容量（Capacity）
多少用户将并发使用该系统？该系统将为用户保存多少数据？
5）生态系统（Ecosystem）
在部署的生态环境中，该系统将与其他系统进行哪些交互？
6）模块化（Modularity）
如何将编写软件的任务分解为工作指派（模块），特别是这些模块可以独立地开发，并能够准确而容易地满足彼此需要？
7）可构建性（Buildability）
如何将软件构建为一组组件，并能够独立实现和验证这些组件？哪些组件应该复用其他的产品，哪些应该从外部供应商处获得？
8）产品化（Producibility）
如果产品将以集中变体的形式存在，如何开发一个产品线，并利用这些变体的共性？产品线中的产品以怎样的步骤开发？在创建一条产品线时，要进行哪些投资？开发产品线中不同的变体的选择，预期会得到怎样的回报？
特别是是否可能先开发最小的有用产品然后再添加（扩展）组件，在不改变以前编写的代码的情况下，开发产品线的其他成员？
9）安全性（Security）
产品是否需要用户认证，或者必须限制对数据的访问？数据的安全性如何得到保证？如何抵挡“拒绝服务”工具或者其他攻击？
文中使用了一个表格，很简洁地表达了结构、组件、关系、品质关注点。
本章其他一些要点：
1. 架构要尽量简单，但不要过于简单。 尽量简单可以便于修改。而过分牺牲简单性的修改要抵制。
2. 系统设计需要保持概念完整性、一致性。
3. 优秀的架构示例：
A-7E OFP 舰载飞行处理器
朗讯53SS电话交换机
万维网WWW
UNIX系统