CRUD Slices

CRUD 听起来像标准动作。

一点 GET。

一点 POST。

一点 PUT。

一点 DELETE。

结束。

但在真实前端中，这往往正是代码开始失去结构的地方。

因为读取、创建、更新和删除，并不只是四种 HTTP Method。它们是四种职责不同的业务 Flow。

Retrieve Flow 为展示构建模型。

Create Flow 向系统发送一个新的 Intent。

Update Flow 修改已经存在的内容。

Delete Flow 是一个具有破坏性的业务决定。

这些文章会具体展示这些 Flow 可以怎样在代码中切分——从 API Boundary 一直到 Component，形成完整的纵向切片（Vertical Slice）。

---

什么是 Slice

Slice 不是 Layer。

Layer 是横向分层：

所有 Component
所有 Store
所有 Service
所有 Mapper

Slice 则是穿过一个业务 Flow 的纵向切片。

它只包含为了实现某项业务操作真正属于一起的文件：

API Boundary
  → Mapper
  → Entity / Command
  → Store / Event Handler
  → Facade
  → Component

Slice 回答的是具体问题：

• Component 可以知道什么？
• ViewModel 在哪里产生？
• Command 在哪里产生？
• DTO 在哪里构建？
• Success 或 Error 在哪里触发响应？
• UI Logic 在哪里结束，Infrastructure 从哪里开始？

目标不是制造尽可能多的文件夹。

目标是让职责清晰可见。

---

四种基本 Flow

Retrieve

加载数据不是 Template 里的一个 GET。

Retrieve Slice 保护 UI 不受 API Leakage 影响，并为展示构建 ViewModel。

Retrieve Slice：不在 Component 中写加载逻辑

Create

创建数据不是从 Component 发一个 POST。

Create Slice 发送 Intent、执行 Command，并让 Success 或 Error 的后续响应彼此独立。

Create Slice：把写入建模为 Command Flow

Update

编辑数据不是“Form 恰好提交了一个 DTO”。

Update Slice 分离 Form State、修改意图、API DTO 与后续 Action。

Update Slice：Form State 不是 DTO

Delete

删除数据不是一个顺手调用 http.delete() 的 Button。

Delete Slice 把删除视为具有破坏性的业务决定，同时让 Reload、Notification 与错误响应保持解耦。

Delete Slice：删除是一项业务决策

---

这一系列的目标

这些文章不是 Pattern 目录。

它们展示具体的代码切分。

不声称适合每个项目。

也不是教条。

它们是一组给团队使用的工作材料——适合那些不只想把前端代码写出来，还希望有意识地决定代码应该如何被切开的团队。