Все мы понимаем для enterprise решений требуется тщательного анализа в плане проектирование и этому уделяется не мало времени, от структуры папок, описании регламента по стилям или коду, подключение микрофронтов и если эта не учитывать мы получаем в своем роде монолита, где все хаотично разбросано и в целом эта не плохо работает до определенного поры времени.
За основу своей чистой архитектуры я применил методологию проектирования DDD (Domain-Driver-Design). Что эта значит вкратце.
Основное понимание предметной области: DDD нацелено на то, чтобы разработчики и эксперты предметной области вместе работали над пониманием бизнес‑логики и задач, решаемых приложением. Это помогает создавать более эффективные и соответствующие предметной области решения.
Определение моделей предметной области: DDD ставит модель предметной области в центр разработки, помогая разработчикам создавать четкое представление о бизнес‑логике и правилах, определяющих вашу систему.
Язык моделирования: DDD ставит задачу разработчикам использовать язык, который понимают и разделяют и технические и предметные эксперты. Это упрощает коммуникацию и обеспечивает более четкое понимание между разработчиками и экспертами предметной области.
Разделение на слои: DDD рекомендует разделение приложения на слои, включающие слой предметной области, слой приложения и слой представления. Это упрощает сопровождение и масштабирование приложений.
Для примера был кейс получить данные о задачах из https://jsonplaceholder.typicode.com/ и отобразить их. Начал с того что настроил пустой React Vite проект без лишних надстроек, далее занялся со структурой папок, в принципе здесь ничего нового, как сказано выше основной концепцией DDD эта четкое представление о бизнес‑логике и правилах, определяющих вашу систему.
Внутри папки features/todos, можно будет увидеть следующее: папка с получением данных то бишь наши репозитории и модели, папка непосредственно с domain сущностью максимально абстрактная логика и папка presentation отвечающий за представление нашей логики.
Начнем с domain папки где описаны наши сущности.
Создаю интерфейс TodoEntity и описываю поля которые ожидаю получить.
Описываю интерфейс репозитория, ожидаю получить getTodos
Создаю usecase который ожидает получить ответ из getTodos
Над реализацией займусь в слой data где будут обращение апи, реализация класса Todo.repository и Todo.entity.
Реализация класса TodoRepository, как вы могли заметить в конструктор попадает todoApiService, аналогично для usecase'ов тоже, их я буду получать через DI.
Модель TodoModel реализует TodoEntity, сериализацию полей и всякого рода валидации
Работа с апи я унаследовал пакет ts-retrofit аналогично пакету retrofit, которая используется под андроид. Ее плюсами я посчитал быстро описывать интерфейсы к апи обращений через декораторы.
Связь между ними будет закладываться через конструкторы с помощью Dependency Injection, для этого я взял за основу очень удобный и подходящий пакет awilix
Ее настройка довольна проста и в использовании тоже, преимущественно эта - управление циклами жизни экземплярами класса.
Переходим к слою features/presentation
Во вьюхе будут 2 папки, эта компоненты и наш store, за основу store'а я решил использовать MobX, почему не Redux вы скажите... эта в избыточности большого шаблонного кода, и одна из плюсов mobx эта - мультисторы, ее подключение с awilix будет выигрышным вариантом чем redux, так как стор будет описываться классом, а не так как мы привыкли видеть в redux.
Ее мы также подключаем к нашей DI, чтобы получить наши usecase'ы. И остается за малым эта наша вьюха.
В заключении я бы хотел сказать, что данная архитектура возможно не самая лучшая, но ее идея в плане чистой архитектуры остается. В процессе ее можно будет расширить я думаю доп. слоями до подключение микрофронтов.
