前言：无效的公理

公理：被认为是成立、接受或不言自明的陈述或主张。

数学家基于公理创造理论，这些公理是对无可争议的事实的假设。软件架构师也将理论建立在公理之上，但软件世界比数学更灵活：基本的东西继续以快速的速度变化，包括我们的理论所依据的公理。

软件开发生态系统以动态平衡的恒定状态存在：尽管它在任何给定时间点都处于平衡状态，但它在长期内表现出动态行为。整体的提升和随之而来的变化是这个生态系统本质，一个伟大的现实例子是：像 Kubernetes 这样的工具在十年前还不存在，但现在整个软件系统都是为用户服务的。软件生态系统发生了混乱的变化：一个小变化导致另一个小的变化；当重复数百次时，它会产生一个新的生态系统。

建筑师有一个重要的责任来质疑以前时代遗留下来的假设和公理。许多关于软件体系结构的书都是在一个与当前世界几乎不相似的时代写的。事实上，作者们认为，根据改进的工程实践、操作生态系统、软件开发过程，我们必须定期对基本公理提出质疑——所有这些都构成了架构师和开发人员每天工作的混乱、动态平衡。

随着时间的推移，软件架构的细心观察者见证了功能的演变。从极限编程（Extreme Programming）的工程实践开始，持续交付（Continuous Delivery）、DevOps 革命、微服务、容器化，以及现在基于云的资源，所有这些创新都带来了新的功能和权衡。随着能力的变化，建筑师对行业的看法也发生了变化。多年来，软件体系结构的舌尖上的定义是“以后很难改变的东西”。后来，微服务体系结构风格出现了，其中改变是首要的设计考虑因素。

每个新时代都需要新的实践、工具、度量、模式和一系列其他变化。本书以现代的眼光看待软件体系结构，考虑了过去十年的所有创新，以及一些适合于当今新结构和观点的新指标和度量。

我们这本书的副标题是“一种工程方法”。开发人员长期以来一直希望将软件开发从熟练的工匠可以创造一次性作品的工艺转变为工程学科，这意味着重复性、严谨性和有效的分析。虽然软件工程仍然落后于其他类型的工程学科很多数量级（公平地说，与大多数其他类型的工程学相比，软件是一个非常年轻的学科），但架构师已经做出了巨大的改进，我们将对此进行讨论。特别是，现代敏捷工程实践在架构师设计的系统类型上取得了巨大进步。

我们还讨论了权衡分析这一至关重要的问题。作为一名软件开发人员，很容易对某项特定的技术或方法着迷。但建筑师必须始终清醒地评估每一种选择的好、坏和其他的选择，而现实世界中几乎没有任何东西提供方便的二元选择——一切都是一种权衡。鉴于这种务实的观点，我们努力消除对技术的价值判断，转而专注于分析权衡，以使读者对技术选择有一种分析的眼光。

这本书不会让一个人一夜之间成为软件架构师——这是一个有很多方面的微妙领域。我们希望为现有的和新兴的架构师提供一个关于软件架构及其从结构到软技能的许多方面的良好现代概述。虽然本书涵盖了众所周知的模式，但我们采用了一种新的方法，依赖于经验教训、工具、工程实践和其他输入。我们采用了软件架构中的许多现有公理，并根据当前的生态系统重新思考它们，并设计架构，同时考虑到现代场景。

使用代码示例

补充材料（代码示例、练习等）可在以下网址下载 http://fundamentalsofsoftwarearchitecture.com.

如果您在使用代码示例时遇到技术问题或问题，请发送电子邮件至 bookquestions@oreilly.com.

这本书是来帮助你完成工作的。通常，如果本书提供了示例代码，您可以在程序和文档中使用它。除非您正在复制代码的重要部分，否则无需联系我们获得许可。例如，编写使用本书中几个代码块的程序不需要许可。出售或分发O'Reilly书中的示例需要获得许可。通过引用本书和引用示例代码来回答问题不需要许可。将本书中的大量示例代码合并到产品文档中需要获得许可。

如果您觉得您对代码示例的使用超出了合理使用范围或上述许可范围，请随时联系我们 permissions@oreilly.com.