架构设计90-学习总结06-【翻译】处理遗留系统替换的模式

2021-07-31 本文已影响0人 Wales_Kuo

本文是martinfowler上关于真对遗留系统的处理的文章。原文地址为：Patterns of Legacy Displacement。如有侵权请联系我。

对遗留软件系统进行有效现代化

当面临更换现有软件系统的需求时，团队经常会陷入半完成状态的循环中。根据我们的经验我们可以使一系列的模式来打破这种循环，这依赖于：有意识地了解替换遗留软件的预期结果，以逐步交付部分的方式打破并替换遗留系统，并改变组织文化有意识的传播世间不变的只有变化。

在过去几十年的时间里，我们经常在帮助大型组织处理他们的遗留系统。在这样做的过程中，我们学到了很多关于什么是有效的方法，并看到了许多导致失败的过程。我们决定在工作中留出一些时间，用我们看到的、使用过的各种方法以模式的形式记录下我们学到的东西。

本文充当这些模式的概览。我们经常看到在组织在半途而废的更换遗留系统的跑步机上奔跑。我们认为打破这个循环的关键是需要按顺序完成三项活动，并在公司的生命周期中反复进行。我们使用这些方式作为描述遗留系统替换模式的主要结构。

我们一直相信，有效的软件开发需要逐步发布有价值的功能，写作也是如此—— 尤其是在网络时代。我们从这篇叙述性文章开始，随着我们写下它们的详细信息，将逐渐添加模式，以及展示它们如何组合的其他示例。我们不能保证系列文章的完成时间，因为我们的首要任务是客户工作，这里有很多需要替换的遗留系统。如果您有兴趣了解这项工作的更多部分，它们将在Martin的twitter和本网站的RSS上公布。

遗留系统替代过程中的死循环

和我们合作的许多组织，都多次尝试删除遗留系统。在一个相当典型的案例中，他们经历了长达3-5年的一系列现代化计划。每次他们都会定义一种新的技术方法，然后添加到大型多年现代化计划并朝着这个目标努力。

在每个项目中客户会在的某个时候遇到了一个危机点，不断变化的业务需求将超过他们当前的技术战略。这时的第一种情况是触发他们将软件从头再开始，他们会对程序采取瀑布式“大爆炸”的方式设计与实现。这意味着放弃了先前大部分的工作。而第二种情况是采用增量交付方式，采取这种方法的更多的只是在已经很复杂的环境之上添加一层稍微较新的技术。对于这两种情况，他们都无法停用任何遗留系统的堆积，成本节约和风险降低的关键业务目标仍未实现，这对于许多遗留替换工作来说是非常普遍的结果。

他们屡次失败有几个关键因素：

首先，看到他们糟糕结果在很大程度上是组织不合理的产物；特别是它的领导力、组织结构和工作方式。他们认为只要选择更新的技术，而其他一切都保持不变，他们会得到与过去不同的结果。事后看来，这显然是不现实的。
其次，通过一个大型变革计划来实现现代化，计划本身又包括一系列项目和团队。这些项目被视为与任何现有项目（BUA，一切照旧，Business As-Usual）工作无关。因此，BAU继续根据现有系统交付业务需求，而新项目团队则根据替换计划开始时的内容进行新的开发。
随着时间的推移，他们发现企业实际需要的东西与替换计划开始时的需求之间的差距越来越大。项目运行的时间越长，项目计划、BAU、未来需求三者之间的差距就越大。虽然变更控制流程已向计划添加新要求，但这些流程非常耗时。而且由于前期与项目实施方的合同变更造成成本高得令人望而却步。
再次，希望与现有系统的业务流程集实现功能对等。一开始这些尝试是承诺以某种方式在幕后“改进”技术，为企业提供他们今天所拥有的一切。到后期，业务领导者看到在替换过程中的多次失败并担心替换中断，开始认为这是一种风险较低的策略。这是一项定义对支持的“原样”功能巨大的挑战，它导致了一个“大爆炸”式的大型单一版本切换计划。

