N-tier, Clean Architecture и Vertical Slice: практическое сравнение для .NET

Как каждая из них организует код, где они пересекаются и что учитывать при выборе.

Большинство .NET-разработчиков знакомятся с этими тремя архитектурами в одном и том же порядке: N-tier — в первых проектах, Clean Architecture — когда её приносит команда или шаблон, и Vertical Slice — когда о ней упоминают на код-ревью или в докладе на конференции. Каждую из них подают как улучшение предыдущей. На практике они отвечают на несколько разные вопросы, и правильный выбор зависит скорее от проекта, чем от того, какая из них новее.

В этой статье разберём, что представляет собой каждая архитектура, посмотрим, как одна и та же функциональность раскладывается во всех трёх, и сравним их сильные стороны и издержки.

Зачем вообще нужна архитектура

Архитектура — это набор правил о трёх вещах: где лежит код, какие части от каких могут зависеть и насколько дорого будет что-то изменить в будущем.

Не каждому проекту она нужна. Консольная утилита, которая читает файл, преобразует данные и записывает результат, может выполняться сверху вниз в одном классе, и слои только добавили бы ей церемоний. То же относится ко многим небольшим фоновым сервисам и скриптам, использующим одну общую библиотеку.

Архитектура начинает окупаться, когда кодовая база перерастает объём, который один человек может удержать в голове, когда над ней одновременно работают несколько разработчиков или когда бизнес-логика должна пережить фреймворк, базу данных или UI вокруг неё. В этот момент правила предотвращают знакомый исход: бизнес-логика, размазанная по контроллерам, обращения к базе прямо из представлений и отсутствие понятного места для следующей фичи.

Многоуровневая архитектура (N-tier)

N-tier — классический многоуровневый подход. Приложение делится на горизонтальные слои, обычно на три:

• Presentation / API — контроллеры, модели запросов и ответов

• Business Logic Layer (BLL) — сервисы, реализующие правила предметной области

• Data Access Layer (DAL) — контекст базы данных, сущности и репозитории

Каждый слой зависит только от нижележащего. API вызывает BLL, BLL вызывает DAL, а DAL обращается к базе данных.

MyApp.sln├── MyApp.API│   └── Controllers/│       └── OrdersController.cs├── MyApp.BLL│   ├── Interfaces/│   │   └── IOrderService.cs│   └── Services/│       └── OrderService.cs└── MyApp.DAL    ├── AppDbContext.cs    ├── Entities/    │   └── Order.cs    ├── Interfaces/    │   ├── IOrderRepository.cs    │   └── IUnitOfWork.cs    ├── Repositories/    │   └── OrderRepository.cs    └── UnitOfWork.cs

В .NET такой подход обычно сочетают с Entity Framework, паттерном Repository и классом Unit of Work. Некоторые разработчики считают два последних избыточными, поскольку DbContext уже работает как Unit of Work, а DbSet<T> — как репозиторий. Тем не менее команды часто сохраняют эти обёртки — ради единообразия между проектами и чтобы слой данных было проще подменять в тестах.

Замечание о терминологии: строго говоря, tier — это физическая граница развёртывания, а layer — логическая. По этой причине в документации Microsoft используется термин «N-Layer». В повседневной .NET-практике эти термины взаимозаменяемы, и статья следует этому соглашению.

Clean Architecture

Clean Architecture сохраняет идею слоёв, но меняет направление зависимостей на противоположное. Вместо того чтобы бизнес-логика зависела от доступа к данным, всё зависит от бизнес-логики.

• Domain — сущности и ключевые бизнес-правила, без внешних зависимостей

• Application — сценарии использования (use cases), интерфейсы и DTO; зависит только от Domain

• Infrastructure — база данных, файловое хранилище, внешние сервисы; реализует интерфейсы, объявленные в Application

• API / Presentation — точка входа; связывает всё воедино через внедрение зависимостей

Главное правило — зависимости направлены внутрь. Проект Domain ничего не знает об Entity Framework, ASP.NET Core или какой-либо базе данных.

У этого подхода было несколько названий. Алистер Кокберн описал гексагональную архитектуру, также известную как Ports and Adapters, в 2005 году. Джеффри Палермо описал луковую архитектуру (Onion Architecture) в 2008 году. Роберт Мартин популяризировал название Clean Architecture в 2012 году. Руководство по архитектуре от Microsoft рассматривает все эти варианты как одну и ту же идею под разными именами, и различаются они в основном тем, как их рисуют на схемах.

В .NET Clean Architecture очень часто используют вместе с CQRS (Command Query Responsibility Segregation) и библиотекой MediatR. Каждая операция становится либо командой, которая изменяет состояние, либо запросом, который его читает, и у каждой есть собственный обработчик.

