Вот все вокруг говорят - DDD, ограниченные контексты... распиливают монолиты на микросервисы, изолируют и разделяют код по микросервисам...
А я вот все думаю: а к чему, к какому контексту (= сервису) относятся контракты по взаимодействию между сервисами? Кто "владелец" API, модели событий или graphQL схемы при взаимодействии сервисов между собой?
Вот, к примеру, есть два сервиса, один вызывает другой по ресту. И вроде бы отсюда следует, что тот, кто предоставляет API, является владельцем, поставщиком контракта, а вызывающая сторона - это клиент, он подстраивается под API. Но вдруг оказывается, что клиент - это большая система, к которой можно подключать плагины/расширители поведения и для этого они должны реализовывать определенный интерфейс. И сразу оказывается, что владельцем контракта является вызывающая сторона, именно она определяет "правила игры", а на реализующий сервер накладываются обязательства следовать контракту...
Такая же история может возникать и с событиями. Кто, какой сервис владелец схемы события - отправитель или получатель? Неправильный вопрос. Владелец схемы - это тот сервис, который определяет логику, смысл, содержание события. Когда-то это может быть сервис-источник события, который генерирует события и ему все равно кто их обработает, потребители подстраиваются под контракт. А может быть наоборот, источник события заинтересован, чтобы его события были обработаны конкретным получателем, и он "подстраивается" под возможности/контракты получателя, посылает события в определенном получателем формате, т.е. владельцем контракта становится получатель, обработчик события.

Видится, что владельцем контракта должен быть тот сервис (и, как следствие - домен), который является источником его потенциальных изменений. Т.е. владельца контракта нельзя определить глядя на архитектуру системы и отношения между её компонентами в моменте, а только лишь изучая и моделируя динамику её развития.