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