Ранняя изоляция компонент vs прагматизм: когда жёсткие границы компонент убивают гибкость и скорость разработки

Изоляция компонентов нужна для управления сложностью, особенно для больших команд и программ. Но её раннее применение часто противоречит целей по гибкости, особенно в начале, когда ещё не известны или не сложились бизнес процессы, когда программу ещё пишет небольшая команда.

Изменение границ компонент это сложно. В ООП это сложнее чем в ФП из-за более крупной гранулярности, класс сложнее чем отдельная функция. Изменение границ микросервисов сложнее чем в монолите.

Проблема ранней изоляции: —

Необходимость частого рефакторинга на раннем этапе

Тонкая прослойка как компромисс: — Например, обёртки над библиотечными классами добавляют функционал с минимальным вмешательством и без необходимости писать всё с нуля.

Гибридный подход: — Функциональный домен, императивная оболочка.

Домен — функциональное ядро: Бизнес-логика в чистых функциях, независимых от инфраструктуры.

Оболочка — императивная. Необходимость интеграции с ООП библиотеками (io, фреймворки) заставляет писать эту часть в ООП. Но можно использовать тонкие прослойки для интеграции для минимизации boilerplate.

Риски: — Скрытая привязка к библиотеке: Домен косвенно зависит от её типов. — Сложность замены: Если библиотека всё же потребует замены, придётся модифицировать методы расширения.

Итог: Ранняя изоляция через толстые адаптеры часто избыточна.

Методика

Как же тогда должна выглядеть методика обследования и проектирования на основе DDD, но оставляя гибкими границы доменов по bounded context до нужного момента?

Методика пригодна как для проектирования архитектуры доменных компонент, так и более мелкого уровня детализации (структуры данных и функции).

Определения (мои)

0. Состояние — наблюдаемое явление, фиксированный набор значений параметров системы или её части в определённый момент времени, определяющий её поведение и доступные действия.

1. Типы → Категории возможных состояний системы и их допустимых комбинаций.

2. События → Факты о произошедших изменениях (прошлые состояния).

3. Процессы → Механизмы перехода между состояниями (будущие изменения состояний).

Последовательность проектирования компонент (домена DDD либо более мелких сущностей):

1. Анализ домена:

— Event Storming → выявление ключевых событий и процессов.

— Определение Bounded Context → границы модулей. Домен должен быть такой чтобы помещался а голове одного доменного эксперта. Если говорить про модули кода, то принцип единственной ответственности не позволит вырасти когнитивной сложности компонента, так как не смешивает разные предметные области в одном коде.

2. Моделирование типами:

— Каждое доменное понятие → алгебраический тип данных, определяет набор возможных состояний и их комбинаций.

— Бизнес-правила → валидаторы как функции.

3. Чистые функции для логики:

• Мелкая гранулярность в ФП позволит легко переносить функционал через границу компонент

• Сервисы → композиция pure-функций

• Обработка ошибок → Either/Result типы.

4. Изоляция эффектов и состояний:

IO-операции → отдельный слой (Http, БД).

Использование СУБД выноса состояний наружу или монад для отсутствия скрытых побочных эффектов / состояний. Если это сложно или не эффективно, то для реализации состояний можно использовать состояние объекта в ООП. Также ООП имеет преимущество если ООП библиотеки уже реализуют почти всю логику вашей предметной области и ваши добавления незначительны.

5. Оптимизация скорости (при необходимости)

Когда же тонкая и гибкая прослойка должна стать жёсткой и надёжно изолирующей?

Выбор между тонкой и толстой прослойкой между компонентами зависит от контекста:

1. Тонкая прослойка (быстро/минимализм) или даже вызовы библиотек напрямую, жертвуя гибкостью и принципом единственной ответственности.

— Подходит, если термины библиотеки на 80% совпадают с вашим доменным языком.

— Подходит когда граница компонент ещё не сложилась, она может и должна легко меняться.

— Риск: Привязка к библиотеке, но экономия времени на разработку.

2. Толстая прослойка (надёжность/изоляция):

— Нужны доменные модели, полностью абстрагированные от библиотек.

— Границы компонент не меняются.

— Нужно надёжно изолировать компоненты, чтобы изменения в одних не требовали цепочку изменений других. Особенно, если другими компонентами уже владеет другая группа разработки.

Компромисс:

Даже минимальные адаптеры (интерфейсы + базовые преобразования) лучше, чем прямое использование библиотеки в ядре. Это сохраняет путь к будущим изменениям без переписывания системы.

Правило выбора:

Чем критичнее компонент для бизнеса и чем более стабильны границы между компонентами, тем «толще» должна быть прослойка между компонентами.