寫在前面
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 (豆瓣)