FeatureSlices существует на стыке множества разных подходов, там и .NET, и hexagonal, и вообще много опыта в разных сферах.
Сейчас, это методология, без жестких рамок. Основная цель — упростить добавление нового кода и изменение существующего.
Первое, что я стремлюсь сделать в любом проекте, это определить опасный и безопасный код. Опасный код — это такие строки в вашем проекте, изменение которых, может легко сломать зависящие от него модули. Безопасный код напротив, влияет лишь на модуль в котором он описан.
К сожалению, невозможно писать лишь безопасный код. Ведь тогда, от этого кода никто не зависит, а значит его никто не использует. А код который не используется — бесполезен.
К счастью, многолетняя история программирования подарила нам волшебную концепцию — инкапсуляцию. Мы можем скрыть детали реализации за красивым интерфейсом. И тут интерфейсом может быть всё что угодно: методы класса, интерфейсы джавы, экспорты в javascript и rust модулях и т.д.
Задача инкапсуляции — скрыть все детали под красивым названием, может даже несколькими. Ровно так мы и поступаем, когда заворачиваем несколько JSX-элементов в компонент с “говорящим” названием.
И если продолжить аналогию, то легко понять, что код внутри компонента безопасен, его можно менять не переживая, что где-то сломается код зависящий от этого компонента. Разумеется, это работает пока не изменяется интерфейс компонента — названия и типы его пропс.
Задача архитектуры разделить весь проект на высокоуровневые блоки-компоненты, обезопасив код внутри каждого.
Немного поразмыслив, я понял, что любой реюзабельный код опасен. Чем чаще его используют, тем сложнее вносить изменения в такой код. Но при этом, в проектах можно четко провести границу между опасным и безопасным кодом — просто положив код в разные директории со своей семантикой.
Если я понимаю с каким типом кода я работаю, я знаю, что я могу с ним сделать.
При некотором исследовании разных подходов, оказалось, что переиспользовать код страниц не имеет смысла. Ведь одна страница это один конкретный путь роутера.
При этом UI-компоненты, парсеры, конвертеры и прочий библиотечный код можно вполне закономерно вынести в директорию библиотечного кода, покрыть тестами, написать документацию. Чем не полноценный NPM-пакет.