「产品矩阵平台」业务域服务体系

第四章 业务域服务体系

业务域服务体系决定平台能承载什么样的产品。技术底座再漂亮，如果业务域切分混乱，团队最终还是会回到“一个需求改五个地方”的状态。

产品矩阵平台建议按业务能力划分领域，而不是按页面、端或数据库表划分。一个领域应该能独立回答：它负责什么对象，维护什么规则，向外提供什么能力，产生什么事件。

4.1 领域划分原则

一个简单判断：如果两个功能总是一起变化，它们大概率属于同一领域；如果只是偶尔协作，应通过接口或事件连接。

4.2 内容域：CMS、UGC 与 Feed

内容域负责文章、视频、评论、标签、专题、审核、发布计划和 Feed 流。它是许多产品矩阵的基础域，因为工具、社区、媒体、电商导购都可能依赖内容能力。

核心对象：

内容域最重要的是状态机：

draft -> reviewing -> approved -> scheduled -> published -> archived
                 \-> rejected

不要用一个简单的 status 字段随意改来改去。每次状态变化都应记录操作者、原因和时间，特别是审核、下架、恢复发布。

4.3 电商域：商品、订单、库存、支付、营销

电商域复杂，是因为它同时涉及交易一致性、用户体验和财务可信。

推荐拆成四个子域：

支付不建议直接放在电商域内部。支付中心应该是平台通用能力，电商域调用支付中心创建支付单，并订阅 payment.succeeded、payment.failed 等事件更新订单。

订单状态变化建议以事件驱动：

4.4 工具域：表单、任务、OCR 与 AI 接口封装

工具域常见于“多应用孵化平台”：表单收集、任务管理、OCR 识别、导入导出、AI 摘要等能力会被多个产品复用。

工具域的特点是输入输出差异大，适合采用任务模型：

这样新工具可以先以异步任务方式接入，等调用量稳定后再沉淀为独立服务。

4.5 媒体域：视频、音频、频道与推荐

媒体域关注两个方向：资产处理和分发效率。

媒体处理不应阻塞用户请求。上传完成后只表示原始文件已入库，转码、审核、分发都应通过异步任务推进。

4.6 分析域：BI、用户画像与埋点仓库

分析域不能只理解为“做报表”。它要把产品矩阵中的行为数据变成可运营、可决策、可自动化的资产。

数据链路建议如下：

前端埋点 / 后端事件
  -> Kafka / Log Queue
  -> 清洗任务
  -> ClickHouse 明细表
  -> 聚合宽表
  -> BI / 用户画像 / 推荐策略

埋点设计要避免两个极端：过少导致无法分析，过多导致无人维护。每个事件至少包含 event_name、user_id、tenant_id、app_id、timestamp、properties。

4.7 推广域：广告、分销与渠道追踪

推广域的核心是归因。用户从哪个渠道来、经过哪些触点、最终产生了什么价值，决定了平台能否优化增长成本。

核心对象：

推广域要与用户域、订单域、分析域协作，但不要直接改它们的数据。它应订阅 user.registered、order.paid 等事件，再计算归因和佣金。

4.8 金融支付域：支付、退款、对账与风控

金融支付域要求“可解释”。每一分钱从哪里来、到哪里去、因为什么变化，都必须能追溯。

推荐把支付域拆成：

支付回调必须幂等。不要只依赖回调成功来推进状态，还要有主动查询和对账任务兜底。

4.9 AI 服务域：模型封装、AIGC 与 Prompt 代理

AI 域的目标不是把某个模型 API 包一层，而是把模型能力变成平台可治理的业务能力。

AI 服务至少应处理：

AI 域要天然支持异步任务，因为许多生成、识别、总结任务不适合在 HTTP 请求里等待。

4.10 业务域协作地图

一个健康的协作方式是：

业务域服务体系不是为了画图好看，而是为了让新产品上线时可以“装配能力”，而不是复制项目。