企业官网建设流程全解析

1. 面试官真正想从这个问题里听到什么

1.1 这不是考你背模型，而是考你的业务拆解能力

最近我参与了好几次数据方向的线下面试，发现“一个新的业务如何设计数据域”这个问题出现频率越来越高。不光是数据仓库工程师，连数据分析、数据产品岗位也经常被问到。很多人一听就开始报概念：先分主题域，再分数据域，再建总线矩阵……但面试官往往追问两句就发现你只是背了流程，并不知道每一步到底在做什么、为什么这么做。

很多候选人把这道题当成一道背诵题，张口就是“数据域是业务的抽象，要按业务过程划分”之类的话。这句话本身没错，但干瘪得让人没法接。面试官真正想观察的是：你站在一个全新业务面前，有没有办法在信息不完整的情况下，快速找到业务的关键骨架，并且把它转化成数据层面可落地的结构。

我举个例子你就明白了。同样一道题，A候选人的回答是：“新业务来了先看业务流程，把核心业务过程找出来，比如下单、支付、发货，再根据这些过程分域，一般有用户域、交易域、商品域……” B候选人的回答是：“我会先问几个问题：这个业务是To C还是To B？它的收入模式是什么？核心用户是谁？用户从了解到付费要经过哪些关键动作？只有先搞懂这些，我才能判断域应该往哪个方向切。比如同样叫交易，电商平台的交易和内容平台的打赏交易，建模重点完全不同。” 两个人高下立判。

B的回答好在哪里？好在它展示了三个能力：第一，面对不确定问题会先澄清，而不是急着给答案；第二，知道数据域设计的起点是“业务理解”，而不是“技术模板”；第三，说明他脑子里有多个业务的横向对比，能把通用的方法论落到具体场景里。这三个能力恰恰是数据团队日常工作中最需要的。

所以面试的时候，请记住一个判断：这道题考的不是你知道多少概念，而是你在没有标准答案的世界里，能不能自己构建出一套合理的思考框架。数据域设计本来就不是数学题，没有唯一解，但思路的闭环是看得出来的——从业务到过程、从过程到分类、从分类到标准，最后还能回到业务上去校验，这就算合格。

1.2 五分钟内能不能把自己的思考路径讲清楚

这道题在面试里通常不会给你半小时慢慢画图。多数情况下，你需要在五分钟内先给出一个整体框架，然后面试官再针对其中一点追问。这意味着你的回答必须有结构，不能想到哪说到哪。

我给一个比较稳的回答框架参考：先澄清边界，再讲方法论，最后用一个微型案例落地。澄清边界是为了确认这个“新业务”大概是个什么形态、数据团队在里面处于什么阶段；方法论是告诉大家你打算分几步做；微型案例是用来证明你不是空谈，而是真的能操作。整个回答控制在五分钟左右，剩下的时间留给面试官追问。

这里有一个细节容易被忽略：很多人在回答时会把“数据域”和“主题域”混着讲。面试官只要追问一句“你说的这个跟主题域有什么区别”，就会暴露概念不清。数据域是从“业务视角”切的一块一块的横向分类，比如交易域、商品域；主题域则通常是面向分析主题的纵向聚合，比如复购分析、用户生命周期研究。这两者的切分逻辑不同，回答的时候要有意识地区分开。如果你能把这一层讲明白，面试官对你的印象会明显上一个台阶。

2. 先厘清前提：数据域解决的是什么问题

2.1 数据域不是表，而是一层“业务的建模逻辑”

在开始设计之前，你得先回答一个问题：数据域到底是干嘛的？如果这个问题想不清楚，后面的设计一定会变形。

我习惯用一个比喻来解释数据域。想象一家公司是一栋大楼，每个部门是楼里的一个房间。数据域就是楼层间的功能区划分——这层是研发区，那层是商务区，再上面是活动区。你当然可以不分区，把所有人塞在一层楼里也能办公，但一旦公司变大、人变多，找一个人就要翻遍整栋楼，效率会极低。数据域也是这个道理：当表数量从几十张增长到几千张，数据平台从一两个人维护变成多个团队协作，如果没有一个清晰的分区逻辑，大家根本不知道某张表该归谁管、某个指标该去哪找。

