Agaltsov Anton | TeamLead-блог

🏗️ Слоистая архитектура: слои, зависимости и цена простоты Слоистая архитектура (Layered / N-tier) — самый старый и самый распространённый способ структурирования корпоративного ПО. Система делится на горизонтальные слои — представление, приложение, домен, доступ к данным, — и каждый слой выполняет строго одну роль. Правило зависимостей одно: только сверху вниз. Верхний слой пользуется услугами нижнего и ничего не знает о тех, кто выше. Идея восходит к разделению ответственности Дейкстры и работает от настольных приложений до современных бэкендов на Spring, ASP.NET и Django. ⚠️ У простоты есть цена: домен «протекает» в базу данных и фреймворк, бизнес-правила тяжело тестировать без инфраструктуры, а тонкий слой домена со временем деградирует в анемичную модель — набор структур без поведения. Clean Architecture, Hexagonal и Onion не отменили слои — они перевернули правило зависимостей: не «вниз», а «внутрь», к домену. Когда честная классика лучше нечестной чистоты — разбирается в статье. 🔗 Подробнее: https://agaltsovav.ru/docs/architecture/layered-architecture/

🌟 North Star Metric: одна метрика, которая задаёт курс всему продукту North Star Metric (NSM) — единственная ключевая метрика продукта, которая наилучшим образом отражает ценность, получаемую клиентами. Формула проста: ценность клиенту × польза бизнесу. Не «сколько фич выпустили» и не «сколько заработали», а «сколько клиентов получили результат, ради которого продукт существует». Выручка при этом не игнорируется — устойчивый рост NSM опережает и предсказывает финансовый результат. Классические примеры: ночи, забронированные на Airbnb; часы прослушивания в Spotify; сообщения, отправленные активными командами в Slack. Все три измеряют момент получения ценности, а не активность компании. 💡 NSM выбирается на годы — она стабильнее стратегических документов и живёт дольше квартальных циклов. Смена NSM — событие уровня смены стратегического фокуса, а не реакция на неудачный квартал. ⚠️ Метрика без дерева Input Metrics бесполезна — это «звезда без пути»: цель известна, а рычагов нет. Поэтому NSM всегда внедряется вместе с 3–5 поддерживающими метриками, на которые команды могут влиять напрямую. И работает закон Гудхарта: когда мера становится целью, она перестаёт быть хорошей мерой. Защита — guardrail-метрики и никакой прямой привязки бонусов к одному числу. 🔗 https://agaltsovav.ru/docs/product-managment/north-star-metric/ ENDOFPOST && ssh agaltsovav@100.64.0.4 wc -c /tmp/tg-post.txt

🧪 BDD — Behaviour Driven Development: поведение как общий язык BDD — методология, в которой разработку направляет поведение системы, описанное на языке, одинаково понятном бизнесу и инженерам. Подход сформулировал Дэн Норт в 2006 году: применяя TDD, он обнаружил, что метод не отвечает на три вопроса — где начинать, сколько тестировать и что именно проверять. Ответом стали сценарии «Дано — Когда — Тогда», которые рождаются до кода в совместном диалоге и затем исполняются как автоматические проверки. Ключевой сдвиг — переименование «тестов» в «поведение»: о поведении естественно говорить и бизнесу, и разработке. Отсюда главный тезис Новы: BDD — не про тесты, а про понимание и согласование требований; тесты здесь побочный продукт, а не цель. BDD живёт над TDD: он задаёт, какое поведение нужно реализовать, а TDD на уровне кода страхует, как это поведение устроено внутри. Сценарии в формате Gherkin (Cucumber, JBehave, SpecFlow) превращаются в живую спецификацию — документацию, которая не расходится с кодом, потому что исполняется вместе с ним. 💡 Эффект BDD проявляется на горизонте месяцев: накапливаясь, живая спецификация устраняет расхождение требований и кода по умолчанию. Оценивать его за один спринт — главная ошибка внедрения. 🔗 https://agaltsovav.ru/docs/development-managment/bdd-behaviour-driven-development/