Какие архитектурные стили существуют кроме микросервисов и саги

Что проверяют

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

Как отвечать

Коротко поправьте формулировку: сага решает задачу транзакции через несколько сервисов (оркестрация или хореография с компенсирующими действиями) и живёт внутри микросервисной или событийной архитектуры. Дальше стили с примерами из .NET:

• слоистый монолит (n-tier): презентация, бизнес-логика, доступ к данным. Прост на старте, но слои со временем срастаются;
• модульный монолит: один процесс и один деплой, но модули с жёсткими границами, своими схемами в базе и общением через контракты. Разумная точка старта, из которой потом выделяют сервисы;
• гексагональная, Onion, Clean Architecture: домен в центре, инфраструктура подключается через интерфейсы (порты и адаптеры);
• событийно-ориентированная (EDA): обмен событиями через RabbitMQ, Kafka или Azure Service Bus, в .NET обычно через MassTransit или NServiceBus. Слабая связность ценой eventual consistency и сложной отладки;
• CQRS и Event Sourcing: раздельные модели записи и чтения, состояние как журнал событий. CQRS без Event Sourcing тоже нормальный вариант;
• SOA: крупные сервисы и общая шина (ESB), предшественник микросервисов в корпоративных системах;
• микроядро (плагины): ядро плюс расширения, в .NET через загрузку сборок в AssemblyLoadContext;
• pipes and filters: цепочка обработчиков, как конвейер middleware в ASP.NET Core;
• serverless: Azure Functions или AWS Lambda под событийную и неравномерную нагрузку.

Где спотыкаются

Ставят REST и «API-ориентированную архитектуру» в один ряд с монолитом. REST действительно архитектурный стиль, но он про взаимодействие по сети и ничего не говорит о том, как разбита сама система.

Не могут объяснить, чем модульный монолит лучше обычного и почему с него часто начинают вместо микросервисов.

Сводят Clean Architecture к проектам Domain, Application, Infrastructure. Суть в направлении зависимостей к домену, а не в названиях папок.