Designing for change with Vertical Slice Architecture - Chris Sainty - NDC London 2024 (Рубрика Architecture)

Интересный, но странный доклад про вертикальные слайсы как архитектурный концепт. Основная мысль в том, что нам стоит проектировать приложения с учетом изменений, так как изменения являются единственной постоянной в нашей отрасли. Дальше автор вспоминает предыдущие виды архитектур

• Трехзвенная архитектура (n-tier), что была популярна во времена динозавров. В этой архитектуре у нас есть data access layer, business logic layer, user interface layer
• Луковая архитектура, ~~хорошо, что не липовая~~ (onion) - в этой архитектуре центральным элементом являются бизнес-правила предметной области
• Чистая архитектура от дяди Боба (что любит все чистое: код, архитектуру, agile) - микс лучших практик из других архитектур возведенный на уровень догм Дальше автор вспоминает что мы делаем код не ради красивой архитектуры (звучит лучше, чем чистая), а ради создания фичей внутри продукта и зарабатывания денег. Поэтому у нас есть ограничения и иногда нам фичи сделать важнее, чем сделать все по красоте. Так появляется техдолг и потребность в рефакторинге. Сейчас стандартным подходом является создание отдельных сервисов, но у нас появляются проблемы
• High coupling и low cohesion (а нужно конечно наоборот)
• Это приводит к сложности в изменении и обслуживании этих систем
• У нас часто появляются проблемы с методами сервисов, которые имеют больше одной причины для изменений (продолжение single responsibility principle и separation of concern)
• Само свойство систем приводит к большому количеству связей и повышению сложности, если мы не боремся с этим
• Стандартная многозвенная архитектура нам не помогает - у нас есть проблемы с пониманием и изменением кода, так как надо держать все части приложения в голове. Также появляются проблемы со сложностью кода, производительностью и масштабируемостью систем.

И автор предлагает серебрянную пулю в виде vertical slice architecture, где у нас

• Организация кода предполагается по сценариям использования, а не по технической ответственности
• Мы пишем отдельный код для слайсов, а не переиспользуем существующий
• В слайсах мы пишем только тот код, что нужен сейчас. Если в будущем появится новые потребности, то мы добавим их в слайсы (~~все 100500, которые сделаем в рамках своей архитектуры~~)

Дальше идут плюсы архитектуры, которые влияют на производительность разработчиков, так как она

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

Здесь мы легко обрабатываем срочность выпуска фич

• Срочные функции могут быть созданы и протестированы быстрее, без компромиссов в коде (просто ~~добавь воды~~ сделай еще один слайс )
• Код под кастомного пользователя может быть написан в отдельной вертикали, что позволяет избежать загрязнения существующего кода
• Технический долг и рефакторинг также могут быть выполнены более эффективно, так как мы можем его отдавать по слайсам

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

Ну и напоследок автор говорит, что некоторый код все-таки надо шарить (~~сюрприз~~) и автор предлагает правило трех (||как правило трех конвертов||), которое гласит, что если код повторяется три раза, его следует извлечь в новую процедуру. Но самое важное, что автор оставил напоследок это то, что модели предметной области хорошо подходят для совместного использования кода, так как они моделируют бизнес-правила и изменения в бизнесе.

#Architecture #Software #SystemDesign #SoftwareArchitecture