体系架构的生命期：对业务的影响以及如何构建更持久的体系架构

什么是体系架构的生命期？应该考虑到何种程度？它对业务可能有何影响？为了回答这些问题，Dan Pritchett 引入了“体系架构保质期”的概念，他将其定义为“开始设计新的系统时，一组模式和技术的适用期限”。他认为体系架构保质期能持续 5 年左右，经过两到三代以后，任何体系架构至少会有部分的改变。否则，该体系架构就会很陈旧，而且在适应业务需求发展时会引起成本的增加。基于此，Pritchett 认为“体系架构通常有 10 到 15 年的有效期”。为了支持自己的论点，他给出了自 1990 年以来发生的技术、体系架构演进的一系列例证。

Pritchett 主张，如果没有在体系架构生命期结束的时候更新体系架构，可能会对业务有重大的影响。但他也承认，改变主要的体系架构会导致可观的成本，尤其是“你在供应链里已经拥有了坚实的客户基础，以及超值的业务特性”。正如争论：是否应该避免架构重写？中涉及的几个作者所强调的一样，改变甚至是破坏性的。不过 Pritchett 认为，不采用新的模式和技术会带来更大的成本。这些技术和模式通常有助于提高开发者的效率、降低部署的成本。拒绝利用这一潜在的竞争优势相当于让竞争对手占尽先机，对业务来说这可是致命的：

被忽略的是，新的模式和平台无论如何都能用来破坏你的业务。如果你拥有成功的业务，许多人也会想分一杯羹。技术就成了他们追赶你业务的工具。他们会以更低的成本或者更具竞争力的特性提供和你一样的服务，这引起的破坏可要远甚于内部体系架构改变所引起的破坏。

在他第一篇文章的续作中，Pritchett 提出随着新模式和技术的涌现，主要体系架构改变的必然性上存在一些细微的差别。他曾经讲过，体系架构的生命期依赖于其轻松扩展以适应演进业务需求的能力，他将这一点转换为技术术语，解释为“随着不断风行的新技术而被更新”的能力。“遵循优良构件设计的标准体系架构原则，保持组件间最大限度的松耦合度”能强化这一能力，使得这些构件可以相互独立地实现和演进。基于识别的一些常见错误，Pritchett 提取出了一 些要构建更持久的体系架构可采纳的原则：

1. 接口协议和实现策略之间的解耦。这将增加“构件在可选实现技术之间移植的灵活性”。Pritchett 建议，构件之间定义像 XML 或 JSON 之类的、基于文本的接口可以达到这个目的。

2. 注重关注点分离，即使两个关注点的初始大小差别很大。这可以避免如下情形：为现有构件增加一个新特性，随着该新特性逐渐发展，你最终等于把两个组件实现成一个严重耦合、相互纠缠、难于解耦的组件，特别是当“解耦后无法保持客户已经习惯的旧有行为”，更加难以解耦。

3. 避免无意识的供应商依赖，这种依赖需要深入理解供应商的产品、它们对体系架构及其含义的影响。

4. 最小化持久化绑定，避免数据库依赖。对实体的关键访问路径应该仅通过主键，其它访问路径则应该在资源层进行分离，以便将来在其它形式的持久化中能处理这些可选路径。

遵循以上尽可能降低耦合度的规则可以让我们构建灵活的体系架构，这样的体系架构更容易与新技术和新模式集成，从而降低改变的成本、延长体系架构的生命期。

查看英文原文：Architecture Life Span:Implications on Business and how to build more Long-lasting Architecture