模型演进

• 数据生产方准备重命名字段并改变枚举含义，下游有十几个团队依赖当前 schema。你会怎样推动这次变更？
• 订单上有一个 status 字段，同时表示履约进度和支付结果，多个团队都在读它。你会怎样把它拆成两个概念，并让旧数据和旧使用方平稳过渡？
• 一个服务资格判断从“当前账户状态”改为“申请时的账户状态加风险审核结果”。客服需要解释历史拒绝原因，审计也要求复现当时的判断。你会怎样演进规则和数据模型，避免新旧结果混为一谈？
• 重复注册导致两个客户实体后来被确认属于同一家公司。合并后报表要统一展示，但历史合同、审批、权限和个人操作仍需保留原始责任。你会怎样设计合并关系？
• 客服工单关闭后，客户补充新证据时可以重新打开，有时还会拆成多个跟进事项。你会怎样设计状态与事件，让关闭、重开和拆分都可追溯？
• 业务规则发生追溯更正，报表需要显示修正后的结果，但决策者还要查看当时依据的旧结果。你会怎样管理两种历史视图？
• 生产者新增一个订单状态后，旧消费者因严格枚举校验拒绝整条消息。团队认为应由消费者更新，但多个消费者由不同组织维护。你会怎样设计兼容性和发布顺序？
• 业务将一项服务的商业规则从免费试用改为满足条件后返还费用，但历史订单仍按旧条款签订。你会如何演进模型和流程，确保新旧交易都能被正确解释？

当前目标在这里暂无匹配题。 切换目标 · 查看全部题目

• 供应商 API 将过去单一的“已交付”状态拆为“已发出”和“已签收”，但历史数据没有区分依据。你会如何更新领域模型、对外接口约定和相关报表？
• 一个数据库字段已被新字段取代，但仍有报表、导出和外部集成在读取旧字段；直接删除会造成静默错误。你会如何规划兼容迁移、消费方确认和最终删除？
• 计费算法从按自然月调整为按服务日计算，新规则只适用于新合同；旧合同跨越发布日，客服仍需解释历史账单。你会如何版本化规则、合同适用范围和账单快照？
• 业务分类会新增、合并或改名。历史报表既要按当时定义复现，也要按当前规则比较。你会怎样保存原始分类、映射版本和报表定义？
• 事件生产方准备把字段从字符串改为结构化对象，但一部分消费者部署周期较长，另一些会把未知字段丢弃后再写回。你会如何安排双写、版本协商、迁移和终止旧格式？
• 历史事件中的客户归属字段被发现写错，需要批量修正并重新计算下游指标；同一事件还可能触发通知和合作方回调。你会如何区分数据重算与重新触发外部操作，并避免重复影响？
• 新业务流程要求所有记录增加一个必填归属字段，但历史数据没有该字段，旧客户端也仍在写入。你会如何设计填充来源、双读写迁移、校验门槛和旧客户端退出？
• 系统将内部用户主键从邮箱改为不可变 ID，但移动端缓存、合作方回调和历史导出仍引用邮箱。你会如何设计映射、双读期、隐私清理和旧引用失效策略？

当前目标在这里暂无匹配题。 切换目标 · 查看全部题目

• 团队准备把资格判断从服务代码迁移到可配置规则引擎，目标是让运营自行调整；历史例外多且规则执行顺序隐含在代码中。你会如何发现规则、验证语义等价并控制配置权限？
• 早期消费者用订单号识别重复事件，后来发现同一订单可有多次合法变更，必须改用订单号加事件版本；历史消息需要重新处理。你会如何迁移去重规则并避免丢失或重复处理？
• 一个客户实体因合并错误被拆成两个真实客户，旧订单、权限和指标都引用原实体 ID。你会如何建模拆分映射、历史归属、当前引用迁移及不可判定记录？
• 多个团队各自定义了用户状态事件，平台计划统一为新的事件模型；某些消费者依赖旧字段的特殊含义，无法一次迁移。你会如何建立兼容适配、并行校验和弃用治理？
• 产品将原本永久有效的额度改为每月刷新，但部分旧合同仍承诺永久额度，用户已累积未用余额。你会如何版本化规则、余额批次、合同切换和用户解释？
• 新模型要求新增特征并调整旧特征含义，线上特征服务还要同时支持旧模型回滚。你会如何版本化特征接口约定、部署顺序、双读成本和退役条件？
• 订单、库存和积分分别由不同服务维护，消息可能重复、乱序或延迟。你会怎样识别事件、避免重复记账并记录补偿？
• 一个产品线拆成两个业务单元，历史订单仍属于旧组织，未来订单按新组织归属。你会怎样表达组织版本和历史视图？

当前目标在这里暂无匹配题。 切换目标 · 查看全部题目