我们对这些组织的观察结论是技术最多只占遗留问题的50%，工作方式、组织结构和领导力对成功同样重要。

打破循环

显然有必要打破“遗留系统替代计划”的循环。但组织需要能够继续满足业务需求的同时更换过时的技术，而且所有这些都是在富技术和严峻的竞争环境下进行的。

我们发现有一系列方法可以帮助我们应对这些挑战。它们将问题分解为更小的部分，以便在改进技术的同时满足新要求。从广义上讲，它们分为四类：

了解您想要达到的结果
决定如何将问题分解成更小的部分，并成功交付零部件
改变组织以允许这种情况持续发生

了解您想要达到的结果

对于一个组织来说，在处理遗留问题时就他们想要实现的结果达成一致至关重要。虽然这似乎很明显，但组织的不同部分往往对预期结果有截然不同的看法。大多数遗留系统现代化的过程涉及我们下面列出的几个结果，但在开始替换之前确定哪些是优先事项是至关重要的。

降低变更成本
许多组织在决定解决遗留问题时的一个关键转折点是：开始业务变更所需的成本远高于任何预期收益，而变更成本由于机会成本（也称为延迟）或实施成本增高。一个预警信号是：为业务绩效只带来小幅的提升，必须花费数周、数十或数以千计的工期来对网站进行更改。
在这一点上，通常证明进行任何大量投资的变更不再可能带来回报。换句话说，技术现在的状态已经决定企业的业务变更规模。对于许多组织而言，这意味着进行“BAU”更改或发起大项目之间的区别是：较大的项目会把以前所有不合理的小变化都吸引过来，从而增加其范围、成本和风险。
改进业务流程
我们也经常看到业务流程在遗留系统旁边发展，而流程又与遗留系统紧密耦合。通常方式是在“线下”塑造一个人工业务流程来完成工作。
我们来看一个例子：使用“绿屏”终端的航空公司执机系统，由于旧系统的限制，必须按照严格的顺序执行该过程，这意味着更正或错误就需要重新开始执机过程。同样最初航空公司没有提供转机航班，当添加此功能时，由于该技术的限制，它必须作为遗留系统中的单独工作流程来完成。因此，如果在办理登机手续时，乘客没有提到他们有转机航班，则会遵循错误的流程，包括打印错误的行李标签，只有在此之后系统才会标记转机航班。鉴于此，更新和更改业务流程反过来需要变更值机人员和乘客的工作方式也就不足为奇了。试图在不改变技术的情况下改变工作流程通常会导致“线下”流程，在这种情况下，人们会将数据提取到电子表格或类似工具中，在那里进行处理，然后再将数据导入到遗留系统中。
在一个组织中，整个股票订购过程实际上是在运行在团队经理 PC 上的 Microsoft Access DB 上的。由于遗留系统无法支持供应商的新工作流程，他们变得沮丧。他们每周会进行几次数据的导入和导出，与此同时，组织的其他成员会看到过时的数据，因为没有人意识到发生了什么。
这里值得注意的是，支持数据导入和导出的遗留系统替换的需求通常可能是这种变通方法造成的。
淘汰旧系统
需要淘汰旧系统是遗留系统现代化的常见原因。这通常是由旧硬件或软件支持服务的挑战所驱动的，这些问题包括软件支持服务成本上升和硬件和软件支持合同到期等问题。
我们发现通过业务的视角来查看旧系统很有用。因此，建立将旧系统替换本身理由不充分。相反，我们需要查看不替换旧系统对业务的影响，不替换会导致运行成本不断上升，或者由于缺乏系统支持服务或支持知识而产生的风险。
虽然一些组织确实为旧技术的淘汰做好了计划，但许多组织似乎在问题达到危机点之前忽略了这个问题。反过来，这往往会促使组织采用看起来像低中断选项或快速获胜的现代化方法，这些通常是反模式，我们稍后会描述其中的一些陷阱。
多年来，我们一直震惊于有多少大型组织在不受支持的硬件和软件上运行他们的业务，常见故事的且令人惊讶的是在 eBay 上购买备件。如果您拥有遗留技术，则非常值得创建包含各种终止支持日期的日历。
虽然许多组织将旧系统的退役作为遗留系统现代化的关键结果，但在不少的例子中发现这种情况实际上并没有发生，遗留系统最后仍在使用，相关的业务目标仍未实现。
即将中断
对于某些组织而言，处理遗留问题的实际临界点可能会由于外部因素而出现，例如监管变更、新的“初创”竞争对手或现有竞争对手的重大变化。通常在这一点上，当面临“必须做”的更改时，资金和响应所需的时间变得过长。
外部事件使组织的领导层清楚他们不再有能力以成比例的成本进行更改。
较新的技术
采用新技术不应该成为遗留系统现代化的原因，仅仅为了自己的利益而拥有更新技术很少是任何组织的关键目标。相反，它应该以最能满足企业当前和未来需求的方式进行选择。这里的一个挑战是技术变革的步伐正在加快，技术的“有用”寿命越来越短。“有用”的实际定义取决于组织，但通常我们需要考虑以下事项：
- 允许竞争优势
- 匹配竞争对手或市场产品
- 允许更快的变化速度
- 更换更便宜
- 运行成本较低
我们今天做出的关于最好和最有用的技术的选择很可能会在相对较短的时间内被更好的替代品所取代。这使得在寻找技术以满足未来需求方面做出正确的决定可能非常危险。
这里的一个好方法是不要做出任何在 2-3 年内无法轻易“完成”的选择。这对技术选择以及整体设计和方法都有影响。当我们承认这种加速的变化步伐时，选择一个具有 5 到 10 年回报时间的大型平台是很难证明的。

