Рефакторинг ядра и разделение на фичи

Краткая сводка по результатам анализа @endge/core: потребность в переходе к feature-модульности при сохранении единого composition root.

Обоснование

В практике enterprise Low-Code (OutSystems, Mendix) и в крупных продуктах ядро платформы отделено от доменной и прикладной логики: kernel отвечает за жизненный цикл, федерацию модулей и контракты, а фичи (domain, runtime, auth, diagnostics и т.д.) — отдельными модулями с явными границами. Это упрощает онбординг, тестирование и эволюцию: изменения в одной фиче не размазаны по «всему ядру». Риск при откладывании: рост связанности, сложность рефакторинга и высокий порог входа для новых разработчиков.

Что видно сейчас

• Пакет ядра уже выполняет слишком много ролей одновременно: federation/kernel, domain, runtime, schema/db, bindings, flow, diagnostics, debug, UI-утилиты и общий публичный API.
• Основная сборка ядра происходит декларативно через EndgeFederation.define(...) и список ENDGE_CORE_MODULES; ручная однотипная регистрация Modules в Endge.configureFederation() больше не используется.
• По мере роста проекта это приводит не только к большим папкам, но и к размытию границ ответственности между подсистемами.
• Дополнительно это усиливается большим main.ts, который экспортирует почти все сущности и типы наружу.

К чему пришёл

• Перенос логики в отдельные feature-срезы возможен и выглядит правильным направлением развития.
• При этом сама федерация не должна разрастаться как место хранения всей предметной логики. Её лучше оставить как composition root и lifecycle-слой.
• Оптимальная модель для развития: тонкое ядро + feature-модули + общий shared/kernel слой.

Рекомендуемый вектор

• В core оставить базовые абстракции: federation, lifecycle, общие контракты, shared primitive types и минимальную инфраструктуру.
• Предметную и платформенную логику постепенно разводить по отдельным feature-направлениям:
  • domain
  • schema
  • runtime
  • bindings
  • contracts
  • flow
  • auth
  • vocabs
  • events
  • debug
  • diagnostics
  • ui
  • styles

Важный вывод

Просто разнести файлы по новым папкам недостаточно. Чтобы эта архитектура была действительно удобной, нужно постепенно сокращать прямую связанность модулей через глобальный Endge.* и выделять более явные контракты между фичами.

Риски и ограничения

• Рефакторинг без изменения поведения должен сохранять обратную совместимость API Endge.* на переходный период; иначе ломаются все потребители. Рекомендуется поэтапный перенос с сохранением фасадов.
• Зависимость: тесно связан с пунктами «Диагностика», «Обработка ошибок», «Конфигурация» — при выделении фич эти модули становятся естественными кандидатами на вынос или явные контракты.

Вывод

Рефакторинг ядра в сторону feature-модульности стоит планировать как отдельное стратегическое направление развития проекта. Приоритет: стратегический (фундамент для остальных направлений).