3. 领域数据所有权：如何划分数据域？以电商为例拆解用户、订单、商品、支付四大核心域
数据网格的核心思想，就是把数据当作产品来管理。那问题来了——谁来生产这个产品？答案就是领域团队。
说白了，数据网格的第一步，就是要把数据的所有权，从中央数仓团队手里，交还给业务领域团队。但这里有个很现实的问题：怎么划分数据域？划粗了，一个域里啥都有，跟没划一样；划细了，团队之间互相扯皮，数据链路乱成一锅粥。
我这些年看过不少团队栽在这个环节。有的直接把数据库表按模块分一分就完事，结果发现订单域和支付域的数据高度耦合，谁也离不开谁。嗯，今天我们就拿电商来拆一拆，看看用户、订单、商品、支付这四个核心域到底该怎么切。
3.1 数据域划分的核心原则
先定几个规矩。我个人习惯用这三条原则来卡边界：
- 业务职责边界清晰——每个域只对自己负责的业务实体和流程负责。用户域管用户注册、登录、画像；订单域管订单创建、状态流转；商品域管SKU、库存、类目；支付域管支付单、退款、对账。谁的孩子谁抱走。
- 数据变更频率和模式相近——用户数据变化慢，订单数据变化快，支付数据要求强一致性。把变化模式不同的数据放在一个域里，会让数据治理变得非常痛苦。
- 数据消费方明确——每个域产出的数据，要有明确的消费者。用户画像数据被推荐、风控、运营消费；订单数据被供应链、财务、客服消费。如果一个域产出的数据没人用，那这个域要么是多余的，要么是没想清楚。
核心观点：数据域的划分不是数据库表的重组，而是业务职责的重新分配。每个域都是一个独立的数据产品团队，拥有从数据采集、建模到对外服务的完整自治权。
3.2 电商四大核心域拆解
我们拿一个典型的电商平台来举例。你想想看，电商最核心的业务流程是什么？用户浏览商品 → 下单 → 支付 → 收货。这个流程里，四个域的角色非常清晰。
3.2.1 用户域
用户域管的是「人」的信息。包括：
- 基础信息：用户ID、昵称、手机号、邮箱、注册时间、账号状态
- 身份属性：实名认证信息、会员等级、标签
- 行为画像：浏览偏好、购买力分层、活跃度（这部分通常由用户域从埋点数据加工产出）
用户域的数据特点是：相对稳定，但隐私敏感。我在项目中遇到过，有些团队把用户手机号直接放在订单域里，结果每次订单数据同步都要过一遍脱敏逻辑，麻烦得要命。正确的做法是：订单域只存用户ID，用户详情通过用户域的数据服务去拿。
我的建议：用户域应该作为主数据域来建设。所有其他域引用用户时，只使用用户ID。用户域对外提供统一的身份解析服务，这样既保证了数据一致性，也方便做隐私合规。
3.2.2 商品域
商品域管的是「货」的信息。包括：
- 商品基础信息：商品ID、标题、描述、图片、品牌、类目
- SKU信息：规格、价格、库存
- 上下架状态：商品状态、销售时间、活动关联
商品域的数据特点是：结构复杂，变化频繁。一个商品可能有几十个SKU，每个SKU的价格和库存都在实时变动。我记得有一次，订单域直接从商品库读价格，结果商品域改了价格没通知订单域，导致一批订单的价格对不上账。后来我们强制要求：订单域在创建订单时，必须把当时的商品价格快照到订单明细里，不能实时去读商品域的数据。
避坑指南：我曾经见过一个团队，把商品库存直接放在订单域里管理，结果大促期间订单域和商品域同时写库存，数据乱得一塌糊涂。记住：库存是商品域的职责，订单域只能通过接口扣减库存，不能直接操作库存表。
3.2.3 订单域
订单域管的是「交易流程」。这是电商最复杂的域，因为它要串联用户、商品、支付、物流等多个域。包括：
- 订单主信息：订单ID、用户ID、订单状态、下单时间、总金额
- 订单明细：商品ID、SKU ID、购买数量、单价、快照信息
- 订单状态流转：待支付、已支付、已发货、已完成、已取消、已退款
- 物流信息：物流单号、物流公司、收货地址（通常从物流域同步）
订单域的数据特点是：状态多变，一致性要求高。一个订单从创建到完成，可能要经历十几次状态变更。而且订单数据是财务对账的基础，不能出错。
这里有个关键点：订单域应该持有自己的数据副本，而不是实时去其他域读数据。比如订单明细里的商品快照，就是下单那一刻的商品信息，之后商品域怎么改都不影响这笔订单的历史记录。
3.2.4 支付域
支付域管的是「资金流」。包括：
- 支付单：支付单ID、订单ID、用户ID、支付金额、支付方式、支付状态
- 退款单：退款单ID、原支付单ID、退款金额、退款原因、退款状态
- 对账数据：渠道对账单、平台应收应付、差异记录
支付域的数据特点是：强一致性，审计要求高。支付数据不能丢，不能错，不能乱。我建议支付域的数据存储使用事务性数据库，而不是普通的分析型数仓。支付域的对外数据产品，应该以「对账报表」和「资金流水」为主，而不是让其他域直接查支付表。
3.3 域间数据交互：如何避免耦合？
域划分好了，但业务是连着的。订单域需要用户信息，支付域需要订单信息，商品域需要知道哪些商品卖得好。怎么交互？
我的经验是：域间只通过数据契约交互，不直接访问对方的数据存储。数据契约可以是：
- 事件：订单创建后发布「订单已创建」事件，支付域订阅后创建支付单
- API：用户域提供用户信息查询接口，订单域通过接口获取用户详情
- 共享数据视图：支付域定期产出「支付对账宽表」，供财务域消费
下面这张图展示了四大核心域之间的数据流转关系：
3.4 数据域划分的常见误区
最后聊几个我见过的坑，你对照一下自己的项目，看看有没有踩中的。
| 误区 | 表现 | 后果 | 正确做法 |
|---|---|---|---|
| 按数据库分域 | 用户表归用户域，订单表归订单域 | 域间耦合严重，数据链路混乱 | 按业务职责分，每个域包含完整的数据产品 |
| 域内数据过多 | 一个域包含几十张表，职责不清 | 团队协作困难，数据质量下降 | 一个域只负责一个核心业务实体 |
| 域间数据重复 | 多个域都存用户手机号 | 数据不一致，维护成本高 | 用户域作为主数据源，其他域只存ID |
| 忽略数据契约 | 域间直接查对方数据库 | 数据安全风险，耦合度高 | 通过事件或API交互 |
我曾经见过一个团队，把「订单域」和「交易域」分开，结果两个域都管订单状态，线上出了好几次数据不一致的事故。后来合并成一个域，问题才解决。记住：数据域的划分不是越细越好，而是要找到业务职责的自然边界。