侧框内容：我们想像 Netflix 一样
我们多次看到的一个问题是我们所说的“Netflix Envy”。这就是组织的技术领导者专注于像 Netflix 或其他一些成功的大型科技公司一样的地方。这意味着他们试图模仿工作方式或选择相同的技术解决方案。如果他们也经常从事流媒体电影业务，这可能是合适的，但这会导致选择不合适的技术。这些技术通常具有扩展能力，但也具有大多数企业根本不需要的更高程度的复杂性和成本。

决定如何将问题分解成更小的部分

从广义上讲，这涉及在当前的业务和技术架构中找到正确的“接缝”。重要的是，您必须考虑当前解决方案的元素如何映射到不同的业务能力。对于遗留系统，这通常意味着发现一个大型技术解决方案如何满足多种业务需求，然后查看是否可以使用新解决方案提取单独的需求以进行独立交付。理想情况下，这些应该是可交付的，彼此之间的依赖性最小。

一个普遍的反对意见是找到这些接缝太难了。虽然我们同意它起初具有挑战性，但我们发现它是一种比通常导致功能对等和大爆炸发布的替代方法更好的方法。我们还观察到，许多组织排除了这种方法，因为他们孤立地看待技术或业务流程。只改变技术的一部分，或者只独立更新一个业务流程很可能会失败，但如果我们可以考虑然后将两者一起实施，就有办法“吃大象”。

入门
在旅程开始时，遗留系统现代化似乎是一个最令人生畏的命题。像任何旅程一样，我们必须首先尝试了解要采取的初始方向。此外，像所有旅程一样，您必须从您所在的地方开始。我们遇到的一个常见问题是，我们似乎经常从茂密森林开始，看不到前方的道路，因此不知道要采取的方向。那么，第一步就是爬上一棵树，环顾四周！这意味着在最短的时间内尽可能地了解当前的系统和架构。这通常很难做到，而且很容易陷入过多的细节中。
幸运的是，有许多非常有用的工具可以协同使用以获得足够好的理解以继续进行。这些工具在别处详细讨论，但汇总列表将包括事件风暴、沃德利映射、业务能力映射和域映射。请注意，在此列表中，我们主要着眼于业务概念如何映射到系统架构中，进而了解该架构如何支持价值生成。这是一个经常缺失的视图，尤其是对于遗留系统。

