🤯 Vertical Slice Architecture vs Onion Architecture — не надо выбирать, берите оба
Спойлер: они про разное. И отлично уживаются вместе.

🧅 Луковая архитектура (Onion Architecture)
Придумал Джеффри Палермо в 2008.
Идея: код — как луковица, в центре бизнес-логика, вокруг слои: инфраструктура, API, базы данных.
Главное правило: зависимости только внутрь. Внешние слои знают про центр, центр — не знает про них.
Зачем:
✅ Бизнес‑логика не зависит от технологий
✅ Легко менять базу данных или API
✅ Всё можно протестировать изолированно
Минус: слоёв много. Для простой фичи приходится править файлы в трёх местах.

🍕 Вертикальные срезы/слайсы (Vertical Slice Architecture)
Продвинул Джимми Богард в 2018.
Идея: не делить код на слои (контроллеры, сервисы, репозитории), а группировать по фичам.
В одной папке лежит всё, что нужно для выполнения одного сценария: от запроса до SQL.
Зачем:
✅ Одну фичу может делать один разработчик — не конфликтуют
✅ Фичу легко удалить — просто стереть папку
✅ Не нужно лазить по всему проекту
Минус: если не следить, код дублируется в разных слайсах.

🔥 А теперь главное: как их соединять
Многие думают, что это взаимоисключающие подходы, но это не так
Схема «брак по расчёту»:
На верхнем уровне — вертикальные слайсы.
Делим проект по фичам: Orders, Products, Users. Каждая фича — независимая папка.
Внутри каждой фичи — луковая архитектура.
Свои слои: бизнес‑логика, инфраструктура, API. Зависимости — строго внутрь.
Что получается:
Вертикальные слайсы отвечают на вопрос: Как сгруппировать код, чтобы не мешать друг другу?
Луковая архитектура отвечает на вопрос: Как организовать зависимости, чтобы бизнес‑логика не привязывалась к базе данных?
Внутри одного слайса PlaceOrder вы можете использовать MediatR, CQRS, чёткие слои. Но соседний слайс CancelOrder об этом ничего не знает.

📦 Пример на пальцах

src/
├── Features/
│   ├── Orders/
│   │   ├── PlaceOrder/           # Вертикальный слайс
│   │   │   ├── Domain/           # Луковая архитектура внутри
│   │   │   ├── Application/
│   │   │   ├── Infrastructure/
│   │   │   └── Presentation/
│   │   └── CancelOrder/          # Другой слайс
│   └── Products/

🎓 Моё резюме
Onion защищает бизнес‑логику от внешнего мира.
Vertical Slice защищает разработчиков друг от друга.
Не выбирайте один подход. Берите лучшее от каждого. Архитектура должна работать на проект, а не проект на архитектуру.

#Инструменты #Термины

📄TypeSpec: новый язык для API или очередная мода?
На Analyst Days 22 Руслан Папенко рассказывал про TypeSpec от Microsoft. Тема действительно горячая, но в индустрии любят волны хайпа — был RAML, был API Blueprint, теперь вот TypeSpec.
Я послушала, сравнила с OpenAPI и альтернативами. Делюсь выжимкой для прагматиков.

🧐 Что такое TypeSpec
TypeSpec — это предметно-ориентированный язык (DSL) для описания API. Он не заменяет OpenAPI напрямую, а компилируется в него (и не только). Релиз — апрель 2024, Microsoft, открытый исходный код.
Синтаксис напоминает TypeScript. Вы описываете модели данных, операции, а генератор выдаёт:
➖ спецификацию OpenAPI (YAML/JSON)
➖ документацию (например, HTML/Markdown)
➖ клиентские SDK на нескольких языках (основная поддержка TypeScript, .NET, Java, Python)
➖ генерация серверных заглушек (ограничена в основном .NET и JavaScript)
Звучит круто. Но давайте по фактам.

⚔️ Почему OpenAPI уже не торт
Презентация Руслана на Analyst Days и мнения инженеров со всего мира сходятся: OpenAPI, при всей своей популярности, доставляет много боли.
❌ Проблема №1: Нечеловеческий синтаксис
OpenAPI использует YAML или JSON — форматы, удобные для машин, но не для людей. Описания получаются многословными, часто похожими на «спагетти» из вложенных блоков. А разработчики с усталостью вспоминают, что им постоянно приходится подсматривать в документацию даже для простых вещей.
❌ Проблема №2: Сложность на масштабе
Если в проекте больше пары десятков эндпоинтов, спецификация превращается в гигантский файл (условно на 2000-3000+ строк). Отладка и поддержка такой простыни становятся крайне трудоёмкими.
❌ Проблема №3: Design-First страдает
OpenAPI создавался как формат документации готового API, не спорю, что далее он уже развивалась как формат для Design first. Если мы говорим про объёмные enterprise-системы, то вносить точечные изменения в разросшиеся YAML-файлы — пытка, да — есть визуальные редакторы...

