documentation MOTIVATION: Добавить больше сравнений с Clean Achitecture

https://www.youtube.com/watch?v=qP9biDbPJ0I

Jul 26 '21 18:07 azinit

https://habr.com/ru/post/499078/

Jul 26 '21 21:07 azinit

https://habr.com/ru/company/mobileup/blog/335382/

Jul 26 '21 21:07 azinit

Сделать вместе с тикетом:

https://github.com/feature-sliced/documentation/issues/155

Aug 31 '21 21:08 azinit

Clean Architecture Feature Sliced

📅 Дата создания ~ 2012, проверенная временем 2018, адаптированная под современные реалии

🛠 Применимость Достаточно абстрактен, имеет много трактовок и имплементаций
(что может затруднить онбординг) Имеет строгий и одновременно гибкий свод правил, для применения на практике;
Представляет собой договоренность среди фронтенд-сообщества

🚀 Экосистема Из-за разночтений, экосистема богата разнородным инструментарием, но который не факт что подойдет для вашего случая

В комьюнити сложно договорится "об одном истинном варианте", что затруднит вкатывание новых разработчиков Поддерживаемая и консистентная документация (tutorials, guides, concepts)
Развиваемый тулкит для разного рода проектов
Помощь от комьюнити с разным стеком на проектах

▶️ UI Внешняя зависимость, с малым влиянием на приложение

"Работайте с этим и выстраивайте связи как хотите сами" В первую очередь UI-oriented, т.к. FS считает UI полноценной частью любого современного фронтенд-приложения

UI становится полноценной "осью" как и Model, Lib, Api (SliceBased)

⚡️ Адаптация к изменениям Позиция "Все может поменяться: и фреймворк, и реализация, и бизнес-требования".
UI становится "часто меняющимся аспектом", хоть там и может храниться базовый UIKit приложения, который очевидно будет меняться редко (Button/Tabs/Input/...)
И находится такие компоненты на одном уровне с другими, наиболее часто меняющимися (LessonCard, CommentForm, LessonsListPage, ...)

domains < application ?? ports, adapters Архитектура адаптируема к изменениям бизнеса (на этом есть акцент). Меняя же библиотеку, очевидно, придется затронуть соответствующий сегмент реализации: ui/model/api
При этом на уровне слоев можно сразу отследить степень изменчивости:
shared < entities < features < (widgets) < pages < app

И по этой же градации можно отследить опасность и влияние изменений:
- shared: менять опасно, но импакт максимальный (освежить дизайн-систему)
- entities: менять менее опасно, но все равно рискованно (вся доменная логика)
- features: конкретные юзкейсы, меняются часто
- pages: конкретные страницы, меняются постоянно, с наименьшим риском

🍰 Слои и скоупы ответственности domains - Доменная логика
application - Конкретные юзкейсы
ports/adapters - Конкретные реализации и аспекты для адаптации к внешнему миру (UI, localStorage, API)

Все остальное - на усмотрение архитектора/лида проекта shared - Общеиспользуемая nonproject-specific логика (UIKit, API, LocalStorage, ...)
entities - Доменная логика
features - Конкретные юзкейсы
pages - Конкретные страницы/экраны приложения
app - Логика инициализации приложения

🔳 Доменная область Распространяется "вчистую" в domains, application. Все остальное - часто меняющиеся "внешние" зависимости, даже UI Везде: entities, features, pages - включая UI, как часть предметной области

⛓ Унификация Из-за "изменчивости UI", строго разделяем UI и чистое описание модели данных.Из-за чего ось изменений размазывается по проекту (ui/OrderForm ~ application/CreateOrder)

Это влияет по итогу на то, что при таком сомнительном преимуществе, мы получаем проблему, что у нас изначально кодобаза рискует стать деунифицированной, ибо "ВСЕ МОЖЕТ ПОМЕНЯТЬСЯ"
(3 реализации адаптера для одного порта, тож самое с компонентами) FS предполагает, что все хранится локализованно и рядом. Т.е. риски деунификации падают - разные реализации сущности/фичи будут все равно лежать рядом

UI модуля и его модель данных - лежат рядом (Low Coupling & High Cohesion)

🀄️ Tech-specific (old-school) В Клине до определенного слоя можно писать без привязки к технологии, что может показаться преимуществом.
Но это означает, что всю ключевую логику мы написали без каких либо реактивных примитивов, без чего сложно представить современный фронтенд.
И это ведет ни к чему иному как к "костыляем свои велосипеды сами, зато родные и стабильные".

Стоит ли оно такого? (new-school) FS предполагает что мы можем использовать любые технологии, в том числе примитивы для работы с дата-флоу, дата-фетчингом и отображением.
Такое более разрозненно для всего фронта, но позволяет заюзать все преимущество современной экосистемы
(например реактивные примитивы для описания бизнес-логики и дата-флоу)

🔩 Explicit Sharing Непонятно куда класть библиотечный код, компоненты разной ответственности и запросы
(они почему то хранятся на самом верху, хотя меняются реже всего обычно)

Непонятно как шарить код между проектами (UIKit, Libs, ...) - все делегируется разработчикам В FS порядок слоев обсулавливает и правила переиспользования

