美的核心在于概念完整性——即一组抽象和规则，在整个系统中尽可能简单地应用它们。
我们将计算机系统的架构定义为一组最小的特征集它们决定了哪些程序将运行，以及这些程序将得到什么结果。
架构是一种折中——决定改进其中一个特征常常会对其他特征产生负面影响。架构师必须确定怎样做是足够好的，方法就是发现特定系统的重要关注点，以及充分满足这些关注点的条件。
外部行为描述展示了产品如何与它的用户、其他系统和外部设备进行交互，这应该表现为需求。结构描述展示了产品如何划分为多个部分，以及这些部分之间的关系。我们还需要内部行为描述，用于描述组件之间的交互接口。结构上的描述常常展示相同部分的一些不同视图，因为不可能把所有信息以有意义的方式组织到一张图纸或一份文档中。一个视图中的组件，可能是另一个视图中一个组件的一个部分。
典型的利益相关人和他们的关注点包括：
• 投资人，他们想知道项目是否能够在给定的资源和进度约束下完成。
• 架构师、开发人员和测试人员，他们首先考虑的是最初的构建和以后的维护与演进。
• 项目经理，他们需要组织团队，制定迭代计划。
• 市场人员，他们想通过品质特点实现与竞争者的差异化。
• 用户，包括最终用户、系统管理员，以及安装、部署、准备、配置人员。
• 技术支持人员，他们关注帮助平台电话呼入的数目和复杂性。
架构师的第一项任务，就是与利益相关人协作，理解这些品质关注点和约束，并为它们排列优先级。
重要关注点包括：
• 功能性
• 可变性
• 性能
• 容量
• 生态系统
• 模块化
• 可构建性
• 产品化
• 安全性
架构结构
• 信息隐藏结构
模块间最基本的关系是“整体-部分”关系。第二种信息隐藏模块结构是基于程序和模块之间的“包含”关系。
满足的关注点：信息隐藏结构的设计应该能满足可变性、模块化和可构建性的要求。
• 使用结构
使用结构确定了我们可以构建并测试怎样的工作子集。
满足的关注点：产品化和生态系统
• 进程结构
信息隐藏结构与使用结构属于静态结构，进程结构属于运行时结构。
满足的关注点：性能和容量
• 访问结构
如果这种结构让程序访问的权限最小化，并且严格执行，我们就认为系统更安全。
满足的关注点：安全性
美丽的架构展示了一些普遍原则：
• 一处一个事实
• 自动传播
• 架构也包含构建
• 最少量机制
美丽的架构不会追求最佳，使用最少的机制来满足整体的需求。找到每种情况下的最佳会导致各种容易出错的机制的产生，而用极简的方式来添加机制则会得到更小的、更快的、更健壮的系统。
• 构建引擎
高度可复用
• O(G)，增长的阶
• 抵制熵增
简而言之，美丽的架构用更少的机制做更多的工作。
架构是一种很浪费空间的艺术。
软件系统就像一座由建筑和后面的路构成的城市。
重要的是要保持软件设计的品质。坏的架构设计会导致更坏的架构设计。
极限编程（XP）没有贬低设计，它贬低的是不必要的工作。
架构有助于定位功能：添加功能、修改功能或修复缺陷。它为你提供了一个模板，让你将工作纳入到一张系统导航图中。
清晰的架构设计将导致一致的系统。所有决定都应该在架构设计的背景下做出。
软件架构不是一成不变的。需要时就改变它。要想做到可以修改，架构就必须保持简单。牺牲简单性的修改要抵制。
延迟设计决定，直到你必须做出这些决定为止。不要在你还不知道需求的时候就做出架构决定。不要猜测。
必须保持架构品质。只有当开发者们相信它并对它负责时，才能做到这一点。
你的系统应该有一组不错的自动化测试，它们让你在进行根本的架构变更时风险最小。这为你提供了工作的空间。
对你的代码进行单元测试将带来更好的软件设计，所以设计时要考虑可测试性。
好的项目计划将带来优质的设计。分配足够的时间来创建架构杰作，它们不会立即出现。
团队的组织方式必然对它产生的代码有影响。随着时间的推移，架构也会影响到团队协作的好坏。当团队瓦解时，代码的交互就很糟糕。当团队协作时，架构就集成得很好。
好的架构是很多因素的结果，包括以下方面（但不限于此）：
• 确实进行有意为之得前端设计。
• 设计者的素质和经验。
• 在开发过程中，保持清晰的设计观点。
• 授权团队负责软件的整体设计，而团队也承担起这一责任。
• 不要害怕改变设计：没有什么是一成不变的。
• 让合适的人加入到团队中，包括设计者、程序员和经理，确保开发团队的规模合适。确保他们具有健康的工作关系，因为这些关系将不可避免地影响代码的结构。
• 在合适的时候做出设计决定，当你知道所有必要信息时再做出决定。延迟那些暂时不能做出的决定。
• 好的项目管理，以及合适的最后期限。
绝不要失去神圣的好奇心。——爱因斯坦
在线游戏和虚拟世界显然已经找到了办法来实现伸缩性，以应对数量巨大的用户。目前分为两类方法：
第一类实质上是基于地理位置来实现的。第二种处理游戏或虚拟世界中拥塞区域的方法叫做分区。
