На реальном кейсе посмотрим, как меняется цена изменений и где модульные подходы действительно снижают когнитивную нагрузку, а где добавляют новую бюрократию. Результатом станут практическая матрица решений и набор правил (public API, доменные границы, адаптеры контрактов), помогающие удерживать архитектуру под контролем независимо от выбранного подхода. Слушатели унесут с собой: - чек-лист симптомов превращения вашей модульной архитектуры в «папку components 2.0» - матрицу выбора и trade‑offs: когда FSD остаётся лучшим компромиссом, когда стоит вводить модульность / FEOD‑подобные правила точечно и как оценить цену бюрократии vs выигрыш в навигации/изменяемости - набор правил без полной миграции, снижающие хаос в ui композиции: public API для крупных блоков, запрет deep‑imports, явные точки композиции - рекомендации по сохранению «границы» модуля: как определить unit of ownership (по домену/сценарию), что считать публичным контрактом, как оформлять адаптеры между доменами (DTO/маппинг/валидация), чтобы изменения не разъезжались по слоям Презентация - https://disk.360.yandex.ru/i/gPW4JF_3b7Kv6w Сайт - https://16.codefest.ru