И строить архитектуру приложения вот так, без привязки к удобству/простоте/легкости/понятности написания кода это конечно жесть.
Архитектура это не про простоту, а про масштабируемость. Вот размажете вы свою очередную бизнес-фичу по разным слоям, а потом через год-два прилетит задача на другого человека и ему придётся вырывать эту логику из этой "архитектуры".
Так и не увидел никакой выгоды. Крайне не убедительные слова не подкрепленные ни одним конкретным примером который можно проверить/воспроизвести.
Так и у вас не было примеров, которые можно воспроизвести. Покажите мне проект с 5+ лет жизни и затронутый больше 10 разработчиками с классической архитектурой и кучей бизнес-логики, который легко поддерживать и масштабировать. Не можете? Вот и я не могу. Разве что могу сказать, что книги по архитектуре диктуют то, что нужно отталкиваться от бизнес-домена.
А вообще весь этот спор не имеет смысла, потому что не были озвучены исходные данные проекта. Если мы говорим про маложивущие и простые проекты, то ваш способ конечно подойдёт и я бы сказал будет лучше.
Про выгоду разработки от бизнесового домена. Легче менять какую-то бизнесовую логику и есть чёткое разграничение между ui и бизнес-логикой. Постановки чаще всего летят от аналитиков, а не от дизайнеров. Луковая архитектура, ddd - также предлагают бизнесовый домен делать независимым от всего, ядром архитектуры.
Ну да, индивидуально. Я пробовал оба варианта. Вариант с одной components на модуль хорош тем, что не нужно в рамках модуля думать о композиции его частей. На плоскую структуру проще смотреть, можно пробежавшись взглядом увидеть от каких частей зависит модуль
Крутая статья!!! Только некоторые моменты смущают. Отпишу, чтобы показаться умным xD:
«useMyComponent.ts (для компонентов с бизнес логикой)» - смутило то, что какая-то часть бизнес-логики пишется в хуках, хотя у вас уже есть для этого стейт-менеджер (zustand). Такую "бизнес-логику" сложно отдирать от юайной логики, особенно если кто-то напичкает в этот хук useEffect'ов
То что можно делать папки components любой вложенности тоже не понравилось. Имхо, но лучше делать одну папку components для компонента и уже в ней создавать остальные компоненты. Проще понять какие самописные компоненты используются и не надо погружаться в ад из папок components
«Пример — тип, описывающий HTML-форму, у которой набор полей на фронтенде не совпадает с моделью бэкенда» - звучит как несоблюдение контракта. Без единого источника истины возникают разного рода конфликты
Написание своих моделей и клиента (функций для взаимодействия с бэком) очень геморный процесс. Можно генерировать по свагеру на фронте модели и клиента, что позволит мгновенно синхронизировать контракт с бэком. Также можно настроить мок-сервер и api-first, но это большая работа)
Использовали react + mobx + react-ioc. Очень понравилось такая связка. По сути react-ioc на wroud можно заменить, вроде не сильно отличаются
Бизнес-логику в принципе нельзя поменять, она исходит от бизнеса. Можно разве что сделать её прозрачнее, не размазывая по всему проекту.
Поэтому я и сказал, что спор бессмысленный. Мы говорим о разных проектах.
Архитектура это не про простоту, а про масштабируемость. Вот размажете вы свою очередную бизнес-фичу по разным слоям, а потом через год-два прилетит задача на другого человека и ему придётся вырывать эту логику из этой "архитектуры".
Так и у вас не было примеров, которые можно воспроизвести. Покажите мне проект с 5+ лет жизни и затронутый больше 10 разработчиками с классической архитектурой и кучей бизнес-логики, который легко поддерживать и масштабировать. Не можете? Вот и я не могу. Разве что могу сказать, что книги по архитектуре диктуют то, что нужно отталкиваться от бизнес-домена.
А вообще весь этот спор не имеет смысла, потому что не были озвучены исходные данные проекта. Если мы говорим про маложивущие и простые проекты, то ваш способ конечно подойдёт и я бы сказал будет лучше.
Про выгоду разработки от бизнесового домена. Легче менять какую-то бизнесовую логику и есть чёткое разграничение между ui и бизнес-логикой. Постановки чаще всего летят от аналитиков, а не от дизайнеров. Луковая архитектура, ddd - также предлагают бизнесовый домен делать независимым от всего, ядром архитектуры.
Ну да, индивидуально. Я пробовал оба варианта. Вариант с одной components на модуль хорош тем, что не нужно в рамках модуля думать о композиции его частей. На плоскую структуру проще смотреть, можно пробежавшись взглядом увидеть от каких частей зависит модуль
Крутая статья!!! Только некоторые моменты смущают. Отпишу, чтобы показаться умным xD:
«useMyComponent.ts (для компонентов с бизнес логикой)» - смутило то, что какая-то часть бизнес-логики пишется в хуках, хотя у вас уже есть для этого стейт-менеджер (zustand). Такую "бизнес-логику" сложно отдирать от юайной логики, особенно если кто-то напичкает в этот хук useEffect'ов
То что можно делать папки components любой вложенности тоже не понравилось. Имхо, но лучше делать одну папку components для компонента и уже в ней создавать остальные компоненты. Проще понять какие самописные компоненты используются и не надо погружаться в ад из папок components
«Пример — тип, описывающий HTML-форму, у которой набор полей на фронтенде не совпадает с моделью бэкенда» - звучит как несоблюдение контракта. Без единого источника истины возникают разного рода конфликты
Написание своих моделей и клиента (функций для взаимодействия с бэком) очень геморный процесс. Можно генерировать по свагеру на фронте модели и клиента, что позволит мгновенно синхронизировать контракт с бэком. Также можно настроить мок-сервер и api-first, но это большая работа)