Как SOLID помогает в проектировании контрактов между микросервисами

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

Умеете ли вы переносить принципы с уровня классов на уровень сервисов, не повторяя определения из учебника. Интервьюеру важно услышать, как вы меняете контракт, не ломая потребителей. Следом обычно спрашивают, как вы ловите ломающее изменение до релиза.

Как отвечать

SOLID здесь работает как аналогия, и лучше сразу привязать каждый принцип к практике в .NET:

• SRP: контракт сервиса описывает один ограниченный контекст. Эндпоинт заказов не возвращает заодно профиль пользователя, событие OrderPaid описывает один факт;
• OCP: контракт расширяется, но не переписывается. Новые поля добавляются необязательными, старые не удаляются и не переименовываются, в protobuf номера удалённых полей помечаются reserved и больше не используются;
• LSP: новая версия сервиса должна подменять старую для любого клиента: те же коды ответов, та же семантика, валидация не строже прежней, ответ не беднее;
• ISP: разные потребители получают узкие контракты под себя, а не один «божественный» DTO на сорок полей. Отсюда паттерн BFF и отдельные сообщения вместо универсального;
• DIP: потребитель зависит от контракта (OpenAPI, .proto, пакет с одними DTO), а не от реализации. Клиент генерируется через NSwag или Kiota, либо описывается интерфейсом Refit.

Про инструменты: ASP.NET Core в свежих версиях генерирует OpenAPI сам (AddOpenApi), для gRPC контрактом служит .proto. Совместимость проверяют сравнением спецификаций в CI и контрактными тестами на Pact (PactNet), где потребитель фиксирует ожидания, а поставщик их прогоняет.

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

Переносят принципы буквально: «OCP значит на каждый новый способ оплаты новый микросервис». Это про дробление, а не про расширяемость контракта.

Выносят доменные сущности в общий NuGet-пакет. Сервисы начинают релизиться синхронно, и это уже распределённый монолит.

Считают безопасным добавление значения в enum. Клиент с JsonStringEnumConverter падает на незнакомом значении при десериализации, поэтому запасное значение и терпимость к новым вариантам нужно закладывать заранее.