Vertical Slice架构与Clean Architecture融合可行性及分层设计咨询

完全可行，这种融合能同时兼顾整洁架构的分层隔离优势和垂直切片架构的业务聚焦特性，非常适合中大型项目的长期维护与迭代。

核心融合思路 #

• 以垂直业务切片为核心组织代码，每个切片对应一个完整的业务场景（比如「订单创建」「用户认证」）
• 每个切片内部遵循整洁架构的职责划分：保留Domain（领域核心逻辑/模型）、Application（应用服务/用例）、Infrastructure（外部依赖实现）的分层，但这些分层是切片内的局部划分，而非全局统一的项目层

两种结构方案的对比与选择 #

1. 全局分层+切片目录（你的初始设想：WebApi/Application/Domain/Infrastructure项目） #

• 优势：全局层面保持整洁架构的清晰边界，Domain层集中存放通用领域模型和跨切片的业务规则，Infrastructure统一管理数据库、第三方服务等外部依赖
• 问题：随着切片数量增长，Domain和Infrastructure项目会逐渐臃肿，跨切片的依赖关系容易变得混乱
• 适用场景：业务领域存在大量通用模型和共享规则，切片间逻辑复用较多的项目

2. 每个切片独立分层（为每个切片设置专属Domain/Infrastructure） #

• 优势：每个切片的代码完全内聚，边界清晰，彻底避免全局层的臃肿问题，新增或修改切片时不会影响其他业务模块
• 问题：可能出现少量领域逻辑重复，需要额外抽象通用逻辑到独立的共享库（比如Common.Domain）
• 适用场景：业务模块独立性强，切片间共享逻辑少，项目规模增长快速的场景

实践落地建议 #

• 项目初期可以先从全局分层+切片目录入手：在Domain层按切片划分子目录（如Domain/Orders、Domain/Users），Infrastructure层同理（如Infrastructure/Orders/OrderRepository），既符合整洁架构规范，又能通过目录实现垂直隔离
• 当某个切片的业务复杂度剧增，或全局层开始出现臃肿迹象时，再将该切片的Domain/Infrastructure逻辑拆分到独立的项目或目录中，逐步演进
• 无论采用哪种方案，WebApi层都按垂直切片组织控制器（如OrdersController、UsersController），Application层按切片存放用例（如Application/Orders/CreateOrderUseCase）

内容的提问来源于stack exchange，提问作者Vagner Wentz