Все мы понимаем для 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'ы. И остается за малым эта наша вьюха. В заключении я бы хотел сказать, что данная архитектура возможно не самая лучшая, но ее идея в плане чистой архитектуры остается. В процессе ее можно будет расширить я думаю доп. слоями до подключение микрофронтов. Ссылка на код Разработчик клиент-интерфейсов