Boilerplate для csr react + ts + webpack + cypress

Примечание перед сипользованием:

• После клонирования необходимо обновить все основные пакеты до последней версии
• Husky обновлять не нужно. Используется версия 4 для работы с конфигурацией через json

Архитектура

Схема архитектуры

Описание слоев

application

Слой приложения. Данный слой является самым "грязным", зависит от остальных слоев и содержит в себе инициализацию других слоев.

shared

Инфраструктурный слой. В данном слое находятся программные компоненты не имеющие прямой связи с данным приложением (не относятся к предметной области). Программные компоненты в этом слое можно рассматривать как компоненты, которые можно использовать в других приложениях. Все внешние заивисмости должны проходить через shared слой. Другие слои не должны иметь прямую зависимость от библиотек.

screens

Экраны приложения. Объединяет на одном экране несколько features. Также может использовать слои: data, features, domain, shared.

!!! Слой не должен напрямую использовать routing. С роутингом взаимодействует application.

modules

Слой изолированных модулей. Каждый модуль можно рассматривать как подобие ограниченного контекста из DDD. Модуль является предметной или служебной подобластью, именно по такому принципу происходит разделение. Потенциально, каждый модуль можно отдать отдельной команде для разработки. Внутренности модули закрыты из вне, взаимодействовать с модулем можно только через публичные сущности, экспортируемые из модуля.

Каждый модуль состоит из подслоев:

• domain
• data
• features

data

Слой работы с данными.

Слой разделен на два сегмента:

• repositories
• dataSources

dataSources

Сегмент позволяющий получать данные из источника (api, localStorage...). Данный сегмент может является кодогенерацией openapi.

!!! dataSources - приватный сегмент data слоя, он недоступен для других слоев.

Правила именования dataSources: НАЗВАНИЕ_ПОЛУЧАЕМОЙ_СУЩНОСТИ + НАЗВАНИЕ_ИСТОЧНИКА_ДАННЫХ + Sources. Примеры: userNetworkSources, requestNetworkSources, userLocalStorageSources

repositories

Сегмент-фасад для работы с данными. Именно repositories доступны для использования в других слоях. Repository зависит от dataSources и может использовать несколько dataSources.

Данный слой отвечает за:

• Предоставление данных другим слоям без раскрытия источника. Использует для получения
• Форматирование данных

Правила именования repositories: НАЗВАНИЕ_ПОЛУЧАЕМОЙ_СУЩНОСТИ + Repository. Примеры: UserRepository, TariffRepository

domain

Слой бизнес-логики. Данный слой содержит только переиспользуемую бизнес-логику. Код данного слоя должен быть полностью покрыт тестами. Слой не имеет зависимостей от view (React).

Примеры бизнес-логики: formatPriceToView, getUserFullName, UserStore.

features

Переиспользуемые React компоненты, имеющие непосредственную связь с предметной областью или приложением.

Примеры features: TariffAutocomplete, MainLayout, RequestForm. Компоненты в features можно группировать произвольным образом (по доменной сущности, по поведению и т.п.), но на начальных этапах развития не рекомендуется этого делать.

Features зависит от: data, domain, shared.

React компоненты в features разделяются на два внутренних сегмента.

Сегментация react компонентов

Выделяется два сегмента:

• store | logic
• view

Зависимости сегментов направлены в одну сторону view -> store(view зависит от store.).

В store | logic сегменте находится вся логика компонента. К логике относится все, что напрямую не связано с react (useRef, useEffect...).

View слой - это react компонент. View заивисит от store и использует предоставляемую им логику.