上篇：数据可靠性闭环
咖啡豆促销分析稳定后，业务希望支持杯子、多门店和新渠道。看起来都是销售与退款，是否复制原模型即可？又是否应该把所有业务合成一套定义？
本篇讨论模型怎样复用与演进。案例和方案为教学设计，不表示已经完成真实系统迁移。
一、完整闭环：让新需求进入已有建设
理解新需求 → 比较共性与差异 → 选择复用、扩展或拆分 → 评估下游影响 → 验证并迁移 → 观察使用 → 调整边界或退役。
复用减少重复劳动，也增加共同维护和变更责任。需要共享的是稳定共性，有价值的业务差异应当被清楚保留。
二、先判断新需求究竟哪里不同
咖啡豆是消耗品，杯子的购买周期可能更长；门店回购与全链回购关注的范围不同；线上渠道的配送和平台费用又可能不同。
因此，支付、退款等事件定义和标识可以共享，复购窗口、成本范围和经营归属则需要分别确认。不能因为字段都叫customer_id，就假设不同来源已经识别同一个人；也不能拿同一个30天复购率评价所有商品。
| 新需求 | 判断方向 |
|---|---|
| 新增商品或门店 | 维度成员与编码映射能否直接扩展 |
| 新增分析属性 | 属性粒度、历史规则和覆盖是否明确 |
| 新增同粒度度量 | 含义与已有事实是否一致 |
| 新增不同粒度过程 | 是否应建立独立事实模型 |
| 新经营定义 | 新指标或新版本，而非悄悄覆盖 |
三、把历史变化与规则变化分开
商品从普通咖啡调整为精品咖啡。若要按销售发生时分类解释历史，就需要保存相应属性历史；若明确只按当前分类重看过去，则可以采用另一种规则，但历史分组结果会随之变化。
错误纠正、真实业务变化与"不保留历史"的选择，需要明确区分。Kimball对缓慢变化维度的讨论也强调，覆盖属性会改变历史观察及相关汇总，处理方式应有明确政策。Kimball：Slowly Changing Dimensions
另一方面，活动贡献从不扣广告费改为扣广告费，是指标含义变化，不能仅依靠维度历史解决。需要记录新定义、适用范围、生效版本，以及历史是否按新口径重算。
四、变更之前，先找出谁会受到影响
影响范围不止一张表，还包括上游来源、字段、加工任务、汇总、报表、接口、导出和使用方保存的结果。血缘可以帮助查依赖，但业务负责人和实际使用记录仍需核实。
例如，改变渠道归属会影响历史贡献排名、门店考核和活动预算。如果只改代码，使用者可能把口径变化误认为经营变化。
变更说明应讲清为什么改、新旧差别、影响范围、可用时间、使用方需要做什么和出问题找谁。字段新增也要检查默认值和消费者假设，不能一概认为天然兼容。
五、先核对差异，再逐步迁移
为新逻辑准备正常与边界样例，在限定范围形成新结果，与旧结果并行比较。新定义造成的预期差异应能解释，无法解释的差异继续排查。
确认后，按约定范围逐步切换使用方，记录当前版本、迁移进度和验收情况。旧定义在兼容期仍有明确用途，不能提前删除。
同一规则下的迟到退款属于数据更新；新增成本范围则属于语义变更。核对时要把输入变化、规则变化和实现错误分开，否则差异无法解释。
六、恢复要覆盖数据和使用行为
发现问题后，可能需要停止新版本、恢复读取旧结果、修正并重算历史。回退代码并不自动恢复已经覆盖的数据、旧汇总或被下载的报表。
如果业务已经据新结果增加投放，技术回退也不能撤销该动作。要保留已发生记录，由负责人评估后续处置。迁移之前应明确备份、兼容期、恢复范围和实际可恢复程度。
七、复用边界不合适时，也允许收缩
如果共享模型持续堆叠互相冲突的门店例外，可能说明边界过宽，需要按业务上下文拆分；如果公共汇总长期无人使用，可以评估合并或退役。
退役先确认依赖，提供替代与迁移期限，再停止服务。停止服务不等于随意删除需要保留的历史证据。评价复用也要观察接入等待、支持负担和变更成本，不能只看接入方数量。
八、快速复习
先识别差异，再决定共享；先明确历史和版本，再修改结果；先找依赖、核对差异，再迁移；最后根据价值和维护代价调整边界。
闭卷解释：商品分类变化和贡献公式变化为什么需要不同处理？前者涉及属性历史与观察视角，后者改变指标语义；两者都可能影响下游，但不能靠一种机制全部解决。
阅读入口
《数据仓库工具箱》第3版第3章的模型扩展、第4章总线架构与第5章缓慢变化维度，是理解复用和历史的入口。本文迁移、恢复和退役路径为工程教学扩展。