В книге сказано (в предыдущем абзаце), что я могу использовать «Временную развязку», используя таймеры или обмен сообщениями.Так что для меня означает, что C больше не должен блокировать и ждать немедленного ответа от S?это правильно?
Да, это для реализации асинхронной интеграции между двумя ограниченными контекстами (BC), когда BC в восходящем направлении (сервер "S") предлагает REST API вместо публикации сообщений в промежуточном ПОочередь.
Временная развязка с использованием таймеров: C выполняет вызов на S только тогда, когда истекает таймер и если удаленная система (S) недоступна, пороговое значение таймера сбрасывается.Что это значит?Вы можете уточнить это?Я понимаю, что C делает вызов только тогда, когда таймер больше 10 секунд, например?это верно?Не ясно, как «порог таймера сбрасывается» может помочь в этом?
Итак, нисходящий BC (C) интегрируется с восходящим BC (S), опрашивая REST API S каждый раз, когда таймерпроходит (скажем, каждые 10 секунд, как вы сказали, например).Отключение порога таймера, когда API недоступен, означает, что клиент будет повторять опрос через обычные интервалы, таймер не имеет значения.
Пример:
C --POLL--> S @ 00:00
C --POLL--> S @ 00:10
C --POLL--> S @ 00:20
C --POLL--> S @ "every 10 sec"
S is-down
C --POLL--> S @ 00:00 (timer is backed-off)
S is-down
C --POLL--> S @ 00:00 (timer is backed-off)
S is-up
C --POLL--> S @ 00:10
C --POLL--> S @ 00:20
C --POLL--> S @ "every 10 sec"
Временная развязка с использованием обмена сообщениями: C выполняет вызов на S только тогда, когда сообщение получено, а если удаленная система (S) недоступна, сообщение отрицательно подтверждается.Что это значит?можешь уточнить?C вызывает S только когда "сообщение получено" получено откуда?и если сообщение не получено, то «... сообщение может быть отрицательно подтверждено посреднику и доставлено», не ясно, какая здесь последовательность событий?
Вместо использования таймера, опрос выполняетсявыполняется каждый раз, когда C получает сообщение, опубликованное внутренним посредником в клиентском BC (не очередь сообщений между C и S).Чтобы вернуть отрицательное подтверждение брокеру, нужно сказать брокеру, что он должен повторно доставить сообщение (поскольку вызов S не может быть выполнен).Таким образом, брокер снова отправит то же сообщение C, а C повторит вызов S. S. 1021 *
ОБНОВЛЕНИЕ:
Вот что говорит Вон Вернон в своемдругая книга «Разбирается DDD» на эту тему:
«Переход в асинхронный режим с REST
Можно выполнить асинхронный обмен сообщениями с помощью опроса на основе REST последовательно растущего набораИспользуя фоновую обработку, клиент будет постоянно запрашивать ресурс канала Atom службы, который предоставляет постоянно растущий набор событий домена. Это безопасный подход к поддержанию асинхронных операций между службой и клиентами при одновременном предоставлении обновленной информации.события, которые продолжают происходить в службе. Если служба по какой-либо причине становится недоступной, клиенты будут просто повторять попытки через обычные промежутки времени или возвращаться с повторной попыткой, пока ресурс канала снова не станет доступным.
Этот подход обсуждаетсяподробно в разделе Реализация доменного дизайна. "