13.1 Data Mesh 的适用条件：分散责任之前先确认组织问题
销售、履约、人力和设备团队都把数据请求交给中央数据平台。队列越来越长，中央工程师也无法判断“设备可用”究竟按维修状态还是预约状态计算。有人提议采购一套 Data Mesh 平台，仿佛换个工具就能消除组织瓶颈；软件采购很擅长制造这种五分钟的乐观。
Data Mesh 不是产品名称，也不是把数据复制给各团队。它是一种社会技术 operating model：让领域承担可消费数据的长期责任，用共享平台降低重复劳动，再以可执行的联邦规则保持互操作。
这里关注分析数据与历史事实的组织方式。Zhamak Dehghani 的原则说明 将四项原则联系起来；它不是分布式事务协议，也不会自动解决跨域写入的一致性。发布接口可以是 API 或流，但是否用于在线决策，需要另外约定时延和失败语义。
本课目标
- 理解 Data Mesh 四项原则之间的依赖；
- 判断瓶颈来自组织责任、平台还是单个技术问题；
- 划定领域边界和跨域责任；
- 识别不适合或尚未准备好采用 Data Mesh 的场景。
1. 它解决什么规模问题
适合考虑 Data Mesh 的信号通常同时出现：
- 多个业务领域拥有不同语义和变化节奏；
- 中央团队成为需求翻译与交付瓶颈；
- 领域已有长期产品/服务责任和工程能力；
- 跨领域消费频繁，需要可发现、可组合的接口；
- 中央平台可以提供安全、质量和发布的自助能力；
- 组织愿意把数据责任写入团队目标和预算。
如果主要问题只是一个慢查询、缺少 schema 管理或中央团队人手不足，先修具体问题。一个领域、少量数据源的小组织，集中团队可能更清晰、更经济。
2. 四项原则必须共同工作
领域导向的数据所有权
最了解数据生成机制的领域，对可消费数据的语义、质量和演进负责。这里的“所有权”是责任与决策权，不是领域可以绕过安全、隐私或组织政策。
数据即产品
领域为已知和潜在消费者提供稳定、可理解、可信的接口，并持续处理反馈、版本和退役。产品可以是表、流、API、指标或模型特征集合，不等于“清洗过的一张表”。
自助式数据平台
平台提供安全的 paved road：发布、存储、计算、契约、质量、目录、血缘、访问与成本能力。若每个领域仍要自己拼装基础设施，所谓自治只是重复劳动。
联邦计算治理
跨域政策由中央与领域共同制定，并尽可能通过机器可执行的模板、策略和测试落地。自治与互操作在此取得边界。
只做第一项会形成数据孤岛；只做平台会得到更现代的中央数据平台；只贴“数据产品”标签不会改变责任。
3. 领域边界从业务能力而来
领域不应按数据库、报表或组织临时架构随意切割。可参考业务能力、术语、决策和变化所有权，例如：
任务执行域：任务计划、状态和结果
资源域：库存、调拨和消耗结算
装备维护域：设备身份、故障、检修与可用状态同一个词跨域可能含义不同。领域应发布清晰语言和转换接口，而不是强迫所有内部模型完全一致。
边界判断问题：
- 谁能解释并改变规则；
- 哪些数据一起变化；
- 哪些 SLO 由同一团队承担；
- 故障和权限能否隔离；
- 消费者是否需要独立版本。
4. 来源对齐与消费对齐产品
Source-aligned
与领域生成的事实对齐，例如已确认的库存移动事件，保留来源语义并提供稳定契约。它不应只是把内部数据库原样复制给所有人；内部字段与消费接口可以独立演进。
Consumer-aligned
为跨域用例组合多个产品，例如“任务资源效率”。它不应偷偷重新拥有所有上游事实，而要声明派生逻辑、owner 和依赖。
Aggregate/derived
这三种是便于讨论的产品视角，不是互斥的技术层；消费对齐产品也可能同时是聚合派生产品。
指标、特征和分析模型等派生输出也需要产品责任。跨域产品最容易变成新的中央巨石，应明确边界、消费者和退役标准。
5. 所有权不等于把 ETL 扔给业务团队
领域 owner 对结果负责，但实现方式可以协作：
- 领域专家定义语义和验收；
- 数据/软件工程师实现管道与接口；
- 平台团队提供工具、模板和运行保障；
- 治理/安全团队维护共同控制；
- 消费者提供用例和兼容反馈。
如果领域没有预算、人员、on-call 和决策权，却被要求“拥有数据”，责任只是从中央队列转成无人维护。
6. 采用前的准备度检查
[ ] 领域边界和业务 owner 可识别
[ ] 领域能承担持续产品生命周期
[ ] 平台已有或能建设安全的自助路径
[ ] 共同身份、目录、契约和策略基础存在
[ ] 成本能归属但不会阻止合理共享
[ ] 跨域争议有裁决机制
[ ] 首批用例有明确消费者和痛点
[ ] 成功标准不是“发布产品数量”缺项不必等待完美，但要作为显式风险和投资计划。
7. 什么时候不要采用
- 组织想用架构改名回避 owner 冲突；
- 每个团队规模太小，无法承担数据产品运行；
- 基础身份、访问、部署和监控尚不稳定；
- 数据主要由一个清晰领域产生，消费关系简单；
- 管理层只下放责任，不下放人力与预算；
- 预期通过强制全局模型消除所有语义差异。
可以只采用数据产品、领域 owner 或平台自助中的一部分，不必把转型包装成完整 Data Mesh。
8. 迁移从一条价值流开始
选择一个：
- 有真实跨域消费者；
- 当前交付痛点清晰；
- owner 愿意承担；
- 风险可控；
- 能展示平台和治理缺口的用例。
先建立当前基线：交付时间、事件数、消费者等待、质量 SLO、变更失败和平台操作步骤。试点目标是验证 operating model，不是追求一个季度“创建多少数据产品”。
例如只试点“设备可用率日报”：维护域负责检修与停机事实，预约域负责占用时段，消费团队负责“可分配设备”的组合定义。共享设备 ID、时区和观察截止后，再比较接入用时与缺失分区事件；不要求先迁移两个领域的全部数据库。若等待主要来自访问工单，就先验证平台权限流程，不能把所有慢都归给领域边界。
常见误区
- 买一个平台就是 Data Mesh：责任、激励和治理没有因此改变。
- 领域所有权等于各自建技术栈：共享平台正是为了减少重复。
- 组织大了自然要走 Data Mesh：复杂度类型和准备度比人数更关键。
- 所有语义必须全局统一：应统一交互边界，不必抹平领域语言。
练习
- 判断一个中央队列问题是认知瓶颈、平台瓶颈还是资源不足。
- 为订单、目录和库存划分领域边界，并解释一个跨领域术语冲突。
- 区分三个 source-aligned 与 consumer-aligned 产品候选。
- 用准备度清单写出采用、暂缓或局部采用的决定。
小结
Data Mesh 只有在领域责任、产品思维、平台自助和联邦治理同时推进时才成立。先确认组织需要解决的是分布式认知与责任问题，再决定是否承担新的协调成本。
下一课把原则落成接口：一个数据产品交付什么，平台怎样铺路，联邦规则如何自动执行并衡量成效。