数仓的数据域和主题域怎么划分？
面试怎么回答
我会先梳理业务过程，再识别核心实体和跨域关系。数据域围绕相对稳定的业务能力划分，例如交易、履约、用户，而不是直接按系统或部门切；主题域围绕分析目标组织，可以消费多个数据域。每个域还要明确核心事实、公共维度、Owner、上下游和变更流程，避免只画分类图却没有责任边界。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
业务希望把订单、支付、退款、广告和用户统一进数仓。有人按来源系统分层，有人按部门建库，半年后同一个“交易域”出现了三个版本。
划域真正解决的是业务边界与责任归属。
稳定的数据域应围绕业务过程和核心实体划分，主题则围绕分析目标组织，不能简单等同于系统或部门。
先梳理业务过程
从下单、支付、履约、退款等事实过程出发，识别参与的实体、事件和状态。业务过程比组织架构稳定，也更适合定义事实表粒度。
再识别核心实体
用户、商品、订单、渠道等实体可能跨多个过程复用。域边界要说明谁拥有主数据、谁提供公共维度，以及跨域关系通过什么一致性键连接。
主题服务分析目标
主题可以围绕用户增长、交易分析、履约效率等问题横跨多个数据域。它是消费组织方式，不必反过来复制一套新的源数据和指标口径。
边界必须带责任人
划域文档至少应包含范围、核心事实、公共维度、上游来源、下游主题、Owner 和变更流程。只有名字没有职责，最终仍会重复建设。
为什么不能只回答概念？
“误区：一个来源系统就是一个数据域”之所以常见，是因为它在理想数据和单次执行里往往说得通。但生产环境会加入数据规模、异常值、并发、版本、失败重试和下游口径，这些条件一变化，只记住术语就很容易给出错误结论。
所以我会把 先梳理业务过程、再识别核心实体、主题服务分析目标、边界必须带责任人 串成一条完整链路。最终判断标准不是某个函数或配置是否出现，而是能否稳定得到可解释、可验证、可恢复的业务结果。
落地时我会检查什么？
- 输入边界：确认数据范围、时间口径、主键和异常值是否符合假设。
- 执行过程：观察分区、并行度、状态、Shuffle 或资源变化，验证方案是否真正生效。
- 输出结果：用行数、唯一性、关键指标和样本明细证明结果正确，而不是只看任务成功。
- 失败恢复：说明重跑、回滚、版本兼容和责任人，避免一次成功后无人维护。
这些检查不一定全部写进一条 SQL 或一个任务，但面试时能主动补充，说明你回答的不是背诵题，而是在描述一套可上线的工程方案。
一个典型场景
一个典型反例是按 CRM、订单系统、支付系统分别建域。退款同时涉及订单与支付，两个团队各算一套退款金额，主题报表只能二选一。重新按交易过程定义事实归属，并把系统来源作为技术维度保留后，业务边界和对账责任才清晰。
系统是数据来源，业务过程才是建模边界。