演进式架构：演进式数据

关系型和其他类型的数据存储无处不在，这种形式的耦合通常比架构耦合更成问题。数据库的演进式设计是指开发人员能够根据需求的不断变化来构建数据库并使其演进。开发人员必须以和代码变更相同的方式处理数据库结构的变更，它们必须是经过检验的、版本化和增量的。利用数据库迁移工具使得开发人员能够对数据库进行小的增量变更，这一过程将作为部署流水线的一部分自动完成。

如果三个应用共用一个关系型数据库，当耦合的应用需要通过数据库模式变更来演进时，可能破坏其他两个应用。常用扩展-收缩重构模式来化解这种耦合。很多数据库重构技术通过在重构过程中创建过渡阶段来避免时间问题。

在重建某个现有的数据库模式时，通常很难达到合适的粒度。很多企业级DBA花费了数十年的时间将数据库模式整合到一起，他们对这种逆向操作不感兴趣。虽然架构师想构建更小的粒度，但如果粒度大小和数据问题不匹配，那么他们的行为将导致不适当的耦合。

大型企业的另一种机能障碍是对数据和数据库的痴迷。认为数据模式是宝贵的，应该永久有效。虽然数据库模式变更的频率比代码低，但数据库模式仍然是对现实世界的抽象，要跟得上现实世界变化的趋势。DBA通常添加另一张连接表来扩展数据库模式定义，这样做短期有效，但它混淆了真实的根本抽象，因为在现实世界中，一个实体是通过多个事物表现的。

遗留的数据库模式和数据具有价值，但它们妨碍了系统的演进能力。架构师、DBA和业务代表需要开展坦诚的对话，讨论哪个对组织更有价值，是永久地保存遗留数据还是进行演进式变更的能力。我们应识别真正有用的数据并将其保留下来，将旧数据作为参考但不将其纳入演进式开发的主流。

拒绝重构数据库模式或拒绝删除旧数据会使架构耦合到过去，这将导致重构难以进行。

只要开发人员应用正确的工程实践，持续集成、代码版本控制等，数据库便可以和架构一同演进。这种可以轻易地变更数据库模式的能力至关重要，因为数据库代表了对现实世界的某种抽象，而现实世界的变化难以预料。在构建演进式架构时，架构师必须将数据当做首要问题。重构数据库是DBA和开发人员需要掌握的技能。