MyApp.sln├── MyApp.Domain│   └── Orders/│       └── Order.cs├── MyApp.Application│   ├── Common/│   │   └── Interfaces/│   │       └── IAppDbContext.cs│   └── Orders/│       ├── Commands/│       │   └── CreateOrder/│       │       ├── CreateOrderCommand.cs│       │       ├── CreateOrderCommandHandler.cs│       │       └── CreateOrderCommandValidator.cs│       └── Queries/│           └── GetOrderById/│               ├── GetOrderByIdQuery.cs│               ├── GetOrderByIdQueryHandler.cs│               └── OrderDto.cs├── MyApp.Infrastructure│   └── Persistence/│       └── AppDbContext.cs└── MyApp.API    └── Controllers/        └── OrdersController.cs

Одна команда и её обработчик выглядят так:

public record CreateOrderCommand(int CustomerId, decimal Amount) : IRequest<int>;public class CreateOrderCommandHandler : IRequestHandler<CreateOrderCommand, int>{    private readonly IAppDbContext _context;    public CreateOrderCommandHandler(IAppDbContext context) => _context = context;    public async Task<int> Handle(CreateOrderCommand request, CancellationToken cancellationToken)    {        var order = new Order(request.CustomerId, request.Amount);        _context.Orders.Add(order);        await _context.SaveChangesAsync(cancellationToken);        return order.Id;    }}

Контроллер отправляет команду, не зная, кто её обработает:

[HttpPost]public async Task<int> Create(CreateOrderCommand command) => await _mediator.Send(command);

Практическое замечание: в 2025 году MediatR перешла на коммерческую лицензию для крупных организаций. Часть команд теперь использует альтернативные библиотеки или собственные простые интерфейсы обработчиков — сама архитектура при этом не меняется.

Vertical Slice

Архитектура вертикальных срезов (Vertical Slice), популяризированная Джимми Богардом, меняет не направление зависимостей, а ось организации кода.

И в N-tier, и в Clean Architecture верхний уровень структуры — это набор слоёв, а каждая фича распределена между ними. Создание заказа затрагивает контроллер в одном проекте, обработчик или сервис в другом и сущность в третьем. Vertical Slice транспонирует эту структуру: верхний уровень — это набор фич, и каждая содержит всё, что ей нужно. Для тех, кто работает с базами данных, это тот же приём, что и PIVOT: строки становятся столбцами.

MyApp.sln└── MyApp    ├── Features/    │   └── Orders/    │       ├── CreateOrder.cs    │       └── GetOrderById.cs    ├── Data/    │   └── AppDbContext.cs    └── Program.cs

Срез часто хранит запрос, обработчик, валидацию и эндпоинт в одном файле:

public static class CreateOrder{    public record Command(int CustomerId, decimal Amount);    public static void MapEndpoint(IEndpointRouteBuilder app) =>        app.MapPost("/orders", Handle);    private static async Task<int> Handle(Command command, AppDbContext db)    {        var order = new Order(command.CustomerId, command.Amount);        db.Orders.Add(order);        await db.SaveChangesAsync();        return order.Id;    }}

В основе лежит принцип: код, который меняется вместе, должен лежать вместе. Срезы могут разделять общую инфраструктуру, например контекст базы данных, но избегают общей бизнес-логики, поэтому изменение одной фичи с меньшей вероятностью затронет другую.

По духу Vertical Slice близка к тому, как CQRS обычно применяется внутри Clean Architecture, где каждая команда или запрос уже лежит в отдельной папке. Разница в том, что Vertical Slice делает основной единицей всего проекта фичу, а не слой.

Что их объединяет и чем они различаются

Все три разделяют ответственность, все три работают с внедрением зависимостей и все три можно использовать с Entity Framework. Различия — в том, что считается основной единицей структуры и насколько строго соблюдаются границы.

Плюсы и минусы

N-tier

Плюсы

• Прост для понимания и быстрого старта

• Знаком практически каждому .NET-разработчику

• Хорошо подходит для CRUD-приложений и проектов со сжатыми сроками

• Мало проектов и папок для навигации

Минусы

• Бизнес-логика зависит от деталей доступа к данным

• Модульное тестирование бизнес-логики может требовать базы данных или обширных моков

• По мере роста проекта BLL и DAL становятся тесно связанными

• Крупные классы сервисов со временем обрастают множеством несвязанных методов

Clean Architecture

Плюсы

• Домен независим от фреймворков и инфраструктуры

• Бизнес-логику легко покрывать модульными тестами

• Инфраструктуру можно заменить с ограниченным влиянием на остальную систему

• Чёткие, проверяемые правила, которые масштабируются на большие команды

