2. 领域所有权

数据网格的核心，说白了就是「谁生产谁负责」。

我刚开始接触这个理念时，觉得这不就是分模块嘛，有什么新鲜的？但真正落地才发现，领域所有权的定义，直接决定了数据网格的成败。搞不好，就会变成「数据孤岛 2.0」。

这一章，我们来聊聊怎么定义数据领域、怎么划分职责、以及我踩过的那些坑。

2.1 什么是数据领域

数据领域，不是数据库里的一个表，也不是某个微服务的边界。它是一组高内聚、低耦合的数据集合，由同一个业务团队负责端到端的生命周期。

举个例子：

• 订单领域：包含订单创建、支付、退款、物流等数据
• 用户领域：包含注册、登录、权限、画像等数据
• 库存领域：包含商品库存、仓库调拨、盘点等数据

每个领域的数据，只能由对应的团队修改。其他团队想用？只能通过接口或事件订阅。

我记得有一次，一个团队把「用户行为日志」划给了「用户领域」。结果用户团队根本不懂埋点，日志质量一塌糊涂。后来我们重新划分，把行为日志归给了「数据平台领域」，问题才解决。

2.2 领域所有权的职责划分

所有权不是嘴上说说，得有具体的职责清单。我习惯用一张表来定义：

职责项	说明	常见误区
数据建模	定义领域内的数据模型、字段、关系	让数据平台团队代劳，导致模型脱离业务
数据质量	保证数据的准确性、完整性、及时性	只关注写入，不关注消费端反馈
数据产品化	将数据封装为可复用的数据产品	直接暴露原始表，没有文档和SLA
数据治理	管理元数据、血缘、权限、生命周期	认为治理是「平台的事」
数据消费支持	响应下游团队的数据需求、问题排查	「数据给你了，用不好是你的事」

2.3 如何识别和划分数据领域

这是最头疼的部分。我见过不少团队，一上来就照着微服务划分，结果数据领域和微服务边界对不上，乱成一锅粥。

我自己总结了一套「三步法」：

1. 找业务事件：列出所有核心业务事件，比如「用户下单」「商品上架」「支付成功」
2. 找聚合根：每个事件背后，谁是数据的主体？订单、商品、用户……这些就是候选领域
3. 找依赖关系：领域之间怎么交互？是强依赖还是弱依赖？强依赖的考虑合并，弱依赖的保持独立

举个例子：

业务事件：用户下单
聚合根：订单（Order）
依赖：用户（User）、商品（Product）、库存（Inventory）

业务事件：支付成功
聚合根：支付（Payment）
依赖：订单（Order）、账户（Account）

业务事件：商品上架
聚合根：商品（Product）
依赖：类目（Category）、供应商（Supplier）

这样梳理下来，我们就能得到几个清晰的候选领域：订单、用户、商品、库存、支付、账户、类目、供应商。

2.4 领域划分的常见模式

根据我的观察，领域划分有三种主流模式：

模式	适用场景	优点	缺点
按业务能力	业务边界清晰，团队组织与业务对齐	自然、易理解	容易忽略跨领域数据
按数据特性	数据量大、实时性要求高	便于优化存储和计算	可能割裂业务逻辑
按组织架构	团队职责明确，避免跨团队协调	落地阻力小	容易变成「数据竖井」

我个人更推荐按业务能力作为起点，再根据数据特性做微调。组织架构应该跟着领域走，而不是反过来。

2.5 领域所有权落地检查清单

每次划分完领域，我都会用这张清单过一遍：

• ✅ 每个领域是否有明确的业务负责人？
• ✅ 每个领域的数据模型是否独立演化？
• ✅ 领域间的依赖是否清晰、可控？
• ✅ 每个领域是否发布了至少一个数据产品？
• ✅ 领域团队是否具备数据治理的能力？

如果有一项不满足，我建议先别急着推进，把问题解决再说。

2.6 领域所有权与数据网格的关系

下面这张图展示了领域所有权在数据网格中的位置：

从图上可以看得很清楚：数据网格的底层单元就是领域，每个领域拥有完整的数据生命周期管理权。上层的数据网格只负责提供基础设施和治理规范，不干涉领域内部的数据决策。

2.7 小结

领域所有权是数据网格的基石。定义得好，团队协作顺畅，数据质量有保障；定义得不好，还不如用传统的数据仓库。

我个人建议，刚开始不要追求完美，先划出 3-5 个核心领域跑起来，再根据实际反馈调整。迭代，才是数据网格的精髓。