建设新城区

绞杀植物模式（Strangler Fig）

绞杀植物模式需要注意的是增量演进和并行运行。不可一股脑的构建出新的系统或服务，然后直接替换，这样做的后果是新构建的系统或者服务往往与原系统有很大差异，甚至不可用。

优势：第一，不会遗漏原有需求；第二，可以稳定地提供价值，频繁地交付版本，更好地监控其改造进展。第三，避免“闭门造车”。

劣势：劣势主要来自迭代的风险和成本，绞杀的时间跨度会很大，存在一定风险，而且还会产生一定的迭代成本。

气泡上下文（Bubble Context）

气泡上下文中的气泡指的是用防腐层（Anticorruption Layer）隔离开一个小的限界上下文。

当你遇到一个新的需求时，可以评估这个需求，如果它适合的话，可以不在遗留系统中开发这个需求，而是将它放到气泡上下文中，在一个全新的环境内开发这个需求。由于防腐层隔离了遗留系统，因此你可以在气泡中相对自由地进行领域建模，而不必受到遗留系统的限制。

 就像一些新企业建厂办公（DDD 落地），老城区的空间不够或者条件不适合。那么就会建立一个新城区（气泡上下文），按照更适合这些企业需求的方式规划和布局（应用 DDD 的各种战术模式）。当新城区需要供电供水供暖（数据）时，就拉一条新的管线（基于防腐层的仓库）从老城区来获取这些资源。自治气泡

自治气泡（Autonomous Bubble）

由于新需求中必然有需要建新表的时候，如果建立再遗留系统中，只会让遗留系统更加混乱，因此引入第二种模式：自治气泡。

自治气泡模式有它自己的数据库，与遗留系统是弱耦合的。不直接访问遗留系统的数据和服务，而是通过同步防腐层（Synchronizing ACL），将遗留系统中的数据同步到自治气泡中。同步的方式可以是轻量级的每日同步脚本，也可以是消息或领域事件。

 这就像是新城区中建好了水电气厂，也建好了医院、学校等其他基础设施（数据库），但是工厂的员工、医院的医生、学校的老师（数据）仍然住在老城区，他们需要每天辛苦地通勤到新城区工作（同步数据）。

变动数据捕获（Change Data Capture）

变动数据捕获简称CDC，它能识别和跟踪数据库中的数据变动，并捕获这种变动，完成一系列后续处理，比如：将变动内容发布到一个事件总线中，再由气泡上下文去消费这个事件，从而同步数据；或者干脆直接连接其他数据库进行同步。

一般来说，有两种捕获变动数据的方法。

1.数据库触发器

优势是使用简单。

劣势是大量触发器，很难管理。基于大量数据库触发器的系统，认知负载非常高。

因此使用数据库触发器要慎重。

2.轮询数据库的事务日志（Event Interception）

由于日志本身包含了数据的变动，你根本不需要去解析。工具本身也运行在单独的进程中，也不用担心和数据库产生耦合和竞争。轮询事务日志的做法，可以称得上是最整洁的 CDC 方案。

事件拦截

如果遗留系统是事件驱动（Event-Driven Architecture）的架构，可以使用事件拦截模式拦截系统中已有的事件，为它们编写新的监听程序来进行数据的同步或开始连带的业务处理。不要的时候可以在遗留系统中补充一些缺失的事件。

遗留系统封装API

如果你的一六兄台那个是一个web系统，看最简洁的方式是将遗留系统封装为若干个 API，对外提供业务能力，供各个气泡上下文访问。

 封装API是，要新建API，不要复用老的API。一方面老API是为特定的页面编写的，很难被其他气泡服用。另一方面老页面与气泡的需求变化方向和速率也是不同的，很可能出现为了满足老页面的需求变化而改了API，结果气泡上下文中的功能被破坏了。

 但你仍然需要在气泡上下文中提供一个防腐层，只不过这个防腐层不再直连遗留系统的数据库，而是去访问遗留系统封装的 API。

小结