但这里要特别强调一个概念：数据域不是某张表，也不是某个物理数据库，它是一层“逻辑上的业务建模标签”。你可以在元数据层面给每一张表打上域标签，但域本身是一种组织业务信息的方式。这个认知会影响你后续的所有决策。比如你建表的时候会先想“这张表属于哪个域”，而不是先想“这个表叫什么名字”。

还有一个常见的误解是，数据域一定要有物理载体。有人觉得我建一个数据库，名字叫交易域，把相关表都放进去，就是分好域了。这当然是一种实现方式，但放到数仓体系里看，域更重要的价值是元数据层面的治理：一张表在物理上可以放在任何计算引擎里，但只要它在元数据中的归属是交易域，全域的知识检索、权限分类、成本核算都会自动跟着走。你可以把域理解成给每张表盖上的“业务印章”，盖完章之后，无论表跑到哪里，大家都知道它归谁管、属于哪个业务板块。

2.2 为什么按业务切，而不是按系统切、按团队切

这是面试里很容易被追问到的一个点：你说按业务分域，那为什么不能按系统分、按团队分？这个问题的回答，决定了你是真正理解了数据域设计的本质，还是只是记住了结论。

按系统分域的最大问题是，业务是跨系统的。一个订单从产生到完结，可能经过前端、交易、支付、物流好几个系统，如果按系统切，你会在每个系统里都看到条目残缺的订单，数据就碎了。按团队分域就更危险，今天组织架构一调整，你的数据域就得跟着变，维护成本极高。业务过程相对稳定，只要这个公司的商业模式没变，下单、支付、履约这些动作就会一直在，所以按业务过程来分域是最抗组织变动和系统演进的。

举个具体例子。用户在交易系统里下的单，到支付系统才扣款成功，再由物流系统发货。如果按系统分域，同一笔订单会在三个域里各出现一次，分析师要关联它们就得跨三个域来回跳。按业务过程分域时，下单、支付、发货都挂在交易域下面，它们在物理上可能是不同表，但在逻辑上属于同一个域，找数据的人一眼就能明白它们之间的关系。

这个逻辑也解释了为什么业界很多成熟的分层方案，都会把“业务过程”当作域设计的核心抓手。业务过程回答的是“业务发生了什么动作”，比如注册、下单、退款、评价。数据域是基于若干高度相关的业务过程聚合出来的一个大分类，比如所有跟“交易”相关的动作聚合为交易域，所有跟“商品”相关的动作聚合为商品域。切开之后，不同域之间的界限要尽量清晰，避免两个域反复重叠。你把这个逻辑讲清楚，面试官就基本确认你是有实际建模经验的人，而不是只会背教科书。

3. 新业务设计数据域的五步落地方法论

3.1 第一步：先梳业务全流程，画出一张业务链路图

拿到一个新的业务，我做的第一件事不是打开建模工具，而是拉上业务方，把业务从起点到终点的完整链路走一遍。比如一个二手车交易平台，链路大概是：用户注册登录、看车、线上咨询、预约看车、线下验车、谈价、签约、过户、金融贷款、交付、售后评价。你把这个链路画出来，数据域的设计就有了原材料。

这一步有两种常见做法。一种是从“用户旅程”出发，站在用户视角把体验链路走一遍，特别适合To C业务；另一种是从“价值链条”出发，把业务赚钱的每个环节列出来，特别适合To B或者平台型业务。场景不同，切入角度不同，得到的业务环节清单会有差异，但这没关系——你要的是完整性和逻辑闭环，不是唯一标准答案。

实操上建议用一个思维导图把流程写下来，每个节点标注一件事：这个环节有没有产生数据？产生了哪些关键实体？这一步不需要精确到字段，粗略即可。整个梳理过程控制在1到2次沟通以内。实际工作中，新项目启动的第一周，核心任务就是干这个。很多团队一上来就急着建表，结果表建到一半才发现漏了关键环节，返工成本极高，根子就在跳过流程梳理这一步。

