Сформулируйте, какие конкретно цифры вы хотите получить - ПМы обещали собрать нужные метрики. Соберут, принесем.
Сложно расписывать в цифрах ощущения от работы. У меня сейчас есть два проекта. Один с FSD, другой - без. Я и без метрик вижу, что количество бойлерплейта на втором - в десятки раз больше. Сторипойнтов на задачи по поддержке/добавлению новых фич уходит в разы больше. Идешь в раздел, в котором давно не был - сидишь вкуриваешь гораздо дольше. Я же не сижу с секундомером.
Про традиционную архитектуру - распишите, что значит "нет", какая у вас архитекутра традиционная, из чего состоит, как устроена?
1. Тут хочу сказать только, что видимо потому, что у нас действительно маленькая команда была + быстро налаженный флоу - у нас такой проблемы не возникло. Базовый шэред создавался первым практически весь, поэтому в нем дублирования не было. Дальше "внезапных" моментов, что создавать то или иное не было - разработке каждого раздела предшествовал макет, и он же был перед глазами, когда мы создавали раздел.
Так же, я упоминал, была создана вся тех. документация с четкими соглашениями, поэтому все хуки, весь шэред, все компоненты - все написано в абсолютно одном стиле. Я пару раз возвращался рефакторить проект - дублирование отсутствует.
При чем не могу сказать, что нужны ЧАСТЫЕ синки - достаточно грамотно разбить раздел, разбить задачи и во время их выполнения следовать соглашениям.
2. Опять же, у нас не такой большой проект, и дизайн-система была неплохо прописана к началу разработки, т.е. мы видели и понимали бОльшую часть предстоящих кейсов по шереду + заложили классику кейсов на всякий случай - в итоге ни один компонент шэреда мы не переделывали. После релиза был создан новый шэред для более удобной работы с svg.
Тащить на другой проект - дело другое. Естественно, мы не могли при создании отталкиваться от потребностей других проектов, поэтому сейчас, когда стали тянуть этот шеред в другие проекты - он требует допила. Тут решение довольно просто - мы вынесли его в отдельный UI-кит пакет, где в дальнейшем и будут базироваться-создаваться эти компоненты, а с него уже тянуть по проектам. Никакой работы по месту в виде допила шереда в компонентах - это, конечно, плохо.
3. Безусловно. Поэтому я в последний выход на рынок себе на первое место в требованиях ставил работу над консистентным продуктом. Мне нравится изучать и применять архитектуру и паттерны, а в хаосе стартапов это все невозможно.
4. Мне кажется, бОльшую часть я все же уделил разбиению и построению наших FSD-макетов, а это буквально самое главное в процессе. Все остальное а) не столь важно, б) я упоминал в начале статьи, что про "обычные" нюансы FSD статей хватает. Статья изначально называлась "флоу разработки", но было решено заменить наиболее близким русским переводом. Может "флоу" в этом плане будет вам репрезентативней отражать то, что я хотел донести.
Вроде бы да, в этом флоу ничего особенного, однако именно он помог нам полностью избежать тех косяков ваших проектов, про которые вы упоминали. Кто-то скажет, "да вам повезло просто", "да просто проект легкий", "да я бы так же вообще легко сделал, и лучше еще" и еще десяток оправданий. Кто-то заметит, что, может быть, дело действительно в качественном флоу и его соблюдении командой. Истина, как обычно, где-то по середине. С чем мне точно "повезло" - так это с командой. Только настоящие профессионалы понимают ценность архитектуры, и готовы соблюдать единые стандарты и ограничения ради общего блага. К сожалению, на рынке лишь единицы понимают, почему это важно в долгосрочной перспективе
5. Сравнивать с другими моими проектами в других компаниях было бы некорректно. ПМы прочтя статью и комменты пообещали собрать метрики, может, упомяну в следующих статьях. Про доку я не даром упомянул, что разработал целый подход, она до сих пор сильно облегачает жизнь, хотя и не могу сказать, что прямо вся-вся востребована.
Про предпоследний абзац - не соглашусь. Ресурсов было немного, временные рамки были очень жесткие. Тут скорее личная мотивация каждого и профессионализм коллег сыграли в огромный плюс.
Про P.S: сквозь размытый скриншот вижу очень похожий функционал на то приложение, которое сейчас вдвоем с лидом мы переводим на FSD. Вот уж где сложность - и без того сложное и едущее приложение рефакторить и переводить на ходу на другую архитектуру. Но опыт и интерес просто бесценный.
Как раз про флоу процесса перевода такого большого и готового проекта на FSD и будет моя следующая статья.
Глядя на скриншот, хоть и плохо вижу, сразу вижу fsd-компоненты. Естественно, можно применять FSD, можно обойтись классикой (ничего не применять). Безусловно, чтобы переводить уже готовый и работающий проект на FSD - это очень трудозатратно и требует четкого понимания зачем и почему. Для разработчиков это зачастую чувствуется и без метрик - на уровне ощущений - поддержка проекта все растет во времени, что-то новое добавляется с проблемами, растут костыли. Но бизнесу и менеджерам это скорее всего не интересно: это непонятно и "дорого".
Давайте про это подискутируем под моей следующей статьей, когда я (надеюсь) опишу не только флоу, но и успешный опыт и результаты переезда готового проекта. Я постараюсь четко расписать причины этого переезда.
А закончить хочу вот этим абзацем от Роберта Мартина, нравится:
И спасибо вам за уделенное время и подробный анализ, дискутировать с такими людьми - одно удовольствие.
1. На самом больше вам не потребуется больше, эта архитектура создавалась не один день, с учетом требований практически любой разработки. Будем честны - что-то совсем "эдакое" и выбивающееся из некой общей массы встречается очень редко, если мы говорим про типичный фронт.
Какой компонент бы вы не выделили - будет отнесен к одному из существующих слоев. На практике чаще возникает ситуация, что команда думает, отнести компонент, допустим, к фичам или к сущностям, но такой ситуации, чтобы мы вообще не знали куда "положить" - не было ни разу, а проект на FSD у компании уже не единственный.
Почему именно 6 - результат ресерча создателей. Добавить новый вы не сможете и, как я уже сказал, не за чем. В этом и смысл любой архитектуры (схожий принцип и у фреймворков) - накладывать определенные ограничения, следуя которым, вы добьётесь хорошей структуры и прочих бенефитов. Как по мне здесь уместна аналогия с рецептами на приготовление из реальной жизни - они накладывают ограничения, но, если вы будете его соблюдать, то получите желаемое. Иначе, по неопытности, получится каша, отдаленно напоминающая желаемое.
2. Тут два варианта. Я пришел к тому, что создал внутри сущностей и фичей дополнительные папки, группирующие сущности/фичи по отношение к бизнес-сущности. Выглядит это примерно так: entities/ - /Order/ - /Restaurant/ - /Review/
И т.д. и т.п., внутри /Review/ в entities будут лежать например ReviewCard, ReviewPreview, ReviewFull. Внутри /Restaurant/ в features лежат CloseRestaurant, OpenRestaurant, EditRestaurant и т.д.
Второй вариант, официальный, упоминается в гайдлайнах - уход в монорепу с микрофронтами. Мы сейчас думаем, и скорее всего будем пробовать такой подход на втором проекте. Если коротко - каждая пейджа - отдельное FSD
3. Нет, связность получается очень низкая. Тут важную роль играет однонаправленность зависимостей. Сущности используют шаред (это могут быть адаптеры селектов, дропдаунов, текстареа, тогглы, чекбоксы, типография, и тд и тп), но не наоборот. Фичи вообще редко используют сущности. Виджеты/страницы собирают в себе сущности и фичи, но не наоборот.
4. Вкладка issues - это страница/виджет. Сущность не может содержать в себе страницу) В вашем случае, например, сущность - это само по себе "issue". Т.е. идите от бизнес-сущностей. Вот есть понятие "проблемы" - у него могут быть свои визуальные представления - карточка проблемы, а где-то это отразится как строчка в списке, - это сущности. Удаление/создание проблемы - фичи. Окошко по работе с проблемой, где можно ее создать/удалить/отредактировать, оставить комментарий, какие-то эмодзи прожать - виджет. Страница, на которой это все собрано - пейджа.
Если хотите, можете кинуть в комменты скрин какой-то любой страницы, вместе с вами разберем по FSD.
Вам fsd дорогу чем-то перешел, что вы с пеной у рта бегаете по fsd-постам и что-то кому-то доказываете? Аж три страницы комментариев по этой тематике на аккаунте с нулем публикаций)
Ну напишите пост какой-нибудь со сравнением одинаковых проектов, написанных на "классической" и fsd-архитектуре в динамике в крупном бизнесе, под ним и поговорим. А дальше вникать в пассажи безработных ноунеймов с синдромом утенка, боящихся не дай бог что-то новое узнать/попробовать не интересно, сорян)
Очередная, как... что например? Как функциональные компоненты в Реакте, которые тоже всех по началу пугали? Вы в FSD разбираетесь и на FSD работали? Применяли ее на своих проектах, метрики какие-то снимали с fsd и с не-fsd? Что-то мне подсказывает, что нет.
Про ограничения - почитайте, зачем в целом архитектура нужна. Я видел судьбу проектов "без всяких ограничений", когда время на поддержку растет пропорционально времени существования проекта и объему кода. Код без ограничений неизбежно превращается в бесформенную массу, какой бы талантливой не была команда.
> fsd никак и не соотносится с реальным миром
Только в ру-сегменте десятки топовых компаний (посмотрите на HH статистику по количеству требований знания/опыта fsd, посмотрите доклады Яндекса, Самоката и т.п.) применяют эту "мертворожденную фигню", видимо, чтобы страдать побольше.
Мне есть с чем сравнивать как в рамках предыдущих, так и в рамках текущих проектов. Наш FSD-проект безоговорочно лидирует по скорости погружения, поддержки и остальным плюсам, указанным в статье.
"Традиционной" архитектурой обычно является ее отсутствие, что приводит к адской неразберихе в корневых папках компонентов/хуков и т.д.
Ограничения существуют в любых архитектурах, и работают они на благо - ценой ограничений создается порядок и легкость поддержки. Чтобы понимать ценность архитектуры как таковой, почитайте какого-нибудь Дядюшку Бо, он в каждой своей книге про это пишет практически.
Голословные утверждения про "просто для всех" конечно хорошо, но опять же, в статье приведены реальные цифры и реальные итоги, опять же, сравнение с другими не-fsd проектами перед глазами.
Про хуки - для всей команды это был первый полноценный проект на FSD, поэтому в пути набили какие-то шишки. Оглядываясь назад - действительно, логичнее было бы создавать папки model, куда можно складывать также и апи для горизонтального взаимодействия: кросс-импортов (одна из самых больных тем fsd).
На эту тему мне понравился вот этот доклад с последней HolyJS Александра Моргунова, в нем как раз описывается этот кейс (да и многие другие, с которыми мы столкнулись в итоге)
1. Сущности и есть обобщенные модели, которые предназначены для использования в разных фичах. Это ни в коем случае не "свойства фичи", а скорее компонент, репрезентирующий ту или иную бизнес сущность.
Представим такую бизнес-сущность, как "продукт". У продукта могут быть следующие сущности: "карточка маленькая", "карточка большая", "список продуктов". Так что да, в итоге визуально это будет компонентом.
2. Экран/страница в FSD - page (в нашем случае route). Рут не может "принадлежать" фичам, наоборот, разные фичи включаются в рут. Иерархия в FSD вертикальная и однонаправленная. Горизонтальные взаимоотношения тоже возможны, но про них стоит поговорить отдельно.
Захотим добавить на страницу авторизацию? Добавляем в рут/пейджу фичу авторизации.
3. Тут всегда немного путает нейминг. Мне сильно проще воспринимать и выделять фичи помог совет из одного из докладов по FSD: фича = юзер процесс.
Пример про аналитику не совсем понял. Блок аналитики в малом представлении может быть сущностью, если это полноценная страница - пейдж, либо виджет, тут уже нужно смотреть на конкретный пример. Фича для примера, упоминавшегося выше - это например "оплата", или "добавление в корзину", или "удаление из корзины". В фиче может быть работа с апи и, например, оптимистичная мутация данных на фронте.
Договорились!
Имхо, иерархия взаимодействия - одна из двух ключевых составляющих FSD, наряду с изолированностью.
Самая частая проблема, с которой сталкиваются начинающие на FSD команды - запрет кросс-импортов.
Я обязательно расскажу, как мы с этим работали в другой статье, т.к. в эту не ложилось по смыслу.
Так получается, что практически любая структура ПО - это 1) стек, 2) структура папок и взаимосвязей. Напомните, что упустил)
FSD себя позиционирует как "архитектурная методология", пожалуй, мне это определение нравится.
Сформулируйте, какие конкретно цифры вы хотите получить - ПМы обещали собрать нужные метрики. Соберут, принесем.
Сложно расписывать в цифрах ощущения от работы. У меня сейчас есть два проекта. Один с FSD, другой - без. Я и без метрик вижу, что количество бойлерплейта на втором - в десятки раз больше. Сторипойнтов на задачи по поддержке/добавлению новых фич уходит в разы больше. Идешь в раздел, в котором давно не был - сидишь вкуриваешь гораздо дольше. Я же не сижу с секундомером.
Про традиционную архитектуру - распишите, что значит "нет", какая у вас архитекутра традиционная, из чего состоит, как устроена?
Спасибо за такой объемный и качественный коммент)
1. Тут хочу сказать только, что видимо потому, что у нас действительно маленькая команда была + быстро налаженный флоу - у нас такой проблемы не возникло. Базовый шэред создавался первым практически весь, поэтому в нем дублирования не было. Дальше "внезапных" моментов, что создавать то или иное не было - разработке каждого раздела предшествовал макет, и он же был перед глазами, когда мы создавали раздел.
Так же, я упоминал, была создана вся тех. документация с четкими соглашениями, поэтому все хуки, весь шэред, все компоненты - все написано в абсолютно одном стиле. Я пару раз возвращался рефакторить проект - дублирование отсутствует.
При чем не могу сказать, что нужны ЧАСТЫЕ синки - достаточно грамотно разбить раздел, разбить задачи и во время их выполнения следовать соглашениям.
2. Опять же, у нас не такой большой проект, и дизайн-система была неплохо прописана к началу разработки, т.е. мы видели и понимали бОльшую часть предстоящих кейсов по шереду + заложили классику кейсов на всякий случай - в итоге ни один компонент шэреда мы не переделывали. После релиза был создан новый шэред для более удобной работы с svg.
Тащить на другой проект - дело другое. Естественно, мы не могли при создании отталкиваться от потребностей других проектов, поэтому сейчас, когда стали тянуть этот шеред в другие проекты - он требует допила. Тут решение довольно просто - мы вынесли его в отдельный UI-кит пакет, где в дальнейшем и будут базироваться-создаваться эти компоненты, а с него уже тянуть по проектам. Никакой работы по месту в виде допила шереда в компонентах - это, конечно, плохо.
3. Безусловно. Поэтому я в последний выход на рынок себе на первое место в требованиях ставил работу над консистентным продуктом. Мне нравится изучать и применять архитектуру и паттерны, а в хаосе стартапов это все невозможно.
4. Мне кажется, бОльшую часть я все же уделил разбиению и построению наших FSD-макетов, а это буквально самое главное в процессе. Все остальное а) не столь важно, б) я упоминал в начале статьи, что про "обычные" нюансы FSD статей хватает. Статья изначально называлась "флоу разработки", но было решено заменить наиболее близким русским переводом. Может "флоу" в этом плане будет вам репрезентативней отражать то, что я хотел донести.
Вроде бы да, в этом флоу ничего особенного, однако именно он помог нам полностью избежать тех косяков ваших проектов, про которые вы упоминали. Кто-то скажет, "да вам повезло просто", "да просто проект легкий", "да я бы так же вообще легко сделал, и лучше еще" и еще десяток оправданий. Кто-то заметит, что, может быть, дело действительно в качественном флоу и его соблюдении командой. Истина, как обычно, где-то по середине. С чем мне точно "повезло" - так это с командой. Только настоящие профессионалы понимают ценность архитектуры, и готовы соблюдать единые стандарты и ограничения ради общего блага. К сожалению, на рынке лишь единицы понимают, почему это важно в долгосрочной перспективе
5. Сравнивать с другими моими проектами в других компаниях было бы некорректно. ПМы прочтя статью и комменты пообещали собрать метрики, может, упомяну в следующих статьях. Про доку я не даром упомянул, что разработал целый подход, она до сих пор сильно облегачает жизнь, хотя и не могу сказать, что прямо вся-вся востребована.
Про предпоследний абзац - не соглашусь. Ресурсов было немного, временные рамки были очень жесткие. Тут скорее личная мотивация каждого и профессионализм коллег сыграли в огромный плюс.
Про P.S: сквозь размытый скриншот вижу очень похожий функционал на то приложение, которое сейчас вдвоем с лидом мы переводим на FSD. Вот уж где сложность - и без того сложное и едущее приложение рефакторить и переводить на ходу на другую архитектуру. Но опыт и интерес просто бесценный.
Как раз про флоу процесса перевода такого большого и готового проекта на FSD и будет моя следующая статья.
Глядя на скриншот, хоть и плохо вижу, сразу вижу fsd-компоненты. Естественно, можно применять FSD, можно обойтись классикой (ничего не применять). Безусловно, чтобы переводить уже готовый и работающий проект на FSD - это очень трудозатратно и требует четкого понимания зачем и почему. Для разработчиков это зачастую чувствуется и без метрик - на уровне ощущений - поддержка проекта все растет во времени, что-то новое добавляется с проблемами, растут костыли. Но бизнесу и менеджерам это скорее всего не интересно: это непонятно и "дорого".
Давайте про это подискутируем под моей следующей статьей, когда я (надеюсь) опишу не только флоу, но и успешный опыт и результаты переезда готового проекта. Я постараюсь четко расписать причины этого переезда.
А закончить хочу вот этим абзацем от Роберта Мартина, нравится:
И спасибо вам за уделенное время и подробный анализ, дискутировать с такими людьми - одно удовольствие.
Здравствуйте! Спасибо)
По вопросам:
1. На самом больше вам не потребуется больше, эта архитектура создавалась не один день, с учетом требований практически любой разработки. Будем честны - что-то совсем "эдакое" и выбивающееся из некой общей массы встречается очень редко, если мы говорим про типичный фронт.
Какой компонент бы вы не выделили - будет отнесен к одному из существующих слоев. На практике чаще возникает ситуация, что команда думает, отнести компонент, допустим, к фичам или к сущностям, но такой ситуации, чтобы мы вообще не знали куда "положить" - не было ни разу, а проект на FSD у компании уже не единственный.
Почему именно 6 - результат ресерча создателей. Добавить новый вы не сможете и, как я уже сказал, не за чем. В этом и смысл любой архитектуры (схожий принцип и у фреймворков) - накладывать определенные ограничения, следуя которым, вы добьётесь хорошей структуры и прочих бенефитов. Как по мне здесь уместна аналогия с рецептами на приготовление из реальной жизни - они накладывают ограничения, но, если вы будете его соблюдать, то получите желаемое. Иначе, по неопытности, получится каша, отдаленно напоминающая желаемое.
2. Тут два варианта. Я пришел к тому, что создал внутри сущностей и фичей дополнительные папки, группирующие сущности/фичи по отношение к бизнес-сущности. Выглядит это примерно так:
entities/
- /Order/
- /Restaurant/
- /Review/
И т.д. и т.п., внутри /Review/ в entities будут лежать например ReviewCard, ReviewPreview, ReviewFull. Внутри /Restaurant/ в features лежат CloseRestaurant, OpenRestaurant, EditRestaurant и т.д.
Второй вариант, официальный, упоминается в гайдлайнах - уход в монорепу с микрофронтами. Мы сейчас думаем, и скорее всего будем пробовать такой подход на втором проекте. Если коротко - каждая пейджа - отдельное FSD
Подробнее можете посмотреть здесь (с 32:00)
3. Нет, связность получается очень низкая. Тут важную роль играет однонаправленность зависимостей. Сущности используют шаред (это могут быть адаптеры селектов, дропдаунов, текстареа, тогглы, чекбоксы, типография, и тд и тп), но не наоборот. Фичи вообще редко используют сущности. Виджеты/страницы собирают в себе сущности и фичи, но не наоборот.
4. Вкладка issues - это страница/виджет. Сущность не может содержать в себе страницу) В вашем случае, например, сущность - это само по себе "issue". Т.е. идите от бизнес-сущностей. Вот есть понятие "проблемы" - у него могут быть свои визуальные представления - карточка проблемы, а где-то это отразится как строчка в списке, - это сущности. Удаление/создание проблемы - фичи. Окошко по работе с проблемой, где можно ее создать/удалить/отредактировать, оставить комментарий, какие-то эмодзи прожать - виджет. Страница, на которой это все собрано - пейджа.
Если хотите, можете кинуть в комменты скрин какой-то любой страницы, вместе с вами разберем по FSD.
Вам fsd дорогу чем-то перешел, что вы с пеной у рта бегаете по fsd-постам и что-то кому-то доказываете? Аж три страницы комментариев по этой тематике на аккаунте с нулем публикаций)
Ну напишите пост какой-нибудь со сравнением одинаковых проектов, написанных на "классической" и fsd-архитектуре в динамике в крупном бизнесе, под ним и поговорим. А дальше вникать в пассажи безработных ноунеймов с синдромом утенка, боящихся не дай бог что-то новое узнать/попробовать не интересно, сорян)
"Главное ничего не надо изучать" - очень хорошо сказано, и в целом ёмко характеризует ваш посыл xD
Очередная, как... что например? Как функциональные компоненты в Реакте, которые тоже всех по началу пугали? Вы в FSD разбираетесь и на FSD работали? Применяли ее на своих проектах, метрики какие-то снимали с fsd и с не-fsd? Что-то мне подсказывает, что нет.
Про ограничения - почитайте, зачем в целом архитектура нужна. Я видел судьбу проектов "без всяких ограничений", когда время на поддержку растет пропорционально времени существования проекта и объему кода. Код без ограничений неизбежно превращается в бесформенную массу, какой бы талантливой не была команда.
> fsd никак и не соотносится с реальным миром
Только в ру-сегменте десятки топовых компаний (посмотрите на HH статистику по количеству требований знания/опыта fsd, посмотрите доклады Яндекса, Самоката и т.п.) применяют эту "мертворожденную фигню", видимо, чтобы страдать побольше.
Мне есть с чем сравнивать как в рамках предыдущих, так и в рамках текущих проектов. Наш FSD-проект безоговорочно лидирует по скорости погружения, поддержки и остальным плюсам, указанным в статье.
"Традиционной" архитектурой обычно является ее отсутствие, что приводит к адской неразберихе в корневых папках компонентов/хуков и т.д.
Ограничения существуют в любых архитектурах, и работают они на благо - ценой ограничений создается порядок и легкость поддержки. Чтобы понимать ценность архитектуры как таковой, почитайте какого-нибудь Дядюшку Бо, он в каждой своей книге про это пишет практически.
Голословные утверждения про "просто для всех" конечно хорошо, но опять же, в статье приведены реальные цифры и реальные итоги, опять же, сравнение с другими не-fsd проектами перед глазами.
Спасибо за отзыв)
Про хуки - для всей команды это был первый полноценный проект на FSD, поэтому в пути набили какие-то шишки. Оглядываясь назад - действительно, логичнее было бы создавать папки model, куда можно складывать также и апи для горизонтального взаимодействия: кросс-импортов (одна из самых больных тем fsd).
На эту тему мне понравился вот этот доклад с последней HolyJS Александра Моргунова, в нем как раз описывается этот кейс (да и многие другие, с которыми мы столкнулись в итоге)
Для роутинга мы используем Трамваевский file-system routing
Общая структура получается простая и наглядная:
По поводу линтера - затащить его хотелось бы, но подружить его с Трамваем пока что скорее всего не получится.
Касательно написания - действительно, спасибо, поправлю
По порядку:
1. Сущности и есть обобщенные модели, которые предназначены для использования в разных фичах. Это ни в коем случае не "свойства фичи", а скорее компонент, репрезентирующий ту или иную бизнес сущность.
Представим такую бизнес-сущность, как "продукт". У продукта могут быть следующие сущности: "карточка маленькая", "карточка большая", "список продуктов". Так что да, в итоге визуально это будет компонентом.
2. Экран/страница в FSD - page (в нашем случае route). Рут не может "принадлежать" фичам, наоборот, разные фичи включаются в рут. Иерархия в FSD вертикальная и однонаправленная. Горизонтальные взаимоотношения тоже возможны, но про них стоит поговорить отдельно.
Захотим добавить на страницу авторизацию? Добавляем в рут/пейджу фичу авторизации.
3. Тут всегда немного путает нейминг. Мне сильно проще воспринимать и выделять фичи помог совет из одного из докладов по FSD: фича = юзер процесс.
Пример про аналитику не совсем понял. Блок аналитики в малом представлении может быть сущностью, если это полноценная страница - пейдж, либо виджет, тут уже нужно смотреть на конкретный пример. Фича для примера, упоминавшегося выше - это например "оплата", или "добавление в корзину", или "удаление из корзины". В фиче может быть работа с апи и, например, оптимистичная мутация данных на фронте.
Сорри, про SSR упоминание оставалось по ошибке)