Software Architecture: The Hard Parts — выпуск 2

Вторая встреча посвящена выбору способа декомпозиции монолита. Если компоненты выделимы, их приводят в порядок и извлекают. Иначе tactical forking копирует приложение для двух команд, после чего каждая удаляет чужой код. Это даёт быстрый старт, но удваивает технический долг.

Текущее разбиение оценивают через abstractness, instability и distance from the main sequence. Instability использует fan-in и fan-out. Конкретный стабильный модуль попадает в zone of pain, абстрактный модуль без потребителей — в zone of uselessness. Участники спорят о пользе подсчёта интерфейсов сегодня.

Component-based decomposition начинается с поиска и измерения компонентов. Большие области дробят, повторяющиеся доменные части объединяют, а namespaces уплощают. Fitness functions отмечают неожиданные компоненты, выбросы размера и запрещённые зависимости. Это governance-сигналы, а не безусловные запреты.

Компоненты группируют в домены и затем решают, нужен ли отдельный runtime; иногда достаточно service-based monolith с общей базой. Shared logic выносят в библиотеку или сервис, но сервис добавляет сеть, latency и отказы. Границы связывают с bounded contexts и транзакциями: без ясной бизнес-модели распил создаёт распределённый монолит.