Комментарии 7
По моему, если вдохновляться fsd, то какие вещи можно без изменения от туда брать. FSD он не только про размер строительных блоков, но и отношения между ними.
Вот вы пишете: Архитектура CLI. Дальшее идет перечисление ваших слоев и объяснением их семантики. И тут сразу несколько вопросов. Почему вы решили отказаться прям от всех слоев fsd? Каким образом выстроены отношения между слоями? Из представленного описания не очевидно направление зависимостей между слоями. Какие еще строительные блоки есть в вашей архитектуре?
Просто для примера рассмотрим, в fds есть слой app. У вас есть файл-простыня cli.ts. В нем куча захардкоженных сообщений, настроек и что-то мне подсказывает, что если вы заходите это расхардкодить то работать с этим сможет одновременно только один человек. Модульность как раз таких вещей позволяет избежать.
Я не отказался от всех слоёв FSD. Я изначально написал (пока что MVP) CLI для упрощение работы с рутиной и быстрому созданию в нужно слое компонент, фичи, сервисы, типы, которые относятся к ним. Не идеально еще конечно, но я буду улучшать. А по поводу хардкода, я с вами согласен, буду убирать и исправлять :)
а как вы это называете?
это один из аспектов архитектуры проекта.
Добрый день! Ну В FSD папки — это физическое отображение слоёв архитектуры. FSD же нам диктует, как и зачем код структурируется. Можно предложить их команде переделать официальное определение их детищу, но мне кажется, это самая, что есть архитектура :)

FSD Forge: Как я создал небольшую CLI для Feature-Sliced Design и почему это было нужно