- Models - проект с Dto.
- Клиент - C#-клиент к сервису. Удобно использовать если остальной стек на C#. Подтянул "Microsoft.AspNetCore.App" чтобы не писать новую модель ошибок руками (по-хорошему лучше свой формат ошибки описать).
- Api - API со "слоями" представления, приложения, слоем доступа к данным и инфраструктурой.
- Runner - точка входа.
- LocalTests - тесты, которым для работы нужны только сборки (Assembly) приложения (unit, интеграционные, против API локального-поднятого сервиса)
- RemoteTests - тесты для работы которых необходим где-то поднятный сервис (например, на тестовой площадке или локально-запущенного у разработчика в дебаге). Позволяют найти больше багов.
- CommonTests - тесты, которые могут работать и с API локального-поднятого сервиса и с API на тестовой площадке.
Для запуска нужно использовать EntryPoint в проекте Runner. Swagger доступен по ссылке: http://localhost:43920/swagger/index.html SwaggerUi discriminator не поддерживает, но в самой json-схеме он описан верно.
LocalTests можно запускать без предварительной подготовки. Для запуска RemoteTests нужно поднять API с помощью EntryPoint в проекте Runner. В тестах захардкожен захадкоженный Url сервиса. По-хорошему он должен быть в конфиге зависящем от CI, но для задания и так сойдет.
Мне показалось что вы ожидаете, что разные типы уведомлений будут обрататываться одним обработчиком (или контроллером). Я сделал так, но редко считаю использование полиморфизма в Dto хорошим. Есть и лучше варианты.
Docker и Postgres не реализовывал, так как не практиковал раньше. А чтобы технологии использовать качественно, необходимо потратить на изучение больше времени, чем я сейчас готов.
EF не использовал, так как
- мало его знаю;
- NoSQL-базы подходят для текущей схемы данных и хорошо масштабируются для текущей задачи, но популярные из них в EF не поддерживаются.