以事务变化的节奏划分边界

以相同速度变化的事物应该聚在一起，以不同速度变化的事物应该分开。

Things that change at the same rate belong together. Things that change at different rates belong apart.

— Kent Beck

近期，讨论完一个技术方案的时候又想到了这句话，我想先举两个例子：

Java版本的发布节奏大约是两三年一次，对于大部分项目来说，升级的频率很低。

继二战结束、苏联解体之后，世界上国家的数量基本保持稳定，很适合内置在Java中。

但是手机号码的区段，这随着各个国家手机号段的划分，电信运营商的变化而变化，自然不适合随着语言发布，Google也是有一个libphonenumber的library。

近期讨论的一个方案是数据集成相关的，从原子能力的规划上，如何把文档、数据表提取成模型、实例数据，是做成一个pipeline一往无前，还是将模型、实例阶段分割。

如果只看第一次执行，这两种方式似乎差不多。无论输入是文档还是数据表，都先提取出模型，再根据模型生成实例。把它们串成一条 pipeline，输入进去，结果出来，整个过程也很好理解。

模型和实例的变化节奏可能并不一致。一个业务领域的概念和关系，在一段时间内可能相对稳定；而这个领域中的具体数据，却可能每天都在增加或变化。

同样，文档和数据表也可能有不同的更新方式。一份业务文档，在某个版本确定后，可以先进行一次提取；而业务数据表还在持续产生新的记录，需要不断同步。

因此，模型构建和实例构建虽然有依赖关系，却不一定需要共享同一个执行周期。它们可以拆成相互衔接的阶段：模型阶段把文档和数据表中的信息结合起来；实例阶段再根据不同来源和需求，选择一次提取、定期更新或者持续同步。