3.2 第二步：识别核心业务过程，找到真正值得建模的动作

业务链路画完之后，下一步是把它翻译成一个个“业务过程”。业务过程中的“过程”两个字，说的是那些在业务上真正有意义的、会产生数据记录的动作。还是说二手车：用户注册是过程，用户看车这个“浏览”也是过程，预约、验车、签约、过户、付款，每个都是过程。

这里有个筛选小技巧：判断一个动作够不够格当业务过程，就问三个问题——这个动作在业务上有没有独立的商业含义？它有没有可能被单独分析（比如“转化率”就是分析每个过程的漏斗）？它会不会产生一对多的数据记录？如果三个答案都是是，它就是一个需要建模的业务过程。反过来，那种单纯的页面曝光级别的动作，除非浏览行为本身就是业务核心，否则通常归为流量域里的明细行为，而不是单独的业务过程。

建议把识别出来的业务过程用统一的动宾结构命名，比如“提交订单”“支付成功”“完成退款”，不要一会儿动词在前面一会儿动词在后面。命名规范是一件看起来不起眼、实际影响极大的事，因为数据域的名称、表的命名、指标口径全都挂在这套动词体系上。命名乱了，后面的治理全是雷。

3.3 第三步：把业务过程聚成域，命名和边界一次想清楚

有了业务过程清单，接下来就是“聚类”。这步有点像在给一大筐水果分类：你可以按颜色分，也可以按种类分，关键是你得定一个统一标准，并把它讲给别人听。数据域的聚类基准通常是“业务语义的亲和度”——几个业务过程在业务上是不是天然围绕同一个核心实体或核心环节展开。

比如电商场景里，登录、注册、会员等级、积分这些都围绕“用户”，归到用户域；收藏、加购、浏览、评价围绕“商品与交易决策”，可以归到商品域或者流量域，具体看公司的分析重点；下单、支付、退款、开票围绕“交易”，归到交易域。注意，这里没有绝对正确答案，不同公司因为业务重心不同，完全可能把一个过程分去不同的域。比如“评价”在社区型公司可能属于内容域，在零售公司则属于交易或商品域。

聚类完成后要给每个域起名字，并写一句边界描述。边界描述里要写清楚“这个域包含什么、不包含什么、跟相邻域的边界在哪里”。比如交易域的边界可以写：“包含所有与订单交易直接相关的业务过程，包括下单、支付、退款、开票；不包含用户注册与商品上下架，这些分别属于用户域和商品域。” 这段描述写得好不好，直接决定后面表治理会不会吵架。

3.4 第四步：拿回去跟业务对焦，把冲突提前暴露出来

很多新手走到第三步就觉得完事了，实际上恰恰漏了最关键的一步——把域划分结果拿回去给业务方看一遍。数据域不是数据团队自娱自乐的结构，它未来要承接各种业务分析需求，如果业务方看到你的划分觉得“这个跟我们的业务逻辑对不上”，后面一定会返工。

对焦时要注意几类典型冲突。第一类是“口径冲突”：业务方对“交易”的理解跟你不一样，比如他们把“已下单未支付”也算交易，你可能默认算在交易域但指标口径不同。第二类是“归属冲突”：某个过程你觉得该归A域，业务方觉得该归B域，这时候不能靠拍脑袋，要看这个过程的“主分析场景”是什么，让分析用得最多的一方来定。第三类是“命名冲突”：业务内部已有约定俗成的名称，尽量沿用，不要为了优雅而自创一套。

对焦这个动作，其实是把数据域从“理论模型”推向“组织共识”的关键环节。我见过不少团队，技术上域划分得很漂亮，结果上线后发现业务不认，指标口径天天吵，最后域规范成了一纸空文。根本原因就是跳过了这一步，把设计当成了一次性交付的图纸，而不是需要持续对齐的契约。

3.5 第五步：从域往下拆，建立域到表的映射关系

