Комментарии 17
Правильная структура папок выглядит всё же так:
/
├── user/
│ ├── user.model.ts
| ├── card/
│ ├── row/
│ ├── link/
│ └── edit/
├── search/
│ ├── search.model.ts
| ├── form/
│ └── results/
├── cart/
│ ├── cart.model.ts
│ ├── page/
| └── snippet/
├── category/
│ ├── category.model.ts
│ ├── page/
| └── snippet/
└── model/
Я не знаю, что такое "Правильная структура". Я предпочитаю пользоваться термином - логичная.
Наверно, ваш вариант, в вашем контексте - логичный. В моём - нет.
Лет через 10 поймёте, что ваша "логичная структура" не масштабируется. Простите за спойлер.
Не понимаю, как структура папок может масштабироваться. Что Вы имеете ввиду?
Я нигде не написал , что она масштабируется.
На данный момент я уверен, что она НЕ должна масштабироваться. Она должна эволиционировать в пакеты. Максимальная эволюция, когда проект состоит только из пактов и конфига. Моя структура этому не мешает, скорее даже способствует.
Очень просто: корзина разрастается настолько, что для работы с ней выделяется отдельная команда, которой нужен отдельный репозиторий с отдельным релизным циклом. Ваши действия?
так... допустим... Собираем слои в пакет, кладем в папку pkg на "передержку". Что бы дозрел. Выносим пакет в отдельный репозиторий. Корзина релизится как пакет с версионностью и все дела. При этом пакет может содержать все три слоя, а может только 1 слой, а может сразу содержать все слои сконфигурированные в модуль. Здесь зависит от контекста.
Конечно, я сделаю сразу пакет, если точно уверен в его границах. Если не уверен не сделаю.
Но я не знаю будущее, иначе я бы сейчас не писал коммент, а играл на бирже или в казино.
Ну вот я и дал вам инсайд из будущего, чтобы не приходилось делать капитальный рефакторинг по мере роста проекта.
корзина разрастается настолько
В моем понимании "масштабируется" и "разрастается" - это разные термины.
А... еще если Вы посмотрите на SFS структуру, то можете заметить, что это почти тоже самое что у Вас в первом комментарии.
Поэтому даже в моём контексте Ваша структура вполне логична и соотвествует тому, что написано в статье.
Ну, если уж говорить про эксперименты, то мы пришли к выводу оформлять любые самостоятельные части отдельными пакетами.
Работа с api сервера - отдельный пакет. Всякие сервисы, например, шифрование, - отдельный пакет. UI kit - отдельный пакет. Даже общий компонент как меню навигации для группы страниц - тоже может стать полноценным отдельным пакетом.
Вот такая структура позволяет сосредоточиться на реальном фронтенде: сама страничка, импортированные сконфигурированные ui-компоненты и бизнес-логика.
Даже если вы работаете в соло, можно импортировать пакеты из локальных папок и прекрасно с этим работать.
Чем проще, понятнее, тем быстрее напишете продукт.
Многие не согласятся с такой структурой, я отвечу так: представь, ты новичок в проекте. Ты что-то слышал о слоённой архитектуре, примерно понимаешь, что такое модули. Ты ещё не открывал проект, не знаешь структуру папок.
Почему многие не согласятся и какую альтернативу они предлагают?
Эти архитектурные паттерны Я слышал под названием feaure-first и layer-first.
В целом хочется отметить, что стоит стремиться к feature first подходу, т.к он лучше поддерживает декомпозицию и понятнее для новых людей.
К сожалению, он сложнее чем layer-first для новичков и для собственно проектирования.
Универсального ответа нет, в вашем домене и на вашем проекте может быть лучше другой подход
Суть статьи и выводы, мне кажется, очень сочетаются с "Законом Мелвина Конвея".
Всегда считал его глубоким и отвечающим на многие вопросы CS.
Формируй структуру папок согласно делению на модули и слои