核心数据谁说了算
当多个系统都有同一份用户、组织、账户、订单或商品数据时，判断哪个系统是准的，谁能改，错了谁修。
阅读边界: 主数据治理不是建一张更大的公共表，也不是让数据平台替所有业务背锅。它要解决的是核心对象的权威来源、owner、读写边界、同步契约、一致性窗口和数据纠错责任。
一句话判断: 如果多个系统都能修改同一个核心对象，却没人能说明哪个值是权威值，主数据和 ownership 已经失控。
识别核心对象
定义权威来源
划清读写边界
发布同步契约
处理冲突与修复
持续审计 owner
| 核心对象 | 最常见混乱 | 治理判断 |
|---|
| 用户 / 组织 | 多个系统各自维护状态、身份、归属和组织层级 | 必须明确身份源、组织源和授权源是否同一套系统 |
| 账户 / 余额 | 业务系统、账务系统和支付系统都能改变金额含义 | 金额类对象必须有严格权威账本和审计链 |
| 订单 / 履约 | 订单状态、支付状态、发货状态被混在一个字段里 | 区分主状态、派生状态和外部事实，不要让一个字段承载所有语义 |
| 商品 / SKU | 营销、库存、履约、财务对商品定义不同 | 先定义对象层级和跨域映射，再谈同步 |
权威来源
每个主对象只能有一个最终裁决源；其他系统可以缓存、投影或订阅，但不能偷偷成为第二权威。
数据 owner
owner 不只是表负责人，还要对语义、质量、变更审批、修复和下游影响负责。
读写边界
写入入口要收敛，读取可以分发；越核心的数据，越不能让写路径随业务增长无限扩散。
同步与一致性
明确强一致、最终一致、延迟容忍和冲突解决规则，让消费者知道能依赖什么。
派生数据
缓存、宽表、搜索索引、报表都应被标记为派生，不允许反向覆盖主数据。
纠错闭环
主数据错误要能追溯来源、审批修复、通知下游并审计影响范围。
| 责任项 | 业务 owner | 技术 owner / 平台 owner |
|---|
| 对象语义 | 定义用户、组织、账户、商品、订单等对象在业务里的含义和生命周期。 | 把语义落实到 schema、API、事件、状态机和文档中。 |
| 权威来源 | 决定哪个系统有最终裁决权，哪些系统只是副本或投影。 | 收敛写入口，防止下游绕过权威系统直接写库。 |
| 质量规则 | 定义唯一性、完整性、状态流转、跨系统一致性的业务口径。 | 实现质量校验、监控、告警、差异看板和修复工具。 |
| 变更审批 | 评估字段语义、状态规则、对象层级变化对业务流程的影响。 | 评估兼容性、迁移、回放、消费者通知和回滚 / 补偿策略。 |
| 纠错闭环 | 确认错误事实、业务影响、修复优先级和下游通知对象。 | 执行 dry-run、修复、对账、审计留痕和防复发改造。 |
| 字段类型 | 常见混乱 | 治理动作 |
|---|
| 身份字段 | 用户 ID、手机号、证件、企业编码在多个系统各自生成或覆盖。 | 定义身份源和映射规则，禁止消费者生成第二套主键语义。 |
| 状态字段 | 订单、账户、履约、审批等状态被多个流程同时推进。 | 拆分主状态、外部事实、派生状态和展示状态，写入只能走状态机。 |
| 金额字段 | 展示金额、冻结金额、可用余额、账务余额、支付结果混在一起。 | 以账务或支付权威源为准，派生金额必须能追溯公式和流水。 |
| 组织层级 | 审批、权限、报表、人事系统各自维护组织树。 | 明确组织主系统、有效期、历史版本和下游同步窗口。 |
| 误区 | 为什么危险 | 修正方式 |
|---|
| 把主数据等同于公共字典 | 字典只解决枚举，不解决对象权威和写入责任 | 按业务对象建立 owner、写边界和变更流程 |
| 用同步任务掩盖 ownership 混乱 | 同步越多，越难判断哪个值是对的 | 先定权威源，再设计同步链路 |
| 让数据平台统一兜底 | 平台能提供工具，但无法替业务定义语义 | 业务 owner 负责语义，平台负责元数据、血缘和质量能力 |
| 检查项 | 最低要求 |
|---|
| 对象边界 | 用户、组织、账户、订单、商品等对象的层级和生命周期写清 |
| 权威系统 | 每个核心字段都有唯一权威来源、owner 和变更审批路径 |
| 写入控制 | 写入口、批量导入、后台修复和自动任务都有权限与审计 |
| 同步契约 | 同步频率、延迟窗口、失败重试、幂等和下游通知规则明确 |
| 质量监控 | 有唯一性、完整性、状态机、跨系统一致性和异常修复看板 |
| 登记字段 | 要写清楚什么 | 缺失后的后果 |
|---|
| 对象身份 | 对象名、对象层级、生命周期、主键规则、历史版本和是否允许合并 / 拆分 | 用户、账户、组织、商品等对象边界被不同系统各自解释 |
| 字段权威 | 核心字段、权威系统、业务 owner、技术 owner、可写入口、只读消费者 | 字段被多个系统覆盖，最后没人能判断哪个值是准的 |
| 同步契约 | 同步方式、延迟窗口、幂等键、失败重试、补偿策略和消费者通知渠道 | 下游不知道延迟和失败语义，把最终一致误用成强一致 |
| 变更规则 | 新增字段、修改语义、状态迁移、对象层级变化的审批和兼容要求 | 主对象演进时静默破坏下游报表、权限、账务或接口 |
| 质量证据 | 唯一性、完整性、状态机、跨系统对账、差异看板和修复审计位置 | 质量问题只能靠用户或业务投诉发现 |
| 冲突处理项 | 必须判断什么 | 处理动作 |
|---|
| 值冲突 | 哪些系统给出了不同值？哪个是权威源？冲突是否来自延迟、修复、回放或绕写？ | 以权威源裁决，冻结非权威写入口，补差异修复和消费者通知 |
| 语义冲突 | 同名字段是否承载了不同业务含义？历史数据是否需要版本解释？ | 拆分字段或版本化语义，补数据契约和迁移说明 |
| 状态冲突 | 状态推进是否来自多个流程？是否存在外部事实、主状态和展示状态混用？ | 收敛到状态机，区分主状态、派生状态和外部事实 |
| 修复冲突 | 直接改值会不会破坏账务、审计、权限、报表或下游缓存？ | 先 dry-run 和影响分析，再走审批、修复、对账、审计和回放 |
| owner 冲突 | 业务 owner、数据 owner、系统 owner 对裁决规则是否一致？ | 升级到数据治理评审，明确长期 owner 和例外期限 |
| 场景 | 最小落地包 | 验收信号 |
|---|
| 组织架构在多个系统里不一致 | 先选定组织主系统，冻结其他系统写入口；输出字段 owner 表、同步契约和差异修复清单 | 同一组织在权限、审批、报表里的名称、层级和状态能对齐 |
| 账户余额在业务、账务、支付侧口径不同 | 明确权威账本、派生余额、冻结金额和在途金额；所有修复必须走账务补偿而不是直接改展示值 | 任一金额字段都能说明来源、计算口径和追溯流水 |
| 下游想直接改主数据字段 | 给下游提供变更申请、API 或事件入口；拒绝绕过 owner 的库表写入 | 写路径收敛到权威系统，下游只能订阅或申请变更 |