API против событий в DDD в ограниченном контексте

Question

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

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

или

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

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

Answer 1

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

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

Answer 2

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

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

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

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