Обзор Vertical Slice Architecture

Что такое Vertical Slice Architecture?

Вертикальная архитектура слайсами (Vertical Slice Architecture) была впервые предложена Джимми Богардом в 2018 году. Джимми так же автор таких библиотек как MediatR и Automapper.

Вертикальная архитектура (Vertical Slice Architecture) представляет собой подход к организации кода, в котором приложение разделяется на независимые функциональные слайсы. Каждый слайс включает все необходимые компоненты для реализации определенной функции, от пользовательского интерфейса до базы данных. В отличие от традиционных многослойных архитектур, где слои разделены по техническим аспектам,  вертикальная архитектура организует код вокруг бизнес фич или пользовательских сценариев.

Пример одного из подходов многослойной архитектуры под названием Clean Architecture:

Основные концепции vertical slice architecture

Вертикальная архитектура ориентирована на создание cohesive и слабо связанных (loosely coupled) модулей. Каждая бизнес функция реализуется как самостоятельный слайс, включающий контроллеры, сервисы, модели данных, репозитории и бизнес логику:

Feature-Centric Design: В вертикальной архитектуре каждый слайс представляет бизнес фичу или пользовательский сценарий. Это означает, что все компоненты, необходимые для реализации этой функции, сгруппированы вместе в одном слайсе. Давайте рассмотрим на примере, так станет понятнее

Пример организации проекта на C#:

ProjectName/
│
├── Features/
│   ├── UserAuthentication/
│   │   ├── Controllers/
│   │   ├── Services/
│   │   ├── Models/
│   │   ├── Repositories/
│   │   └── Data/
│   ├── FlightBooking/
│   │   ├── Controllers/
│   │   ├── Services/
│   │   ├── Models/
│   │   ├── Repositories/
│   │   └── Data/
│   └── HotelReservations/
│       ├── Controllers/
│       ├── Services/
│       ├── Models/
│       ├── Repositories/
│       └── Data/
└── Shared/
    ├── Utilities/
    └── Middleware/

Простымы словами, мы не создаем несколько проектов и не распихиваем наши файлы по ним, вместо этого например в API проекте мы создаем папочки для каждой фичи и складываем туда реализацию всех слоев (сервиса, контроллера, репозитория, модели и тд)  

✔️Преимущества VSA

1. High cohesion: Все элементы, необходимые для реализации функции, находятся в одном месте, что облегчает их понимание и изменение.
2. Low coupling: слайсы слабо зависят друг от друга, что упрощает внесение изменений и тестирование.
3. Модульность и масштабируемость: Новые фичи могут быть добавлены в виде новых слайсов, не влияя на существующий код.

❌Недостатки VSA

1. Сложность первоначальной настройки: Создание архитектуры вертикальных срезов требует тщательного планирования и понимания бизнес требований.
2. Повторение кода: Из-за изоляции слайсов могут возникать ситуации, когда схожая логика или компоненты дублируются в разных слайсах.
3. Обучение и адаптация: Командам разработки может потребоваться время для адаптации к новому подходу, особенно если они привыкли работать с традиционными многослойными архитектурами.
4. Управление зависимостями: Хотя слайсы независимы, управление зависимостями между общими компонентами (например, утилитами или библиотеками) может усложнить проект.
5. Размер и сложность проекта: В небольших проектах преимущества вертикальной архитектуры могут быть не столь очевидны, и она может добавлять ненужную сложность​.

Так же можете посмотреть хорошее обзорное видео по VSA:

Шаблон архитектуры, который показали на видео можно найти на github.

Почему стоит выбрать Vertical slice architecture для своего проекта?

Но подождите, разве вы не должны стремиться к low coupling  и high cohetion при разработке, как завещали GRASP принципы?  

Да, и это, пожалуй, то, что отличает VSA от традиционных многоуровневых архитектур и, вносит дискуссию и консерны. Как утверждает автор концепта, мы должны стремиться к тому, чтобы:

Минимизировать связь между слайсами и максимизировать связь внутри слайса.

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

Новые фичи только добавляют код, вы не меняете общий код и не беспокоитесь о сайд эффектах.

Говорит Джимми.

Такой подход дает ряд преимуществ, например, мы можем выбрать разный подход к фетчингу данных, где-то юзать ORM, где-то чистый SQL,  а где-то Event Sourcing.

Что по микросервисам?

Конечно, вы можете все пилить отдельными сервисами, тогда у вас отпадёт потребность в слайсах, но не всегда отдельная фича равна отдельному микросервису, и если вы заходите в будущем слайс выделить в отдельный микросервис, это будет проще сделать, нежели с CleanArchitecture подходом. В теории, если вы сделали все верно и у вас нет зависимостей на другие слайсы, вам всего лишь нужно будет copy-paste папочки сделать, чтобы переместить логику в отдельный сервис.