[!info] related notes

• 所属 MOC: Matt Pocock Skills MOC
• 对比: 项目分层架构
• 相邻方法: Tracer Bullet
• 验证: TDD
• 工程闭环: Matt Pocock Skills 的工程闭环

Vertical Slice

一句话定义

Vertical Slice 让一个工作单元沿着系统层次纵向穿透：

user/system behavior
→ domain/state
→ API
→ persistence
→ UI/consumer
→ test/evidence

做到：

这个切片本身可以被验证，而不是只完成了某一技术层的一部分。

与按层拆任务的区别

Horizontal / layered task 常写：

ticket A: database schema
ticket B: backend API
ticket C: frontend page
ticket D: tests

这些 ticket 单独完成时，往往无法证明真实行为已经可用。

Vertical Slice 更像：

用户可以创建一个 Task
→ schema
→ domain command
→ API
→ UI
→ test

然后下一片再做：

用户可以完成 Task

Slice 应该多小

一个好 slice 通常：

• 有明确 observable behavior；
• 能独立验收；
• 足够小，可以快速完成；
• 又足够完整，不依赖大量“以后再接”的未完成层。

太大：

退化成 epic。

太小：

退化成只改一层的技术 task。

Layered Architecture 并不会消失

Vertical Slice 是工作/交付切分方式，不是说代码内部不再分层。

完全可以：

Vertical feature slice
├─ domain
├─ application
├─ infrastructure
└─ UI

因此：

Vertical Slice 与 layered architecture 不矛盾。

一个描述交付边界，一个描述代码组织边界。

与 Tracer Bullet

Tracer Bullet 更强调：

先打通一条贯穿系统的真实路径，以验证架构和不确定性。

Vertical Slice 更强调：

把后续工作持续切成端到端可验收行为。

两者可以组合：

Tracer Bullet
→ prove path

Vertical Slices
→ incrementally deliver behaviors

为什么适合 Agent / AI 编码

对 coding agent 来说，vertical slice 提供更强反馈：

• 目标行为明确；
• 可以写 acceptance test；
• 改动范围相对小；
• 完成后能运行真实验证；
• review 更容易判断“是否完整”。

这比“一次生成整套数据库层”更容易形成 ground-truth feedback。

常见失败模式

Slice 只剩 UI

界面按钮出现，但没有 persistence/API contract。

Slice 只剩 Backend

接口能调，但用户实际路径未接通。

Slice 没有验证

代码跨层都改了，却没有 acceptance test 或可观察证据。

每片都偷偷重构全系统

slice 失去小步反馈价值。

学习检查

1. Vertical Slice 与按数据库/API/UI 分票的核心区别是什么？
2. 为什么 Vertical Slice 不等于抛弃 layered architecture？
3. 一个 slice 太小或太大分别会怎样失败？
4. Tracer Bullet 与 Vertical Slice 的关注点有什么差异？
5. 为什么 Vertical Slice 特别适合 coding agent 的实现/review 闭环？
6. 把“任务管理功能”拆成 3 个可独立验收的 vertical slices。