理解问题的模式	理解问题的模式
价值流图 †	描述用户如何完成工作的人工制品
事件风暴 †	用于理解业务流程的技术

† 目前只是一个介绍，还没有进行填充

侧边栏内容：事件风暴 - 现代流程映射的瑞士军刀
关于该技术的文章很多，作者发现它是一种非常通用的工具，可以在多种情况下使用。事实上，除了绘制业务流程和领域外，作者还使用它进行价值流映射和可视化生产路径。

具体来说，我们发现人们经常在遗留系统的边界处停止发现活动，“这里有沟”，就没有了进一步。如果不跨越边界并揭示遗留系统如何支持（或阻碍）业务流程和活动，则很难找到并提取要交付的薄片。
另一个经常被忽视且非常有价值的信息来源是系统的用户本身。事实上，在笔者经验，这是经常在那里你可以找到令人惊讶的数额个有用的东西，尤其是暴露出许多变通方法，并影子IT生态系统，通常积聚围绕旧的系统-也就是Access数据库和版本的Excel电子表格实际上经营业务。客户旅程图、创建服务蓝图和价值流图是用来表现这种细节的良好效果的工具。

解决问题的模式	解决问题的模式
提取产品线	按产品线识别和分离系统。
提取价值流 †	识别和分离关键价值流
功能奇偶校验	使用新技术堆栈复制遗留系统的现有功能。
一个真戒指 †	通过识别独特和共享的业务能力来细分问题

† 目前只是一个介绍，还没有进行填充

成功交付零件
需要更快的更改以及在没有大量依赖的情况下增量交付和独立更改业务元素的能力通常会导致“敏捷”交付方法以及基于微服务的架构。持续交付成为这些可单独部署的组件的必备条件。使这一挑战超出普通软件交付范围的原因在于，寻找从现有大型解决方案的元素中切入、共存并最终替换元素的策略。存在几种成功的策略，包括并行运行、入口分叉和流量分流。

交付模式
金丝雀发布 †	对部分用户进行更改
停止世界切换 †	在切换到新系统的同时暂停正常的业务活动
恢复到源 †	确定数据的原始来源并与之整合
转移流量 †	首先将关键业务活动和流程从遗留系统中转移出去
黑暗发射 †	在不使用结果的情况下调用新的后端功能以评估其性能影响。
传统模拟 †	新系统以旧系统不知道任何更改的方式与遗留系统交互。
事件拦截 †	拦截系统状态的任何更新并将其中一些路由到新组件

† 目前只是一个介绍，还没有进行填充

改变组织以允许这种情况持续发生

如果我们退后一步并查看交付新业务需求的整个过程，我们会很快发现这只是部分技术问题。如果我们使用更新的技术来减少构建解决方案的时间和成本，那么我们将强调与达成一致的要求和将更改投入生产的任何问题。

我们需要改变组织结构和流程以充分利用更好的技术，根据“康威定律”，我们还需要一个促进这一点的技术架构。如果团队和他们的沟通是围绕现有的遗留解决方案和流程组织的，我们可能需要使用康威逆定律来重组他们，以匹配新的解决方案及其架构。

侧边框内容： 最难的转变是范式转变
在传奇管理顾问 Eli Goldratt 发表《目标》 20 年后，他参加了《财富》小型企业的采访，有人问他为什么这么多组织变革缓慢。他解释说，大多数人会尽其所能避免像当时的约束理论那样根本性的变化。他继续说，他们将尽其所能避免范式转变。
他继续建议，为了成功地改变范式，需要三件事。
1.必须有真正的压力来改善结果
2.并且，同一范式中的其他一切都已经尝试过
3.他们在迈出第一步时得到了帮助

遗留系统可以约束和限制采用替代现代工程实践的能力，尤其是那些与极限编程和持续交付相关的实践。在更换遗留系统时，重要的是要确保改变工作方式，以确保我们最终不会返回一个缓慢、困难且更改成本高的系统。