域划分好之后，还要继续往下走，把每个域里的表组织起来。这一步通常会碰到另外两个概念：业务过程明细表、维度表。业务过程明细表是一张记录每个过程事实的表，比如订单明细表、支付流水表；维度表是描述业务对象属性的表，比如用户维度表、商品维度表。在规范的分层数据仓库里，一般建议在明细层尽量保持“一个业务过程对应一张明细表”的原则，维度则是跨过程共享的。

也就是说，你回答“如何设计数据域”的时候，如果能顺带说出“域下面挂什么、域之间怎么共享”，会让面试官觉得你对整个建模链路有全局观。比如你可以提一句：交易域里会有订单事实表、支付事实表、退款事实表，这些事实表共享用户维度和商品维度，而维度表会放在公共维度层，由专门的负责人维护。这比单纯报一遍“用户域、交易域、商品域”这种空名高明得多。

这一步的产出里，还有一张非常重要的东西叫“总线矩阵”。行是业务过程，列是公共维度，中间打勾表示该过程关联该维度。有了这张矩阵，团队做表的时候，每张事实表需要用哪些维度、维度里的字段口径从哪来，全都一目了然。这一步做完，数据域设计才算真正从“分类”走到了“可落地建模”。

4. 模拟案例：某同城跑腿业务的数据域设计全过程

4.1 先问边界，再给假设，把模糊问题变具体

光讲方法论太虚，我们拿一个具体的模拟案例走一遍。假设面试官突然给你一个新业务：某同城跑腿平台，用户在APP上下单，让骑手帮忙取送物品，平台按距离和重量收费。这个业务当前只有一套简单的订单库，数据团队刚成立，老板要求建立规范的数据体系。

如果你能稳稳地先问出几个关键问题，面试就已经赢了一半。我会问：这个平台是自营骑手还是众包骑手？是否有自己的仓储？主要客群是个人用户还是企业用户？目前最关心的分析指标是GMV、履约时效还是用户留存？这些问题直接决定了数据域的划分重心。比如如果自营骑手占比高，运力管理就是一个核心域；如果更多是撮合模式，那用户与骑手的匹配效率就非常关键。

提醒一句：面试里提问不是象征性走过场，而是确认边界之后给出你的默认假设。比如你可以说：“如果按行业常见模式假设——众包骑手、个人用户为主、核心指标是订单量与履约时效——我会这样设计……” 这样既展示了澄清能力，又不会因为问不到答案就停摆。面试官其实不怕你问问题，怕的是你连问题都想不出来就硬答。

4.2 基于假设的域划分结果

基于上面的假设，我会把这个跑腿平台的业务过程先列出来：注册、登录、下单、支付、接单、取件、送达、评价、退款、骑手入驻、骑手审核、骑手接单、结算、申诉、营销活动发放与核销。然后聚成下面几个数据域：

注意我特意加了“运力域”而不是叫“骑手域”，这是个很容易忽略但很关键的决策。原因是这个业务的命脉是“运力调度”这个能力，核心分析场景如“骑手运力利用率”“配送时效”“每单成本”都围绕运力展开。如果你只按实体分域叫骑手域，后面想扩展车辆管理、站点管理、调度优化时就会很别扭。好的域命名要给未来留出扩展空间，这是从第一个案例里能学到的第一课。

4.3 案例里最有价值的三个讨论点

第一个讨论点：运力域和交易域怎么划清边界。骑手接单之后，订单会发生状态变化，这笔单到底是交易域的账还是运力域的账？我的处理方式是：交易域管“钱”和“订单契约”，运力域管“履约动作”。订单事实表记录下单、支付、退款金额等；运力明细表记录接单时间、取件时间、送达时间、骑手绩效等。两边通过订单ID关联，不互相覆盖。这样分析师想看“收入”进交易域，想看“配送效率”进运力域，各取所需，不会打架。

第二个讨论点：用户域要不要单独拆出一个会员域。很多公司习惯把“会员域”单拎出来，但会员本质上是用户的一个属性，除非会员是独立售卖的商品、有独立的购买分析和收入口径，否则不建议单开。跑腿平台这种业务，会员只是促销手段，放在用户域里加一个会员等级维度就够了。不要为了凑域而切域，域的粒度要跟业务分析复杂度匹配。

