主题域划分方法
主题域按业务对象聚类：会员域、商品域、交易域、履约域、财务域是常见划分。边界以业务过程的归属为准，同一个过程只属于一个域，避免同一份数据在两个域各算一次。跨域交互通过一致性维度连接，而不是让一个域直接读取另一个域的明细表。划分粒度上，域与组织分工对齐能显著降低协作摩擦，但也不要跟着组织频繁调整，否则模型会随组织变动反复摇晃。
基本信息
| 划分依据 | 业务对象与业务过程的归属 |
|---|---|
| 边界原则 | 归属清晰、低耦合，一个过程只属一个域 |
| 交互方式 | 跨域通过一致性维度连接，不直读明细 |
| 常见划分 | 会员、商品、交易、履约、财务、营销 |
典型使用场景
- 数仓分层规划：先定域再定表，避免表归属反复迁移
- 团队分工：每个域设唯一 Owner，问题有明确责任人
- 权限治理：按域授权，敏感域（财务、会员）访问范围可控
- 口径评审：域内口径由该域 Owner 审批，跨域变更走联合评审
- 新业务接入：先判断归属哪个域，再决定复用还是新建模型
域与过程归属
域与过程归属
主题域示例：会员域 / 商品域 / 交易域 / 履约域 / 财务域 / 营销域 # 按业务对象聚类
交易域包含过程：下单、取消、支付、退款 # 一个过程只归一个域
履约域包含过程：发货、签收、退货入库
跨域取值规则：通过一致性维度（日期、用户、商品）连接，不直读对方明细表
边界校验：同一业务过程是否在两个域各建了一张事实表 # 出现即为边界不清边界自检
| 检查项 | 通过标准 | 常见问题 |
|---|---|---|
| 数据主责人 | 每个域唯一 Owner | 两张表都是主责，变更互相打架 |
| 跨域取数 | 走一致性维度，不直读明细 | 直读导致上下游强耦合 |
| 口径变更 | 域 Owner 审批并公告 | 各自修改后口径分叉 |
| 域边界 | 跟随业务对象而非频繁调整的组织 | 组织一变模型就跟着改 |
域划分与组织分工对齐能降低协作摩擦，但域的粒度不宜过细：域太多会导致跨域连接无处不在，一致性维度反而成为瓶颈。
边界是否清晰有一个简单检验：任何一个业务过程，能否在三分钟内说出它归属哪个域、由谁负责。答不上来说明划分还需要修订。