Autonomous bubble pattern | 雷达哔哔哔

写在前面

ThoughtWorks每年都会出品两期技术雷达，这是一份关于科技行业的技术趋势报告，在四个象限：技术、平台、工具以及语言和框架对每一个条目（Blip）做采用、试验、评估、暂缓的建议。（第十九期雷达已发布，点击文末[阅读原文]下载）

一直以来，我们都未对每一个Blip做进一步的解读，而这次决定尝试一个新的专栏——《雷达哔哔哔》，由作者根据自己实践与理解，对雷达中部分条目作出解析，致力于用一篇篇短小精悍的文字，帮助读者加深对雷达的理解。

今天是《雷达哔哔哔》的第四篇，依然关注架构，Blip是Autonomous bubble pattern。

位置

2018年5月第18期技术雷达，技术象限，建议试验

标签

遗留系统、DDD、Bounded Context、ACL、Eric Evans

目标受众

系统架构师

关注问题

如何在遗留系统上继续保持构建新功能的能力，不受自身的限制与拖累，可以采用全新的架构甚至工程方法，同时保持相对独立的快速演进？

解决方案

将新的功能和能力封装到新的独立上下文中，建立独立且完全自主控制的数据存储，采用同步的机制保证与其他上下文的数据一致性，形成完整独立的Autonomous bubble，用同步复杂性换取上下文完整性。

解读

之前在介绍Architectural fitness function时，我们谈到无论一个系统初建时多么新潮且纯粹，都会随着时间的洗礼，慢慢成熟，慢慢衰老，就像我在《技术的一生》中描述的场景一样。

碰到这种情况，我们通常会首先想到推倒重建，希望可以重回初生时的美好。但往往斥重金重建系统、短暂享受重获新生的喜悦之后，依然无法逃离时间和需求的侵浊，再一次走向衰老，成为另一个崭新的遗留系统。

有没有两全其美的方法，既能保持对于遗留系统足够敬畏，不用花费大量成本冒风险重建；又能应用新的技术和架构甚至工程方法为系统构建新的功能和能力，在老树上开出“新花”？

我们发现DDD(Domain-Driven Design)的作者Eric Evans早在2012年就提出的一种叫做Autonomous bubble pattern(自治气泡模式)的模式，对于解决这样的问题越来越有其用武之地。

这种模式乍一看，并无新奇之处，无非就是为新的功能或是应用创建一个新的限界上下文（Bounded Context），在新的上下文里采用全新的设计，并通过Anticorruption Layer（ACL：防腐层）匹配旧的遗留系统而已，常见的应用场景就像Eric Evans在视频中展示的一样：

但Eric Evans提出的Autonomous bubble pattern并不止于此。 精妙之处在于，他提出了另一种看似更复杂的解决方式，即为新的上下文提供完整的数据存储能力。并通过同步（Synchronizing）的方式保持新的上下文与遗留系统中的数据一致性，如下图。

Eric Evans在视频中也坦言，这种方式相比与第一个方案会更加“昂贵”，需要一些额外的工作来处理开发者们最为头疼的“同步”问题。

但我们认为由此带来的“上下文自主性”和“对于开发摩擦力（development friction）的减少”，是迈向现代化甚至未来架构的第一步，也是重要且勇敢的一步。

支持工具

DDD

延展阅读

• Four Strategies for Dealing with Legacy Systems – Strategy 2, Autonomous Bubble (3/5)
• Domain-Driven Design (豆瓣)