Vertical Slice vs Clean Architecture in .NET 10: the hybrid layout
The author compares Vertical Slice and Clean Architecture on the same Product API in .NET 10, counting the files each layout touches for one new feature. He then presents a hybrid layout that keeps the Domain project, drops the Application project, and groups endpoints by feature. It is a practical reference for teams deciding how to structure a Web API.
Key points
- Adding one endpoint takes about five files across several projects in Clean Architecture, but only one feature file in the hybrid layout.
- The Application project is dropped in the hybrid because, once feature folders live in Api, it would only pass calls through or pull in ASP.NET Core.
- Business rules live on the Domain entity, and private setters stop invalid values such as a negative price from being assigned.
- For concurrent stock updates, IsRowVersion() maps to PostgreSQL's xmin column, and a conflict returns 409 Conflict to the client.
- The Shared folder holds technical code only, such as endpoint discovery, filters and exception handlers, never business rules.
- Keep input validation in each slice's validator and business rule checks on the entity, so the two are not mixed.
The author builds the same Product API three ways, Clean Architecture, pure Vertical Slice and a hybrid, and counts how many files and projects each one touches to add a single endpoint. Clean Architecture asks for about five files across several projects, while a slice layout needs one file, but it leaves business rules without a clear home.
His recommended hybrid keeps a Domain project with no dependencies, drops the Application project, and puts each feature in one file inside the Api project. Business rules sit on the entity with private setters, and a row version token guards against lost updates under concurrent requests. The article also sets rules for the Shared folder and separates input validation from domain checks. The full sample and architecture tests are in the linked repository.
Real-world use
- A CRUD-heavy product API that ships features quickly can keep each endpoint, validator and handler in one feature file.
- A long-lived order system with complex pricing or stock rules can keep those rules on the Domain entities in the hybrid layout.
- When an API and a background worker must share the same use cases, keeping an Application project is the better choice.
Why it matters
Deciding early where a feature's files live and where business rules belong directly affects the cost of every future change. The hybrid keeps the speed of slices while giving rules one place to live.