---
url: /zh/onboarding/executive-guide.md
description: 用可验证的业务切片、所有权与运营证据决定是否资助一次 Wow 试点。
---

# 高管指南

本页只回答一个问题：**是否值得为当前业务资助一次有边界的 Wow 试点？**

Wow 不是最终用户产品，也不自动提供业务指标、生产 SLA、合规认证或组织效率收益。它提供的是围绕命令、领域事件、事件溯源状态和明确完成阶段构建应用的框架能力。完整价值与采用成本以[简介](../guide/introduction.md)为准。

## 决策输入

### 业务是否匹配

优先考虑具有以下已知需求的业务切片：

* 决策规则和不变量比 CRUD 字段更新更重要；
* 需要解释“发生过什么”并从事件重建状态；
* 写入、投影和下游处理需要明确区分完成阶段；
* 重试、幂等、补偿或审计属于产品责任，而不是偶发实现细节。

如果主要需求是简单同步 CRUD、团队不需要业务历史，或无法承担最终一致性与事件演进责任，应先选择更简单的架构。

### 谁承担持续成本

试点前必须给出具名的责任领域，不要求虚构人数或预算：

| 责任 | 必须回答的问题 |
|---|---|
| 领域模型 | 谁批准命令、不变量、事件语义和演进规则？ |
| 平台与依赖 | 谁维护 JVM/Wow 版本、存储、消息、构建与发布？ |
| 运行 | 谁负责阶段化监控、备份、重放、恢复和有界关闭？ |
| 产品 | 谁定义用户可见的等待、失败、重复请求与恢复体验？ |
| 安全与数据 | 谁验证认证、授权、租户隔离、保留期和访问审计？ |

没有所有者的能力不能算作已具备。

## 试点完成证据

试点应选择一个真实但可回滚的业务切片，并交付可观察证据：

1. 领域 Spec 证明命令产生预期事件并得到预期状态；
2. 运行中的服务接收真实 HTTP 命令；
3. 命令结果声明请求的完成阶段，而不是笼统的“成功”；
4. 能按版本读取或重建事件溯源状态；
5. 若用户旅程依赖读模型，投影可见性有独立验证；
6. 至少一次失败、重复请求或恢复路径演练有记录；
7. 依赖、数据、运行、安全和回滚的所有权已分配；
8. 未验证的吞吐、延迟、可用性、成本或生产恢复能力被明确标为缺失证据。

[快速上手](../guide/getting-started.md)提供最小技术证明，但它不是生产准入。生产判断还需[生产最佳实践](../guide/best-practices.md)和[可观测性](../guide/advanced/observability.md)中的环境证据。

## 决策门禁

| 结论 | 条件 |
|---|---|
| 资助有边界试点 | 业务匹配、切片可回滚、责任人明确，并同意用上述证据验收 |
| 继续取证 | 价值假设合理，但数据、运行、安全或恢复责任仍未确定 |
| 暂不采用 | 简单方案已满足需求，或组织不准备承担事件演进与运营责任 |

不要用仓库测试数量、示例 benchmark 或框架能力清单替代本业务的基线。是否扩大采用范围，只能由试点相对既定业务目标和风险边界的实际结果决定。

## 优先下一步

1. **验证业务适配**：让产品负责人完成[产品经理指南](./product-manager-guide.md)中的工作流决策。
2. **验证技术与运营适配**：让架构负责人完成 [Staff Engineer 指南](./staff-engineer-guide.md)中的边界与证据矩阵。
3. **执行试点**：从[快速上手](../guide/getting-started.md)建立首次成功，再替换为真实业务切片。