Что из следующего считается лучшей практикой при интеграции через ограниченные контексты в DDD?

1) Публикация событий, когда объект изменяется в исходном BC, прослушивание этих событий в потребляющем BC, преобразование этих данных в требуемый объект и сохранение их в потребляющем BC.

Или

2) Выполните вызов API синхронно с BC, который владеет объектом, когда эта информация требуется другому BC.

Или есть другой вариант, который считается лучшей практикой, чем приведенный выше?

0
eddiec 20 Дек 2018 в 15:27

2 ответа

Лучший ответ

Если вы заинтересованы в автономии, вы не хотите иметь службы, для которых требуются другие службы.

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

Обычно это означает, что каждая служба кэширует копию необходимых данных.

Заставить потребителей получать данные, которые им нужны, обычно проще, чем пытаться передать их им - см. Доклад Грега Янга на Данные Polyglot.

1
VoiceOfUnreason 20 Дек 2018 в 14:23

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

Вы можете реализовать асинхронную интеграцию с API вместо событий, выполняя вызовы удаленного API каждый определенный период, опрашивая запросы.

0
choquero70 21 Дек 2018 в 08:15