Игорь Чесноков

Компонент API. (Application Interface)

Реализует компонент связывающий приложение и CRM стандартом REST.
Реализовать асинхронно, с помощью фреймворка FastAPI.

Приложение (NotificationHandler)

Выполняет необходимые задачи, принимаемые из очереди или запускаемые по графику Celery.
Приложение синхронное, в случае увеличения нагрузки будут подниматься автоскейлом инстансы, консюмящие очередь.
Компонент репозитория инкапсулирует детали доступа к данным, будь они за API, компонентом парсинга, в базе или где-либо еще. За референсом обращаться к комментариям Мартина Фаулера PofEAA.

Mapping.

За референсом обращаться к паттерну IdentityMapper. Слой максимально привязанный к инфраструктуре, использование ОРМ(sqlalchemy) по желанию.

Externals.

Компонент, включающий варианты доступа к внешним данным. Одна из частей компонента – резолвер капчи, подключаемый в случае необходимости использовать стратегию парсинга, как, например, в случае autoins.

Очередь.
Нужно сделать как минимум две очереди – задачи, падающие с ЦРМ, имеют максимальный приоритет, и должны, по возможности, быть обработаны приложением как можно быстрее.

---

Детали:

Зависимости прокидывать через DI, с использованием DI контейнера, лично я предпочитаю punk из за простоты, но допустимы dishka и т.п.

Обязательно покрытие тестами слои, между слоями ходят исключительно примитивы, или DTO.
Код будет распологаться в репозитории GitLab с настроенным CI пайплайном (black, isort, ruff).
Сущности “доменного” слоя реализовать с использованием Dataclasses.

Компоненты, обозначенные в схеме flow приложения как Celery, а так же детали функционирования репозиторного слоя приложения (*check if exists) касательно кеша в redis, разрабатывать не нужно.

Готовое решение поставить с использованием docker-compose.

Flow приложения, а так же компонентную схему можно посмотреть в приложении.