遗产系统也是组织文化和领导力的产物，如果没有更广泛的变化，您应该期待与之前看到的相同的结果。我们已经观察到许多遗留系统现代化工作由于“企业抗体”而失败，这些抗体发现新发生的事情并采取行动将其从组织中拒绝。

举一个广泛拒绝变革的组织的例子；我们与一家非常大的电信公司合作，该公司希望为手机开发软件。领导层都明白这意味着比他们看到的专注于固定基础设施的现有计划更快的反馈周期和更频繁的变化。

虽然领导层理解这一点，但没有对现有的工作实践或运行这些流程的中层管理人员进行任何更改。因此，现有的变更控制流程得到了严格的应用。最后，软件团队花在填写变更控制表格和参加变更控制会议上的时间比他们制作软件的时间要多。“企业抗体”成功地拒绝了新的工作方式。

组织变革是一个大话题，已有很多文献可用，遗留问题的关键挑战通常与时间相关。很少有组织能够在重新设计（或重建，对于外包受害者）整个交付方法以及组织结构和关键业务流程的同时延迟遗留现代化。虽然更广泛的组织转型主题超出了我们的范围，但我们确实推荐了一些策略，用于在遗留环境中应用和保护新的工作方式。如果你只是改变传统而不做其他事情，那么期望你会在几年内再次取代传统是公平的。

持续组织变革的模式
按您的意思开始继续 †	以您需要在上线后继续的方式创建您的旧版替代品。
受保护的飞行员 †	为新工作创建一个试点计划，并将其与正常的公司治理流程分开
新公司 †	组建全新公司，追求市场颠覆

† 目前只是一个介绍，还没有进行填充

组织转型肯定还有其他策略和方法，我们只是强调了这两种策略和方法，因为它们在某种程度上允许尽早开始遗留现代化的工作。

示例：集成中间件移除

这个例子描述了我们的一个团队如何使用许多遗留系统现代化模式来成功替换对其客户业务运营至关重要的集成中间件，作为更大的遗留现代化计划的一部分。他们将模式和重构相结合，成功地管理了业务风险，并促进了“吃大象”时特别坚硬的部分的食用。

了解结果

我们团队面临的挑战是如何用新的可支持、灵活的业务解决方案替换不受支持、难以变更且成本高昂的集成中间件。不会破坏现有业务运营或将其置于风险之中。有问题的中间件用于在后端系统和店面之间进行集成。这些系统共同负责每天销售价值数千万英镑的高价值独特产品。

这项工作是更大计划中的一个高度优先的部分。支持业务的整个后端系统正在被替换，店面也将在几年内进行现代化计划。

因此，按照上面的第 1 步，团队需要实现的业务成果被定义为：

改善业务流程
如何？这个特定的集成中间件解决方案包含大量逻辑，包括业务核心规则，例如在哪个渠道销售产品，或如何以及何时在店面内展示待售产品。这个现有的系统很难改变，扼杀了业务创新，逻辑上的缺陷导致了产品甚至没有销售的时期等问题！
尽快淘汰旧系统
为什么？减少现有（和增加）的许可和支持成本。此外，为了降低因在过时的支持中间件和数据库技术上运行关键功能而对业务造成的风险。

高级系统处理：用户使用遗留后端系统中的屏幕单独管理产品的定价和发布。对于每个发布的产品，该系统都会将一条消息放入 SwiftMQ 队列。集成中间件将使用该消息，创建其自己的产品状态视图，并调用商店前台的遗留 SOAP API 来发布它。随着时间的推移，集成中间件将使用 API 更新产品的状态，以更改产品向客户提供的方式（例如，将产品从“仅预览”更改为“新可用”等）。当客户购买产品时，旧店面将调用集成中间件提供的 API。

分解问题：第一个接缝和重构

