下载掌阅APP，畅读海量书库
立即打开
一直以来，由于软件架构涉及范围广且内涵不断变化，开发人员不断尝试给它一个简洁的定义。Ralph Johnson 就将其定义为“重要的东西（无论那是什么）”。架构师的工作就是理解和权衡那些“重要的东西”（无论它们是什么）。
为了给出解决方案，架构师工作的第一步是理解业务需求，也即领域需求。这些需求是使用软件来解决问题的动机，但终究只是架构师在构建架构时需要考虑的因素之一。架构师还必须考虑其他很多因素，其中一些比较明确（比如清楚地写在性能服务水平协议里），还有一些则隐含在商业活动中不言自明（比如公司正着手并购重组，软件架构显然也要有变动）。所以对于软件架构师来说，架构水平体现了他们在权衡业务需求和其他重要因素后找到最佳方案的能力。软件架构涵盖了所有这些架构因素，如图 1-1 所示。
图1-1 架构的完整概念，包括需求及“各种特征”
如图 1-1 所示，业务需求与其他架构关注点（由架构师定义）并存。这包括各种外部因素，这些因素可以改变构建软件系统的决策过程。表 1-1 列举了一些例子。
表1-1 部分特征列表
在构建软件时，架构师必须明确哪些特征最重要。然而，许多因素是互相矛盾的。比如，让软件具备高性能的同时还要实现极大的伸缩性就很困难，因为实现这两者需要谨慎地平衡架构、运维及其他诸多因素。因此，在为架构设计做必要分析的同时，又要处理好各个因素之间不可避免的冲突，架构师在权衡每个架构设计方案的利弊时，常常需要做出非常艰难的 折中 。近年来，软件开发核心工程实践的持续发展给我们提供了条件，使我们得以重新思考架构随时间的推移要如何变化，以及当这样的演进发生时，如何保护重要的架构特征。本书将这些部分联系起来，以一种新的方式思考 架构 和 时间 。
我们想为软件架构添加一个新的标准“特征”—— 演进能力 。