• Наиболее узнаваемая структура в актуальных .NET-вакансиях

Минусы

• Значительно больше файлов и проектов на одну фичу

• Более высокие затраты на начальную настройку

• Чтобы проследить один запрос по коду, нужно больше переходов

• Может быть тяжелее необходимого для небольших приложений или быстро меняющихся требований

Vertical Slice

Плюсы

• Весь код фичи находится в одном месте

• Добавление или удаление фичи редко затрагивает другие

• Минимум церемоний для простых фич и возможность добавить структуру для сложных

• Хорошо сочетается с Minimal API

Минусы

• Менее предписывающая, поэтому единообразие зависит от дисциплины команды

• Общие бизнес-правила могут дублироваться в разных срезах

• Меньше устоявшихся шаблонов и соглашений, чем у Clean Architecture

• Менее знакома многим разработчикам и интервьюерам

Проекты, которым не подходит ни одна из них

Не у каждого приложения есть предметная область, которую стоит защищать. Интеграционный сервис, который получает результаты от внешнего API, преобразует их и передаёт дальше, ближе к паттерну «Адаптер», чем к любой из этих архитектур. Его основная задача — преобразование между двумя форматами, и разнесение этого преобразования по трём-четырём проектам мало что даёт.

То же касается консольных инструментов, задач по расписанию и небольших внутренних утилит. Разумный вариант по умолчанию для них — простая структура, а архитектура вводится только тогда, когда проект до неё дорастает.

Практические заметки

Несколько наблюдений, которые редко попадают на архитектурные схемы, но важны в повседневной работе.

Навигация действительно стоит времени. В решении на Clean Architecture одна фича может быть разнесена по четырём проектам и нескольким вложенным папкам. Файлы легко найти поиском, но переходить между ними медленнее. В Visual Studio опция Track Active Item in Solution Explorer («Отслеживать активный элемент в обозревателе решений»; Tools → Options → Projects and Solutions → General) заставляет Solution Explorer следовать за файлом, открытым в редакторе. Для разового перехода то же самое делает Sync with Active Document (Ctrl + [, S).

Шаблонный код стал дешевле. Самым частым практическим возражением против CQRS в связке с Clean Architecture был объём повторяющегося кода: класс команды, затем обработчик, затем валидатор, затем DTO — часто создаваемые копированием существующего набора с последующим переименованием. Ассистенты на базе ИИ теперь надёжно генерируют большую часть этого кода, что снимает значительную долю издержек, из-за которых подход ещё несколько лет назад казался медленным.

Выигрыш в тестировании неравномерен. Поскольку фичи и бизнес-правила изолированы, модульные тесты в Clean Architecture и Vertical Slice писать проще, чем в тесно связанном N-tier-проекте. Интеграционные тесты требуют примерно одинаковых усилий во всех трёх, поскольку в любом случае проходят через API, как бы ни был организован код за ним.

Частота изменений имеет значение. Проекты со сжатыми сроками и часто меняющимися требованиями сильнее всего ощущают дополнительную структуру Clean Architecture, поскольку каждое изменение затрагивает больше файлов. Проекты со стабильной сложной предметной областью и долгим ожидаемым сроком жизни выигрывают от неё больше всего.

Рынок

Каковы бы ни были технические компромиссы, Clean Architecture сегодня — вариант по умолчанию в .NET-вакансиях, на собеседованиях и в шаблонах проектов. Разработчики, приходящие в профессию сейчас, часто изучают её первой, и многие команды используют её как стандартную структуру для новых сервисов.

Ситуация похожа на фронтенд-разработку, где React — далеко не единственный хороший вариант, но именно его чаще всего требуют работодатели. Хорошее понимание Clean Architecture полезно для карьеры .NET-разработчика независимо от того, какую структуру в итоге использует конкретный проект.

Как выбирать

Универсально правильного ответа нет, но несколько вопросов сужают выбор:

• Сколько проживёт этот код? Недолговечные или экспериментальные проекты тяготеют к N-tier или Vertical Slice. Долгоживущие системы со сложными правилами — к Clean Architecture.

• Как часто будут меняться требования? Частые изменения вознаграждают меньший объём церемоний на фичу.

• Насколько велика команда? Большим командам полезны строгие и общеизвестные границы Clean Architecture.

• Что команда уже знает? Знакомая архитектура, применяемая последовательно, обычно лучше незнакомой, применяемой частично.

Все три — рабочие способы построить .NET-приложение. Самое важное решение — выбрать одну осознанно и применять её последовательно.

---

Это перевод моей статьи, впервые опубликованной на Medium.

Какую архитектуру использует ваша команда — и был ли это осознанный выбор или шаблон, который пришёл вместе с проектом? Интересно узнать, как это сработало на практике. 👇