体系架构的生命期:对业务的影响以及如何构建更持久的体系架构
作者 Sadek Drobi 译者 张兵 发布于 2008年10月6日 上午1时16分
什么是体系架构的生命期?应该考虑到何种程度?它对业务可能有何影响?为了回答这些问题,Dan Pritchett引入了“体系架构保质期” 的 概念,他将其定义为“开始设计新的系统时,一组模式和技术的适用期限”。他认为体系架构保质期能持续5年左右,经过两到三代以后,任何体系架构至少会有部 分的改变。否则,该体系架构就会很陈旧,而且在适应业务需求发展时会引起成本的增加。基于此,Pritchett认为“体系架构通常有10到15年的有效 期”。为了支持自己的论点,他给出了自1990年以来发生的技术、体系架构演进的一系列例证。
Pritchett主张,如果没有在体系架构生命期结束的时候更新体系架构,可能会对业务有重大的影响。但他也承认,改变主要的体系架构会导致可观的成本,尤其是“你在供应链里已经拥有了坚实的客户基础,以及超值的业务特性”。正如争论:是否应该避免架构重写? 中涉及的几个作者所强调的一样,改变甚至是破坏性的。不过Pritchett认为,不采用新的模式和技术会带来更大的成本。这些技术和模式通常有助于提高开发者的效率、降低部署的成本。拒绝利用这一潜在的竞争优势相当于让竞争对手占尽先机,对业务来说这可是致命的:
被忽略的是,新的模式和平台无论如何都能用来破坏你的业务。如果你拥有成功的业务,许多人也会想分一杯羹。技术就成了他们追赶你业务的工具。他们会以更低的成本或者更具竞争力的特性提供和你一样的服务,这引起的破坏可要远甚于内部体系架构改变所引起的破坏。
在他第一篇文章的续作中,Pritchett提出随着新模式和技术的涌现,主要体系架构改变的必然性上存在一些细微的差别。他曾经讲过,体系架构的 生命期依赖于其轻松扩展以适应演进业务需求的能力,他将这一点转换为技术术语,解释为“随着不断风行的新技术而被更新”的能力。“遵循优良构件设计的标准 体系架构原则,保持组件间最大限度的松耦合度”能强化这一能力,使得这些构件可以相互独立地实现和演进。基于识别的一些常见错误,Pritchett提取 出了一 些要构建更持久的体系架构可采纳的原则 :
1. 接口协议和实现策略之间的解耦。这将增加“构件在可选实现技术之间移植的灵活性”。Pritchett建议,构件之间定义像XML或JSON之类的、基于文本的接口可以达到这个目的。
2. 注重关注点分离,即使两个关注点的初始大小差别很大。这可以避免如下情形:为现有构件增加一个新特性,随着该新特性逐渐发展,你最终等于把两个组件实现成一个严重耦合、相互纠缠、难于解耦的组件,特别是当“解耦后无法保持客户已经习惯的旧有行为”,更加难以解耦。
3. 避免无意识的供应商依赖,这种依赖需要深入理解供应商的产品、它们对体系架构及其含义的影响。
4. 最小化持久化绑定,避免数据库依赖。对实体的关键访问路径应该仅通过主键,其它访问路径则应该在资源层进行分离,以便将来在其它形式的持久化中能处理这些可选路径。
遵循以上尽可能降低耦合度的规则可以让我们构建灵活的体系架构,这样的体系架构更容易与新技术和新模式集成,从而降低改变的成本、延长体系架构的生命期。