在Inception期间，团队与对遗留系统有深入了解的人举办了一个研讨会，以协作可视化原样和未来的软件架构。完成此操作后，他们发现了一个技术接缝，可以在遗留后端和集成中间件之间以基于消息传递的集成形式加以利用。遗留后端，一个老化的 J2EE 应用程序，将“发布产品”消息放置到一个非常旧版本的 SwiftMQ 提供的队列中。该事件拦截模式在这里很有用，如果作为实现基于内容的路由将允许控制如何路由来自旧后端的消息，并创建一个选项，使消息能够路由到新系统。

集成中间件还处理来自店面的消息（例如用于产品销售），使用 JDBC 直接更新遗留后端后面的主数据库中的状态。通过 SwiftMQ 的异步消息传递和 JDBC 数据库更新共同构成了传统后端和集成中间件之间的接口。

尽管当时没有发现，该团队能够在子系统规模上使用抽象分支模式作为替代遗留中间件的策略。抽象层是队列和 JDBC。通过确保新的实现遵循该抽象层，它可以被替换为“有缺陷的供应商”而不会影响业务运营。

该团队所做的第一件事是通过重构添加一个事件路由器来实现事件拦截。

创建事件路由器 (1) 时考虑了三个主要功能：

高级系统处理：这里选择术语重构，因为系统的结构发生了变化，而没有任何可观察到的行为变化。现在，当用户发布产品时，遗留后端系统仍会将发布消息放置到 SwiftMQ 队列中。事件路由器现在使用来自该队列的消息，而不是使用它的集成中间件，并将其排入队列，不变地，到另一个 SwiftMQ 队列中。集成中间件使用来自这个替代队列的消息，通过简单的配置设置可以进行更改。

将消息从一个 SwiftMQ 队列中取出，并将它们放入另一个 SwiftMQ 队列中 (2)。一些配置的微不足道的更改使集成中间件能够使用来自这个新队列 (2) 的消息。
总的来说，重构使可观察的系统行为保持不变，但事件路由器现在是过渡架构的一部分，已插入到消息处理管道中。
事件路由器的愿景是通过配置将消息路由到替代目的地——使新实现能够处理发布消息。事件拦截
事件路由器还将提供从旧的 SwiftMQ 技术到为目标架构选择的新 ActiveMQ 技术的桥梁。

实现事件路由器并不像它本来的那么简单。由于缺乏可用的驱动程序/库，与 SwiftMQ 的集成存在问题，并且该方法多次受到挑战。该团队了解这种方法将解锁的选项的价值，并完成了工作并发布到生产中。他们在野外监控新组件，并准备使用新的持续交付管道逐步增强其能力。

成功交付零件：构建功能，维护合同

新的店面经理 (1) 现在由团队迭代构建。与此示例相关，该构建包括实现 Legacy Mimic 模式的主数据库适配器 (2)。这是抽象层的一部分，需要使用从店面收到的销售信息更新主数据库。由于事件路由器不转换消息，因此创建了 Legacy Event Adapter (3) ( Message Translator ) 以将消息转换为新格式，而不是将旧世界暴露给新格式，并与新架构的原则保持一致。传统店面适配器(4) 也在新店面经理 (1) 和旧店面之间实施，以将新实施与店面更换时即将发生的未来变化隔离开来。

在旧店面 (5) 上引入了新的店面经理将使用的新 API。此外，还添加了一项功能，可以将在新 API 上发布的产品的回调发送到新店面管理器的适配器 (4)。至关重要的是，这使遗留实现和新实现能够并行运行。

成功交付零件（续）：过渡到实时服务 - 使用第二个接缝

有了所有的部分，企业就能够测试新的解决方案，但如何以风险管理的方式将其推广到实时服务中。

为此，他们利用了另一个接缝——这次使用的是按产品细分模式。事件路由器得到了增强，可以按产品类型和唯一的产品 ID 添加可配置的路由 (6)。该团队能够通过 ID 测试单个产品的发布、管理和销售，然后随着时间的推移为路由器配置越来越多的产品类型，从根本上增加了新解决方案处理的产品百分比。

