---
url: /zh/onboarding/product-manager-guide.md
description: 判断一个产品工作流是否需要 Wow 的命令、事件、状态与完成阶段模型。
---

# 产品经理指南

本页只回答一个问题：**这个产品工作流是否需要 Wow 的命令 → 事件 → 状态模型？**

Wow 是应用框架，不是现成的业务产品。产品决策应从用户意图、业务事实、可见状态和失败恢复开始，而不是从 Kafka、MongoDB 或模块清单开始。

## 决策输入

选择一个真实工作流，并与领域和工程负责人核对：

| 输入 | 要回答的问题 |
|---|---|
| 用户意图 | 用户请求系统做什么？这是可被接受或拒绝的命令吗？ |
| 业务事实 | 接受后发生了什么不可变事实？事件名称是否能被业务人员理解？ |
| 当前状态 | 哪些状态由事件重建，哪些只是派生读模型？ |
| 完成阶段 | 用户只需知道请求已发送、已处理、快照已更新或匹配投影函数已完成，还是产品必须实际查询到读模型？ |
| 失败体验 | 校验失败、领域拒绝、重复请求、超时和下游失败分别如何呈现？ |
| 恢复责任 | 哪些失败可自动重试，哪些需要人工处置？补偿不会撤销已经发生的事实。 |
| 数据与安全 | 谁定义身份、租户范围、保留期、删除、审计与敏感字段政策？ |

命令阶段的精确定义见[完成语义](../guide/command/completion.md)，读模型边界见[投影](../guide/projection.md)。

## 适合与不适合

### 更适合

* 工作流有需要集中保护的业务不变量；
* 业务需要可追溯的变化历史或按版本重建状态；
* 写入接受、领域处理、快照、匹配投影函数完成和读模型查询可见性必须分别表达；
* 重复请求、异步处理和恢复是明确的产品场景。

### 应先选择更简单方案

* 主要是同步 CRUD，变化历史没有业务价值；
* 用户体验要求立即一致，但团队不准备设计等待、超时和恢复；
* 产品只需要报表读取，不需要命令侧领域模型；
* 采用理由只是“技术栈统一”，没有具体业务决策受益。

## 产品验收切片

在进入路线图前，为一个工作流写出以下可验证合同：

```text
Given  已知业务状态与权限
When   用户发送一个命令
Then   系统接受或以明确原因拒绝
And    接受时产生具名领域事件
And    事件可重建带版本的状态
And    UI/API 只承诺请求的完成阶段
And    超时、重复和下游失败有可操作路径
```

完成证据至少包括：

* 领域 Spec 覆盖接受和拒绝路径；
* 真实接口结果包含聚合标识与所请求阶段的可观察结果；`aggregateVersion` 只在该阶段已知时记录。在 `SENT` 阶段，`aggregateVersion` 可能为 `null`，也可能仅携带命令提交的 expected version；若验收需要处理后的版本，应等待 `PROCESSED` 或后续阶段，或另行读取状态/事件；
* 若产品依赖查询页面，必须通过实际查询证明目标 read model 已可见。`PROJECTED` 只能作为匹配投影处理器已完成的附加阶段证据，不能替代写后读验证，尤其不能覆盖返回响应式链之外启动的工作；
* 重试与人工恢复路径不会被描述成事务回滚；
* 数据保留、删除、权限与运营审计由应用或平台策略明确承担；
* 延迟、吞吐、可用性和成本目标来自本产品环境的基线与验收，而不是框架示例。

本仓库的示例和测试可以证明框架行为，但不能替代产品生产数据、用户研究或服务等级证据。

## 优先下一步

1. **工作流匹配**：与工程师在[聚合与不变量](../guide/domain/aggregate.md)中把命令、事件、状态和不变量变成一个 Spec。
2. **需要异步读模型**：继续[投影](../guide/projection.md)与[查询](../guide/query.md)，明确用户等待到哪个阶段，并把实际查询可见性作为独立验收。
3. **需要失败恢复**：阅读[事件补偿](../guide/event/compensation.md)与[恢复](../guide/recovery.md)，定义自动和人工边界。
4. **工作流不匹配**：停止引入 Wow；采用更简单方案不需要额外论证。