第三个讨论点：新业务没有历史包袱，反而要趁早定规范。老业务改造数据域最痛苦的是已经有几百张表、各种口径已经写死在报表里。新业务没有这个包袱，但也容易因为图快而给每张临时表乱打标签，等表多了再回头治理，成本翻倍。所以新业务设计数据域的正确态度不是“随便先分分”，而是“用最小的规范锁住未来的增长”，刚开始哪怕一个域的边界定得粗一点也没关系，但命名和归属机制要从第一天就建立。

5. 容易被追问的五个进阶问题

5.1 业务变化很快，数据域要不要一次设计到位

这是一个必追问题。实话实说，新业务三个月一小改、半年一大改是常态，你不可能预判所有变化。我的观点是：域级别要稳，过程级别要活。域是对“业务核心对象和核心动作”的长期分类，比如一个做本地生活的公司，交易域、用户域、商户域、内容域这些大方向很稳定，不要频繁动。但在过程级别，你可以随时新增一个业务过程挂到已有域下面，也可以把某个过程从A域挪到B域。这样既保证了大的结构稳定，又给业务演进留了弹性。

如果面试官再深入问“那你怎么判断什么时候该大重构”，可以回答：当超过30%的业务过程所在域，在实际使用中频繁跨域查询、且产生大量重复口径时，就该考虑重构数据域了。这个数字不是官方标准，而是一种实用的经验阈值，实战中摸索出来的触发条件比纸上谈兵管用得多。

5.2 数据域、主题域、数据分层是什么关系

这个问题我前面提过，这里给出一个完整的回答版本。数据域是“按业务横向切”的第一层分类，对应的是整个数仓里的业务全景；数据分层是“按数据加工深度纵向切”，比如ODS原始层、DWD明细层、DWS汇总层、ADS应用层。一个数据域里的表，会同时存在于不同分层中——交易域在ODS里有订单原始表，在DWD里有订单明细表，在DWS里有订单汇总表，在ADS里有交易分析报表对应的数据。

主题域则是偏分析视角的聚合，通常是把多个数据域的数据按“分析主题”重新组织，比如“复购分析”“用户生命周期”“供应链履约分析”。这层定义在不同公司差异很大，有的公司干脆把数据域和主题域合并使用。所以面试里你先亮出自己的定义，再说明“这层我们公司是这样看的”，比硬去背一个权威定义要自然得多。面试官不会因为你的定义和某个方法论不完全一致就否定你，怕的是你连定义都有没有。

5.3 同一个业务过程被两个域需要，怎么处理

比如“评价”既可以看作交易完成后的服务环节，也可以看作内容创作的来源。处理原则是：按主分析场景归属，而不是强行复制。如果你把同一张表同时归到两个域，等于没分域，元数据管理会混乱，权限治理也会出问题。更常见的做法是确定唯一归属域，另一个域通过引用或者视图来使用，而不是复制物理数据。

如果两边分析频率都很高怎么办？我会建议在两个域里各建一张“语义视图”，但底层物理表只有一张，这样既满足了两边的使用习惯，又保持了单一事实来源。面试中讲出这个方案，通常能让人觉得你有实际治理经验，而不是只会画框架。

5.4 域设计的产出物是什么

这个问题考的是你能不能把方法论落成具体交付物。标准的产出物至少有三样：一是数据域划分文档，包含每个域的名称、边界描述、包含的业务过程清单；二是业务流程过程清单，每一条对应一个或一组事实表；三是核心实体关系说明，描述用户、商品、订单、支付这些核心对象之间的关系。再有条件的话，补一张总线矩阵，把业务过程和维度对应起来，方便后续建模。

我要特别强调总线矩阵这个东西。它是域设计和具体建模之间的桥梁：行是业务过程，列是公共维度，中间打勾表示该过程关联该维度。有了这张矩阵，团队做表的时候就清楚每张事实表要用哪些维度，维度字段的口径从哪来，这能省掉大量后期对齐时间。面试的时候哪怕只提一句总线矩阵，也能明显提升你回答的专业度，因为它说明你不是停留在“分域”这一步，而是看到了域设计之后的一整条建模链路。

