最近发现了个新架构 Vertical Slice Architecture (VSA),想法来源于.NET 社区,刚开始以为是什么新东西,结果发现它是另一种极端的思想:
- DDD:过度分层(Controller、UseCase、Entity、Repository、Infrastructure…)
- VSA:不分层,按业务组织代码,一个功能的所有逻辑写在一起
看起来很新鲜,但仔细想想:按业务组织代码,我之前的 Functional Architecture 也能做。VSA 和 Functional Architecture 的真正区别是:VSA 不强制分层。
核心理念:不只是文件夹组织
Functional 也可以按功能组织文件夹,比如:
src/features/
create-order/
route.ts # 路由层
service.ts # 业务层
domain.ts # 领域层
但 VSA 和 Functional Architecture 的真正区别不在文件夹结构,而在于:
分层约束
Functional Architecture:强制分层,即使按功能组织,也要保持 route → service → domain 的依赖方向
// features/create-order/route.ts
router.post('/orders', async (req, res) => {
const order = await orderService.createOrder(req.body); // 必须调用 service
// ...
});
// features/create-order/service.ts
export const createOrder = async (input) => {
const draft = buildOrder(input); // 必须调用 domain
return prisma.order.create({ data: draft });
};
// features/create-order/domain.ts
export const buildOrder = (input) => ({ /* 领域逻辑 */ });VSA:不强制分层,所有逻辑写在一起
// features/create-order/handler.ts
export async function createOrder(input) {
// 验证、计算、保存,所有逻辑都在这里
const draft = { userId: input.userId, totalAmount: calculateTotal(input.items) };
return prisma.order.create({ data: draft });
}复用策略
- Functional Architecture:预设 domain 层复用
- VSA:重复 3 次再抽到
shared/
灵活度
- Functional Architecture:每个功能都要遵守分层规范(route/service/domain)
- VSA:简单功能 1 个文件,复杂功能才拆多个文件
对比总结
Functional Architecture:即使按功能组织,也是”分层的功能切片”
features/create-order/
├── route.ts ← 必须有
├── service.ts ← 必须有
└── domain.ts ← 必须有(如果有领域逻辑)
VSA:真正的”功能切片”,按需拆分
features/create-order/
└── handler.ts ← 简单功能只需 1 个文件
关键区别表格
| 维度 | Functional Architecture | VSA |
|---|---|---|
| 分层约束 | 强制分层(route → service → domain) | 不强制,按需拆分 |
| 文件数量 | 每个功能至少 2-3 个文件 | 简单功能 1 个文件即可 |
| 复用策略 | 预设 domain 层复用 | 重复 3 次再抽到 shared |
| 适合场景 | 中大型项目,需要技术分层约束 | 小型项目,快速迭代 |
何时用哪个
VSA:非常小的项目(<10 个功能)、功能之间基本没有复用、单人或小团队
Functional Architecture:中等规模项目、有代码复用、需要分层约束
DDD:大型复杂项目、多团队协作、业务极其复杂
总结
VSA 和 Functional 的区别不是文件夹组织,而是是否强制分层。
核心观点:
- 按业务组织代码,Functional 也能做,不是 VSA 的专利
- VSA 的特点是不强制分层,一个文件写完所有逻辑
- 这是一种极端思想,适合非常小的项目,但一旦项目变大会面临代码复用困难、缺乏约束、重构成本高的问题
对于大多数项目,Functional Architecture 是更平衡的选择。