Основывался на статью 12 факторов https://12factor.net/

Clean Architecture

Simple Clean architecture

Bounded Context Микросервис должен соответствовать ограниченному контексту.

Ограниченный контекст это понятие явных границ вокруг какого-то бизнес-контекста. Например, в рамках электронной коммерции мы оперируем понятиями «темы» (themes), «поставщики платёжных услуг» (payment providers), «заказы», «отгрузка», «магазин приложений». Всё это ограниченные контексты, а значит — кандидаты в микросервисы.

https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/common-web-application-architectures

Disposability (Одноразовость)

**Процессы приложения являются одноразовыми , то есть их можно запустить или остановить в любой момент.** Это способствует быстрому эластичному масштабированию, быстрому развертыванию изменений кода или конфигурации , а также надежности производственного развертывания.

Каждая различная сторонняя служба является ресурсом. Ресурсы можно по необходимости подключать к развёртыванию и отключать от развёртывания. Например, база данных MySQL является ресурсом и должна иметь свое состояние. Приложение считает эти базы данных подключёнными ресурсами, что указывает на их слабое связывание с развёртыванием, в котором они подключены.

cancelation token https://andrewlock.net/using-cancellationtokens-in-asp-net-core-mvc-controllers/

Reliability (Надежность)

Надежность в простоте. Нет необходимости писать сложный код и сложную логику,- разбей на кусочки и собери конструктор. Применяй принцип YAGNI, KISS и DRY.

Обязательное документирование кода. Каждый класс, перечисление или параметр метода должен быть описан и иметь достаточно подробное описание.

Соблюдай Code standart

Покрытие тестами, используй TDD

(λ) Функционально Ориентированное Программирование (ФОП)

Observability (наблюдаемость)

Сервис должен уметь заявить о себе

Port binding Микросервис должен быть самостоятельным и прослушивать запросы проходящие через порт. Которые можно поставить на мониторинг