当所有产品都由新系统处理时，旧的集成中间件退役，实现了许可证、支持和数据中心托管费用的显着节省。

高级系统处理：除非企业另有规定，否则对给定产品的处理与以前一样进行。对于企业乐于通过新系统路由它们的产品，处理现在如下。发布消息被放置在 SwiftMQ 队列中。事件路由器将检查消息有效负载并检查产品制造商。如果已配置，事件路由器会将这条消息原封不动地放到 ActiveMQ 队列中。Legacy Event Adapter 将消息转换为符合目标架构原则的业务事件。New Storefront Manager 应用程序将存储它自己的产品表示，并通过要发布的产品的队列转发命令消息。
根据业务的要求，除了经理通过发出新命令来更改加班时间之外，用户现在还可以操纵产品在店面上的展示方式。
当产品（通过 v2 API 发布）售出时，Legacy Store Front 会回调 Legacy Storefront Adapter 提供的 API，该 API 将调用转换为业务事件并将该事件放置到 ActiveMQ 队列中。新店面管理器和主数据库适配器使用这些事件。新店面经理更新其产品的内部状态，主数据库适配器使用销售信息更新旧主数据库。

改变组织以允许这种情况持续发生

我们的团队已经在组织的另一部分与客户合作，并且已经成功取代了不同的遗留系统。

在整个组织的工程级别，持续交付和良好的支持质量实践现在已成为既定规范，微服务风格的架构支持定期和独立地将容器化服务部署到基于云的平台上。

新计划的团队与新的利益相关者合作，需要在相同的“敏捷和持续交付”之旅中承担业务的另一部分，并且早期风险管理发布能够赢得信任。随着时间的推移，可以证明包括持续交付在内的新工程和质量实践如何减轻历史上导致更高级别官僚主义和治理的相同风险。因此，不那么频繁、更大范围的发布也被更小、更频繁、更高置信度的部署所取代，并在他们准备好接受更改时切换到业务。

结束语

当然，与上面的简化故事所暗示的相比，复杂性和集成要求要高得多。在生产中测试新实现后不久，考古学需求的一个例子就自我介绍了。许多关键业务的管理信息报告不符合要求——产品正在“迷失”。

经过大量挖掘，团队发现集成中间件使用的数据库（用于存储长期运行的业务事务的状态）已复制到组织的数据仓库中。通过大量批处理作业、存储过程和视图，这些数据可用于关键业务 KPI 报告中。

需要额外的 Legacy 模拟来确保这些报告不会中断。该团队对来自店面的销售消息使用 Wire Tap，并使用 JDBC 将数据注入到数据仓库内的适当表中。这些额外的模仿也成为过渡架构的一部分，并在可能的情况下被删除。

抽象分支的方法以及上述模式和实践的使用是一种旨在降低风险的方法。

使用事件拦截（技术接缝）、Legacy Mimics 和 Transitional Architecture 使客户能够解决问题。然后按产品（业务接缝）（在本例中为产品类型）进行细分，从而能够对更广泛的部署进行精细控制并进一步管理风险。总体而言，该方法使企业能够以他们认为合适的速度进行系统更换。

这种方法允许管理风险，但需要付出代价。因此，需要考虑的一个问题是“企业对这种风险缓解有什么价值？” 对其进行明确和量化，将使团队能够根据它跟踪投资。事件路由器和传统模拟是对旨在管理风险的过渡架构投资的一部分。他们的角色是创造能够管理风险的选项。此类工作很容易被视为“扔掉”——因此尽可能避免这种成本。在这种“风险缓解的价值”与“过渡架构的成本”的权衡中要明确和透明。

致谢

Bill Codding、Chris Ford、James Emmott、Kief Morris、Mark Taylor、Meaghan Waters、Peter Gillard-Moss、Rebecca Parsons 和 Simon Brunning 在我们的内部邮件列表中讨论了这些模式的草稿。James Emmott 建议在标题中使用“置换”。

卡片插图中使用的新旧曼彻斯特电车照片由Picasa 提供，经过裁剪和颜色处理。