💡 Чем TypeSpec лучше
Если взять простой пример (приводить не буду, был на конференции и полно в "интернетах"), то разница очевидна, разница будет раза в 3 по количеству строк.
✅ Композиция без боли
✅ Не привязан к REST
Описав модели, можно сгенерировать не только OpenAPI, но и gRPC (protobuf), AsyncAPI для сообщений, даже GraphQL.
✅ Один источник правды
Меняете модель — перегенерировали клиента, документацию, моки. Забыли обновить документацию вручную — не ваш случай.

🔄 Полная картина: какие есть альтернативы
Вопрос рёбром: инновация или тренд? Хочу расширить контекст. TypeSpec — не единственный игрок на поле «API как код».
1️⃣ Design First
Платформы вроде Apidog или Stoplight Studio отходят от сырого YAML . Они предлагают визуальные редакторы, схемы перетаскиванием, авто-моки и документацию на лету.
Плюсы: GUI понятен даже нетехническим специалистам. Минусы: GitHub не всегда удобен для ревью тяжелых PNG.
2️⃣ Code First
Инструменты вроде Swaggo (Go) или SpringDoc (Java) парсят комментарии в коде и генерируют OpenAPI.
Плюсы: Документация всегда соответствует коду. Минусы: Код обрастает аннотациями, сложно охватить всю систему целиком.
3️⃣ Альтернативные DSL и Protocol Buffers
Если TypeSpec от Microsoft, то Smithy от Amazon (используется в AWS) существует дольше.
Protocol Buffers (protobuf) от Google — вообще тяжёлая артиллерия для микросервисов.
Плюсы: Скорость, строгая типизация, поддержка в любом языке. Минусы: Бинарный протокол, REST вы получаете через транзакцию.

🎓 Моё резюме
Инструмент действительно зрелый, но ещё не полностью готов для промышленного использования всеми командами в любом масштабе.
Пробовали уже TypeSpec? Или всё ещё на YAML? 👇

#Инструменты

🖋Конструктивная критика: что это такое (и что — нет)
📖 Определение
Конструктивная критика — форма обратной связи, которая направлена на выявление недостатков и предложений по их устранению, осуществляемая с фокусом на позитивных аспектах работы. Это не просто указание на ошибки, а детальный и обоснованный анализ, который позволяет человеку увидеть свои слабые места и понять, каким образом он может улучшить свою практику.
В более широком философском смысле конструктивная критика — «созидательная критика, предлагающая конкретные пути решения проблем, реальные методы разрешения противоречий, эффективные способы преодоления заблуждений». В отличие от негативной, разрушительной критики («голого» отрицания всего и вся), конструктивная критика не просто отбрасывает критикуемые концепции, но сохраняет их позитивное, рациональное содержание.
Неконструктивная критика — оценка личности, обобщения, эмоции без фактов.

🧠 Ключевое различие: факты vs оценки
Факты можно проверить. Оценки — это чужое мнение, часто эмоциональное.
❌ «Ты вечно опаздываешь» — это оценка, обобщение.
✅ «Ты пришёл на встречу в 10:15 вместо 10:00» — это факт.
❌ «Ты пишешь ужасный код» — оценка личности.
✅ «Этот метод не обрабатывает null» — факт.
❌ «Ты не умеешь писать ТЗ» — оценка.
✅ «В разделе 2 нет ошибочного сценария» — факт.

⚖️ Почему люди боятся критики
Исследования показывают: мозг реагирует на критику так же, как на физическую боль. Поэтому даже нейтральные замечания воспринимаются как угроза.
Конструктивная критика снижает эту реакцию, потому что:
➖даёт понятные рамки («сделай вот это» вместо «ты плохой»)
➖оставляет лицо («я совершил ошибку», а не «я — ошибка»)

📌 Примеры из практики
Ситуация: Коллега перебивает вас на совещаниях.
❌ Неконструктивно: «Ты грубиян, вечно меня перебиваешь».
✅ Конструктивно: «На последних трёх совещаниях, когда я начинал говорить про API, ты вступался в диалог. Мне сложно донести мысль. Давай договоримся: я поднимаю руку или говорю «дай закончить», и ты ждёшь паузы».
Ситуация: Студент сдал отчёт с ошибками в формулах.
❌ Неконструктивно: «Ты безграмотный, не учил матан».
✅ Конструктивно: «В разделе 3 во второй формуле неправильно посчитана дисперсия. Ошибка в знаменателе. Сверься с методичкой на стр. 15 и приди на консультацию завтра».
Ситуация: Разработчик прислал код с проблемами.
❌ Неконструктивно: «Ты халтурщик, переделывай всё».
✅ Конструктивно: «В этом классе нет обработки ошибок при пустом вводе. Пользователь увидит непонятное сообщение. Добавь проверку и верни на ревью».

🎓 Моё резюме
Конструктивная критика — это не про «быть вежливым». Это про точность и полезность. Она — важнейшее условие для профессионального развития. Если вы не можете сформулировать, что конкретно не так или что делать, — не критикуйте. Сначала поймите сами.
#Карьера