Критерии слоев и сама слоисто-слайсовость подразумевает, что наше приложение композируется из более атомарных элементов-модулей
Благодаря этому удается выстраивать гибкую архитектуру, элементы которой можно предсказуемо и контролируемо переиспользовать для всяких нужд

	Clean Architecture	Feature Sliced
📅 Дата создания	~ 2012, проверенная временем	2018, адаптированная под современные реалии
🛠 Применимость	Достаточно абстрактен, имеет много трактовок и имплементаций (что может затруднить онбординг)	Имеет строгий и одновременно гибкий свод правил, для применения на практике; Представляет собой договоренность среди фронтенд-сообщества
🚀 Экосистема	Из-за разночтений, экосистема богата разнородным инструментарием, но который не факт что подойдет для вашего случая В комьюнити сложно договорится "об одном истинном варианте", что затруднит вкатывание новых разработчиков	Поддерживаемая и консистентная документация (tutorials, guides, concepts) Развиваемый тулкит для разного рода проектов Помощь от комьюнити с разным стеком на проектах
▶️ UI	Внешняя зависимость, с малым влиянием на приложение "Работайте с этим и выстраивайте связи как хотите сами"	В первую очередь UI-oriented, т.к. FS считает UI полноценной частью любого современного фронтенд-приложения UI становится полноценной "осью" как и Model, Lib, Api (SliceBased)
⚡️ Адаптация к изменениям	Позиция "Все может поменяться: и фреймворк, и реализация, и бизнес-требования". UI становится "часто меняющимся аспектом", хоть там и может храниться базовый UIKit приложения, который очевидно будет меняться редко (Button/Tabs/Input/...) И находится такие компоненты на одном уровне с другими, наиболее часто меняющимися (LessonCard, CommentForm, LessonsListPage, ...) `domains < application ?? ports, adapters`	Архитектура адаптируема к изменениям бизнеса (на этом есть акцент). Меняя же библиотеку, очевидно, придется затронуть соответствующий сегмент реализации: ui/model/api При этом на уровне слоев можно сразу отследить степень изменчивости: `shared < entities < features < (widgets) < pages < app` И по этой же градации можно отследить опасность и влияние изменений: - `shared`: менять опасно, но импакт максимальный (освежить дизайн-систему) - `entities`: менять менее опасно, но все равно рискованно (вся доменная логика) - `features`: конкретные юзкейсы, меняются часто - `pages`: конкретные страницы, меняются постоянно, с наименьшим риском
🍰 Слои и скоупы ответственности	`domains` - Доменная логика `application` - Конкретные юзкейсы `ports`/`adapters` - Конкретные реализации и аспекты для адаптации к внешнему миру (UI, localStorage, API) Все остальное - на усмотрение архитектора/лида проекта	`shared` - Общеиспользуемая nonproject-specific логика (UIKit, API, LocalStorage, ...) `entities` - Доменная логика `features` - Конкретные юзкейсы `pages` - Конкретные страницы/экраны приложения `app` - Логика инициализации приложения
🔳 Доменная область	Распространяется "вчистую" в `domains`, `application`. Все остальное - часто меняющиеся "внешние" зависимости, даже UI	Везде: `entities`, `features`, `pages` - включая UI, как часть предметной области
⛓ Унификация	Из-за "изменчивости UI", строго разделяем UI и чистое описание модели данных.Из-за чего ось изменений размазывается по проекту (ui/OrderForm ~ application/CreateOrder) Это влияет по итогу на то, что при таком сомнительном преимуществе, мы получаем проблему, что у нас изначально кодобаза рискует стать деунифицированной, ибо "ВСЕ МОЖЕТ ПОМЕНЯТЬСЯ" (3 реализации адаптера для одного порта, тож самое с компонентами)	FS предполагает, что все хранится локализованно и рядом. Т.е. риски деунификации падают - разные реализации сущности/фичи будут все равно лежать рядом UI модуля и его модель данных - лежат рядом (Low Coupling & High Cohesion)
🀄️ Tech-specific	(old-school) В Клине до определенного слоя можно писать без привязки к технологии, что может показаться преимуществом. Но это означает, что всю ключевую логику мы написали без каких либо реактивных примитивов, без чего сложно представить современный фронтенд. И это ведет ни к чему иному как к "костыляем свои велосипеды сами, зато родные и стабильные". Стоит ли оно такого?	(new-school) FS предполагает что мы можем использовать любые технологии, в том числе примитивы для работы с дата-флоу, дата-фетчингом и отображением. Такое более разрозненно для всего фронта, но позволяет заюзать все преимущество современной экосистемы (например реактивные примитивы для описания бизнес-логики и дата-флоу)
🔩 Explicit Sharing	Непонятно куда класть библиотечный код, компоненты разной ответственности и запросы (они почему то хранятся на самом верху, хотя меняются реже всего обычно) Непонятно как шарить код между проектами (UIKit, Libs, ...) - все делегируется разработчикам	В FS порядок слоев обсулавливает и правила переиспользования Критерии слоев и сама слоисто-слайсовость подразумевает, что наше приложение композируется из более атомарных элементов-модулей Благодаря этому удается выстраивать гибкую архитектуру, элементы которой можно предсказуемо и контролируемо переиспользовать для всяких нужд

Nov 13 '21 08:11 azinit

documentation documentation copied to clipboard

MOTIVATION: Добавить больше сравнений с Clean Achitecture

documentation
documentation copied to clipboard