ИТ блог, про Управление разработкой, Управление командой, Управление проектом, Управление продуктом, Саморазвитие, Архитектура - все это ежедновно на канале.
Молодые и опытные TeamLead’ы и руководители тимлидов найдут на канале много полезного.
ИТ блог, про Управление разработкой, Управление командой, Управление проектом, Управление продуктом, Саморазвитие, Архитектура - все это ежедновно на канале.
Молодые и опытные TeamLead’ы и руководители тимлидов найдут на канале много полезного.
🏗️ Гексагон и луковица: зачем разворачивать зависимости
Гексагональная архитектура (Ports & Adapters) и Onion — два названия одной идеи: бизнес-логика образует ядро, изолированное от внешнего мира, а UI, базы данных, очереди и сторонние сервисы подключаются снаружи через порты и адаптеры. Механика у обоих одна — инверсия зависимостей, поднятая с уровня классов до уровня всего приложения.
Зачем это нужно: ядро тестируется без базы данных и HTTP — на место адаптеров подставляются заглушки, и тесты за доли секунды проверяют именно бизнес-правила. Смена базы, протокола или UI-фреймворка перестаёт быть событием для домена.
💡 Паттерны появились как ответ на дефект классической слоистой схемы, где домен зависит от слоя доступа к данным, и в бизнес-логику просачиваются схема БД, SQL и детали ORM. Clean Architecture — прямой синтез обоих подходов.
Когда оправдано: сложная доменная логика (биллинг, страхование, логистика), много доставок и интеграций, долгоживущий продукт. Для простых CRUD честный controller → service → repository дешевле.
🔗 Hexagonal (Ports & Adapters) и Onion: https://agaltsovav.ru/docs/architecture/hexagonal-onion/
«Agaltsov Anton | TeamLead-блог» - канал из категории «Блоги», подключенный к сервису кросспостинга MaxGate. Публикации канала синхронизируются между Telegram и мессенджером MAX, а на этой странице собраны ссылки на обе версии канала.
Сейчас у канала 995 подписчиков суммарно в Telegram и MAX. За последние 30 дней в истории MaxGate учтено 34 публикаций, поэтому перед подпиской можно оценить не только размер аудитории, но и регулярность обновлений.
Чтобы подписаться, используйте кнопки «Открыть в MAX» и «Открыть в Telegram» в верхней части страницы. У отдельных постов ссылка может быть доступна в обоих мессенджерах или только в одном из них, если MaxGate получил такой URL из истории обработки.
📊 Воронки и конверсии: где продукт теряет пользователей
Воронка раскладывает путь пользователя на измеримые шаги и показывает, сколько людей доходит до каждого. Главная задача — не следить за всеми конверсиями сразу, а найти узкое горлышко: шаг, на котором теряется больше всего людей.
Арифметика здесь решает: сквозная конверсия равна произведению шаговых, поэтому улучшения накапливаются мультипликативно — рост каждой из четырёх конверсий на 10% даёт не +10%, а +46% к итогу. При этом усилия стоят вкладывать именно в слабое звено: у сильных шагов просто нет запаса для роста.
Проценты часто скрывают масштаб потерь: шаг с «здоровой» конверсией 50% может терять больше людей в абсолютных числалах, чем финальный шаг оплаты. Приоритет определяется произведением низкой конверсии на большие абсолютные потери.
Воронка отвечает на вопрос «где», но не «почему»: причина отвала выясняется интервью, записями сессий и тепловыми картами, а решение проверяется экспериментом.
🔗 Подробнее: https://agaltsovav.ru/docs/product-managment/funnels-and-conversions/
🗺️ Driven-подходы: что их различает и как выбрать свой
Все «*DD» — от TDD до Risk-Driven Development — различаются движущей силой: артефактом, который принимает решения за команду и отвечает на вопрос «почему мы делаем именно так». Тест, домен, гипотеза, реестр рисков или контракт — сила своя у каждого уровня разработки.
У подходов общая анатомия: артефакт создаётся до основного труда, работа идёт короткими циклами с быстрой обратной связью, а решение считается принятым, когда артефакт «зелёный» — тест прошёл, гипотеза подтверждена данными, контракт соблюдён.
Подходы не конкурируют за одно место: TDD страхует код, BDD — взаимопонимание с заказчиком, DDD — структуру системы, Risk-DD — фокус архитектурных усилий. Зрелая организация применяет несколько одновременно — каждое на своём уровне.
Завершается серия статей о driven-подходах. В обзоре — сравнительная таблица одиннадцати методологий, дизамбигуация аббревиатур (TDD: Test и Type, FDD: Feature и Fear, RDD: Risk и Readme), дерево выбора и группировка по семействам.
🔗 Полный обзор серии: https://agaltsovav.ru/docs/development-managment/driven-development-overview/
📈 Масштабируемость: не «сколько система тянет сейчас», а «что с ней будет завтра»
Масштабируемость — это не скорость системы при текущей нагрузке, а её поведение при росте: сохранит ли она время отклика и долю ошибок, когда пользователей и данных станет в десять раз больше. Быстрая система может не масштабироваться, а масштабируемая — быть неторопливой на малой нагрузке.
Два пути добавить мощности различаются направлением. Вертикальное масштабирование усиливает один узел: больше ядер, памяти, быстрее диски — просто, но с физическим потолком и нелинейно растущей ценой. Горизонтальное добавляет узлы: почти неограниченный предел роста за commodity-цены, но платой становятся распределённая сложность, балансировка и согласованность данных.
⚠️ Закон Амдала задаёт жёсткую арифметику: если 10–20% работы последовательны, то N узлов не дадут N-кратного ускорения — потолок окажется на уровне 5–10x, и узлы сверх него не окупятся. Измерение узких мест предшествует масштабированию, а не следует за ним.
Типичная ошибка — строить шардинг и микросервисы под «миллион пользователей», пока продукт обслуживает тысячи: Stack Overflow и Shopify годами держали миллионы пользователей на нескольких мощных серверах. Заимствовать у FAANG стоит принципы, а не топологии.
🔗 Подробнее: https://agaltsovav.ru/docs/architecture/scalability/