5.5 谁来维护域规范，推动它落地

这题问的是治理机制。我的经验是：必须有一个明确的“数据域Owner”，这个人通常是数据仓库架构师或者数据平台组的核心成员，不能是兼职顺带管一管。域Owner的职责包括：接收新业务过程的归属申请、更新域文档、组织季度边界审查，以及在上线新表前检查表归域是否合理。如果公司有数据治理委员会，域划分的重要变更最好经过委员会评审。

如果面试官继续深挖，你可以补充一句：域的维护不是纯技术问题，它需要业务分析团队和数据开发团队一起参与。如果指标口径天天变，再清晰的域划分也撑不住。所以域规范能落地的前提，是公司有相对稳定的指标管理机制。这一句会把你从“懂建模”提升到“懂体系”。

6. 实战体会与自查清单

6.1 三个失败案例与反思

第一个失败案例是按系统分域。曾经某个项目初期图省事，直接按照订单系统、用户系统、支付系统来分数据域，结果系统一重构，整个数据域跟着乱，花了三个月才重新梳理完。这个教训让我非常坚定地改成按业务过程分域的原则，后来再遇到系统变更就没慌过。

第二个失败案例是域划分之后没有写边界描述。当时人员扩张快，新人来了看到“商品域”三个字就以为是跟商品有关的数据都往里面塞，结果商品域膨胀成一个巨型杂物间，分析效率严重下降。后来补上了边界描述，并且把“不属于本域的典型例子”也写进去，情况立刻好转。这个习惯我从那以后一直保留，宁可多写两行字，也不要让后来的人去猜。

第三个失败案例跟新业务很像：新团队上线一个新项目，为了追求架构完整，一开始定了十多个数据域，每个域下面只有两三个表，规范远大于实际。结果分析师嫌麻烦，开始绕过域规范自己建中间表，数据情况比没规范之前更混乱。后来我们把域合并到五个，刚好贴合当时业务的复杂程度，规范才真正被人用起来。这件事让我明白，域设计的粒度必须跟业务当前的分析复杂度匹配，过度设计比不设计还危险。

这些失败总结起来就是三句话：不要按系统分域，不要只命名不写边界，不要过度设计。你可以把这三条当作回答这道题时的“反面清单”，讲给面试官听的时候，会显得特别有实战感，比背十个概念都有说服力。

6.2 两条黄金原则和一份自查清单

第一条黄金原则：永远先讲思考顺序，再讲结论。面试官想听的不是你的最终划分结果，而是你对一个复杂模糊问题的切入路径。哪怕你最后划分的域与面试官心中的答案不同，只要你的推导过程逻辑自洽，分数就不会低。反之，直接报答案的人，一旦答案跟预期不一致，很容易直接判负。

第二条黄金原则：把“为什么”挂在嘴边。每一个你做出的设计决策，都要能回答“为什么”——为什么按这个标准分域、为什么这个动作算业务过程、为什么这个表归到那个域。讲不清楚为什么的结构，就是没有灵魂的结构。数据域设计最忌讳的就是“别人这么分我也这么分”，你说不出理由，就经不起追问。

最后给你一份自查清单，拿去准备这道题：

• 我有没有先澄清业务边界，而不是直接开答？
• 我有没有按“流程梳理 → 过程识别 → 聚合分域 → 边界规范”这条链路展开？
• 我能不能手绘出一个完整业务的域划分，并用一句话说明每个域的边界？
• 我能不能解释数据域、主题域、数据分层三者的区别？
• 我有没有准备一个3分钟的微型案例，证明自己不是只会背框架？
• 我能不能说出两个数据域设计失败的教训，以及我是怎么调整的？

把这份清单过一遍，这道经典面试题对你来说就不是背题，而是真正变成你的思维方式了。下次再有人问你“一个新的业务如何设计数据域”，你可以自信地反问一句：我们先聊聊这个业务最核心的赚钱动作是什么，再聊怎么分域。