2020年/02月/15日
架构之美序言
序 StephenJ.Mellor
使用随意的、非正式的工程技术去开发高性能、高可靠性和高品质的软件系统会遇到非常多的困难。这些技术对于过去要求较低的系统也许还能对付，而目前系统的复杂性已经达到了这样一种程度：如果不开发并维护一个基础架构，利用它将系统组织成一致的整体并避免零碎的实现，那么我们就无法应对，必将导致测试和集成失败。但是，建立一个架构是一项复杂的任务。很难得到合适的例子，因为要么必须考虑专有权，要么刚好相反，有人需要向各式各样的环境推销某一种架构风格。架构是很大的概念，这使得很难在不吓坏读者的情况下来记录或描述。但是，美丽的架构展示了一些普遍原则，下面我列出了几点：
一处一个事实
重复导致错误，所以应该避免。每个事实应该是单一的、不可分解的单元，每个事实必须独立于其他事实。当改变发生时（这是不可避免的），只有一个地方需要修改。数据库设计者很熟悉这一原则，它以范式（normalization）之名规范化了。这个原则也不那么规范地应用于行为，名为提取公因式（factoring），即同样的功能提取出来，放到独立的模块中。美丽的架构找到了一些方法来定位信息和行为。在运行时，形成了分层，即系统可以按层来划分，每个层代表了一层抽象（abstraction）或一个领域（domain）。
自动传播
一处一个事实听起来不错，但出于效率的考虑，某些数据或行为常常会重复。为了维护一致性和正确性，这些事实的传播必须在构建时自动进行。美丽的架构是由一些构建工具支持的，结果导致了元编程（metaprogramming），将一个事实从一处传播到多处，在那些地方有效地使用它们。架构也包含构建架构不仅包含运行时系统，而且必须包含它的构建方式。只关注运行时代码会导致架构随时间的推移而退化。美丽的架构是经过深思熟虑的。它们不仅在运行时是美丽的，在构建时也是美丽的；利用同样的数据、函数和技术来构建系统，就像在运行时使用的那样。
最少量机制
实现某个功能的最佳方式要视情况而定，但是美丽的架构不会追求“最佳”。例如，有许多种方式可以存储和查找数据，但如果系统利用一种机制达到了性能要求，就会考虑编写、验证和维护较少的代码，以及占用较少的内存。美丽的架构使用一组最少的机制来满足整体的需求。找到每种情况下的“最佳”，会导致各种容易出错的机制的产生，而用极简的方式来添加机制则会得到更小的、更快的、更健壮的系统。
构建引擎
如果您希望构建脆弱的系统，就采用IvarJacobson的建议，将架构建立在用例的基础上，每次实现一个功能（例如，使用“控制器”对象）。但是，可扩展的系统依赖于虚拟机的构建，即由更高层提供的数据来“编程”的引擎，一次实现多个应用功能。这个原则以多种外观出现。虚拟机的“分层”可以追溯到EdsgerDijkstra。“数据驱动的系统”提供了引擎，依赖于系统中的编码常量，让数据来定义特定情况下的具体功能。这些引擎是高度可复用的，也是美丽的。
O（G），增长的阶
在以前，我们会考虑算法的“阶”，例如，根据对一组一定数量的元素进行排序的时间来分析排序的性能。许多书籍都是围绕这个主题来写的。这同样适用于架构。例如，一个投票程序在少量数据的情况下工作得很好，但数据量增大时响应时间就变得难以接受。按照中断或事件来组织所有的工作，在开始时会工作得很好，但后来可能突然出现问题。美丽的架构会考虑可能的增长方向，并能够支持这种增长。
抵制熵增
美丽的架构设计了一条最容易维护的路线，随着时间的推移仍能够保持架构，所以延缓了“系统熵增定律”的效果。该定律指出，系统会随着时间的推移变得越来越乱。维护者必须适应该架构，这样变更才能与架构保持一致，不增加系统的熵。一种方法是利用敏捷开发的隐喻（Metaphor）概念，它是一种简单的方式，说明架构像什么。另一种方法是使用大量的文档，并以解雇相威胁，虽然这种方法难以取得长久的效果。然而，这通常与工具有关系，特别是那些生成系统的工具。美丽的架构必须保持美丽。这些原则是高度相关的。只有在你实现了自动传播时，一处一个事实才行得通，而自动传播又只有在架构考虑到构建时才有效果。类似地，构建引擎和最少量机制支持一处一个事实。抵制熵增是长时间保持架构的要求，它靠的是架构包含构建方法并支持自动传播。而且，如果忘记考虑系统将以何种方式增长，将导致架构不稳定，最终会在极端但可预见的环境下失败。将最少量机制与构建引擎的观点结合起来，就意味着美丽的架构通常包含一组有限的模式，同时支持构建任意的系统扩展，这相当于“按模式扩展”。简而言之，美丽的架构用更少的机制做更多的工作。
本书由DiomidisSpinellis和GeorgiosGousios汇编而成，当你阅读本书时，你可以通过每章提供的具体例子，寻找这些原则并思考它们的意义。你也可以寻找违反这些原则的情况，想想这是否导致架构变得丑陋，或涉及某些更高的原则。在写这篇序时，作者问我能否说说如何才能成为好的架构师。我笑了起来。如果我知道的话……但是接着我从自己的经历中想到，有一种特效方法[1]可以帮助人们成为美丽的架构师。这种方法就是永远不要相信你最近创建的系统是唯一的，应设法寻找不同方法来解决相同类型的问题。本书提供的美丽架构的示例就能帮助你朝着实现这个目标迈出一步。[1]或者是锻炼更多，吃得更少。