BC-10｜经营分析与数据质量（analytics）

状态：working-draft；本次边界建议，未批准为完整新基线。
Design=draft；Contract=not-defined-here；Implementation=not-assessed；Verification=document-review-only。
上游：SD-09（仍为候选占位）
输入：既有模块设计（历史材料保留在 docs_bak/）
编写责任：主会话；业务决策 / 长期维护责任人：待指定。日期：2026-09-18。

1. 需要什么，它是什么

让经营者知道发生了什么、统计口径是什么、结果是否可信。

统一语言：AnalyticalFact 是从源事实派生的分析记录；MetricVersion 是统计解释；Serving 是发布结果；DataQualityIssue 是质量问题，不是修改业务的授权。

2. 拥有与不拥有

拥有： 分析接收、派生事实与维度、指标版本、数据质量问题、重算发布、分析监测的口径/条件语义及受控导出。分析信号接入通用监控平台，告警事件、路由、通知、工单和自愈不在本域再建一套。

不拥有： 订单、财务分录、库存与容量、客户关系等源事实；不默认拥有推荐决策、实验分配或即时业务操作状态。

这里列出事实族和职责，不直接定义数据库表、聚合事务范围或最终接口名称；详细模型须在下一层继续验证。

3. 谁参与，怎样使用

经营者与财务读取看板及来源解释；分析人员管理指标和重算；Worker 消费版本化事件；业务 Owner 接收质量问题并通过自己的命令修复。

典型场景：源事件进入 → 验证去重和版本 → 派生事实 → 指标计算 → 带口径与新鲜度发布；发现差异回源修复，再重算与验证。

4. 如何与其他上下文协作

消费各 BC 的允许事件；Finance 提供财务解释事实；对外提供只读指标与来源引用，不能让交易命令依赖延迟看板判断可售。

调用方向、信息方向、流程协调者和失败责任统一见 CONTEXT-MAP；事实边界及混淆项见 OWNERSHIP。不使用共享可变实体或跨 Owner 写表。

5. 不变量、权限与一致性

指标必须可解释口径与时间范围；不得把丢事件当零值；查询和导出均按范围用途授权；源事实修复只能回 Owner。

所有入口遵循 统一授权接缝。本上下文负责自己的资源关系和业务动作条件，不能仅凭客户端提交的角色或对象归属放行。

6. 失败、并发与恢复

迟到、乱序、重复和新版本隔离处理；重算失败保留旧版本并显示过期；撤权后已排队导出需复查，已交付文件的访问控制有撤销边界。

部署和数据库共用不构成跨上下文原子性承诺。需要立即成立的约束在对应事实 Owner 内执行；跨域步骤记录意图、版本、结果与恢复进度。

7. 边界取舍与可能推翻结论的证据

保持分析与交易、财务分离。个性化输出若只是只读统计可消费分析结果；若产生规则/实验决策事实必须另判 Owner，不能塞入 Analytics 掩盖。

反证检查：验证重复事件不多计、缺失事件不显示完整、源事实更正后重算、跨范围导出、指标与总账口径不同可解释。

上述是设计反例清单，尚未执行产品测试。拆合讨论及重开条件见 BOUNDARY-DECISIONS。

8. 未决事项与后续交付

指标口径、新鲜度目标、重放保留、导出撤销及推荐决策边界待明确。

先核对本页业务范围及上下文边界，再细化模型、不变量、状态、命令/查询/事件和授权契约；最后派生完整业务增量 REQ。不得据本稿直接锁定开发接口。当前未决项统一归入DECISIONS对应D项；REVIEW仅保留历史审查及Q项来源，不另作活动决策台账。