IDDD 红皮书：第 13 章集成限界上下文，RESTful 时间解耦
IDDD Red Book: Chapter 13 Integrating Bounded Context, RESTful Temporal Decoupling
本书第 458 页。
“不过，我们可以通过依赖来在一定程度上克服这个问题
在 RESTful 资源上，消费者自主权的障碍较小。
即使 RESTful（或 RPC 就此而言）是您唯一的手段
整合，你可以创造时间解耦的错觉
通过在您自己的系统中使用计时器或消息传递。那
只有当一个
定时器超时或收到消息时。如果远程
系统不可用，定时器阈值可以回退，或者
如果使用消息传递，消息可以被否定地确认
经纪人并重新交付
上下文：
我有一个客服C
我有一个服务器服务S
C --calls--> S
我想增加C的自主性，减少对S的依赖
问题：
书上说（在上面的段落中）我可以使用 "Temporal Decoupling" 使用计时器或消息传递。所以对我来说意味着 C 不再需要阻塞并等待 S 的立即响应？对吗？
使用定时器的时间解耦：C 仅在定时器超时时调用 S，并且如果远程系统 (S) 不可用，则定时器阈值将回退。那是什么意思？你能澄清一下吗？
例如，我知道 C 仅在计时器超过 10 秒时才进行调用？对吗？
不清楚 "timer threshold is backed off" 对此有何帮助？
使用消息传递的时间解耦：C 仅在收到消息时调用 S，如果远程系统 (S) 不可用，则消息被否定确认。那是什么意思？你能澄清一下吗？
C 仅在 "a message is received" 从 where?
收到消息时才调用 S，如果没有收到消息，则“...消息可以被代理人否定确认并重新传送”，这里的事件顺序不明确?
如果可以，请举例说明。谢谢。
The book says (in the above paragraph ) I can use "Temporal
Decoupling" using timers or messaging. So that to me means that C no
longer has to block and wait for an immediate response from S? is that
correct?
是的，当上游 BC（服务器 "S"）提供 REST API 而不是将消息发布到中间件队列时，它用于在两个限界上下文 (BC) 之间实现异步集成。
Temporal Decoupling using Timers: C only makes a call on S when timer
elapses and if the remote system (S) isn't available the timer
threshold is backed off. What does that mean? can you clarify this? I
understand that C makes call only when timer is more than 10 sec for
example? is that correct? Not clear how "timer threshold is backed
off" can help in this?
因此，下游 BC (C) 通过轮询 S 的 REST API 与上游 BC (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"
Temporal Decoupling using Messaging: C only makes a call on S when a
message is received and if the remote system (S) isn't available the
message is negatively acknowledged. What does that mean? can you
clarify? C only calls S when "a message is received" received from
where? and if no message is received then "... the message can be
negatively acknowledged to the broker and redelivered", not clear of
sequence of events here?
不是使用计时器，而是在每次 C 收到一条消息时进行轮询，该消息由客户端 BC 内的内部代理发布（不是 C 和 S 之间的消息队列）。 return 对代理的否定确认是对代理说它必须重新传递消息（因为无法执行对 S 的调用）。因此代理将再次向 C 发送相同的消息，C 将重试对 S 的调用。
更新：
以下是 Vaughn Vernon 在他的另一本书 "DDD distilled" 中关于此主题的说法：
"与 REST 实现异步
可以使用基于 REST 的轮询顺序增长的资源集来完成异步消息传递。使用后台处理，客户端将持续轮询服务 Atom 提要资源，该资源提供不断增加的领域事件集。这是维护服务和客户端之间异步操作的安全方法，同时提供服务中持续发生的最新事件。如果服务由于某种原因变得不可用，客户端将简单地按正常时间间隔重试，或通过重试退出，直到提要资源再次可用。
这种方法在实现领域驱动设计中有详细讨论。"
本书第 458 页。
“不过，我们可以通过依赖来在一定程度上克服这个问题 在 RESTful 资源上，消费者自主权的障碍较小。 即使 RESTful（或 RPC 就此而言）是您唯一的手段 整合，你可以创造时间解耦的错觉 通过在您自己的系统中使用计时器或消息传递。那 只有当一个 定时器超时或收到消息时。如果远程 系统不可用，定时器阈值可以回退，或者 如果使用消息传递，消息可以被否定地确认 经纪人并重新交付
上下文：
我有一个客服C
我有一个服务器服务S
C --calls--> S
我想增加C的自主性，减少对S的依赖
问题：
书上说（在上面的段落中）我可以使用 "Temporal Decoupling" 使用计时器或消息传递。所以对我来说意味着 C 不再需要阻塞并等待 S 的立即响应？对吗？
使用定时器的时间解耦：C 仅在定时器超时时调用 S，并且如果远程系统 (S) 不可用，则定时器阈值将回退。那是什么意思？你能澄清一下吗？
例如，我知道 C 仅在计时器超过 10 秒时才进行调用？对吗？
不清楚 "timer threshold is backed off" 对此有何帮助？使用消息传递的时间解耦：C 仅在收到消息时调用 S，如果远程系统 (S) 不可用，则消息被否定确认。那是什么意思？你能澄清一下吗？
C 仅在 "a message is received" 从 where?
收到消息时才调用 S，如果没有收到消息，则“...消息可以被代理人否定确认并重新传送”，这里的事件顺序不明确?
如果可以，请举例说明。谢谢。
The book says (in the above paragraph ) I can use "Temporal Decoupling" using timers or messaging. So that to me means that C no longer has to block and wait for an immediate response from S? is that correct?
是的，当上游 BC（服务器 "S"）提供 REST API 而不是将消息发布到中间件队列时，它用于在两个限界上下文 (BC) 之间实现异步集成。
Temporal Decoupling using Timers: C only makes a call on S when timer elapses and if the remote system (S) isn't available the timer threshold is backed off. What does that mean? can you clarify this? I understand that C makes call only when timer is more than 10 sec for example? is that correct? Not clear how "timer threshold is backed off" can help in this?
因此，下游 BC (C) 通过轮询 S 的 REST API 与上游 BC (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"
Temporal Decoupling using Messaging: C only makes a call on S when a message is received and if the remote system (S) isn't available the message is negatively acknowledged. What does that mean? can you clarify? C only calls S when "a message is received" received from where? and if no message is received then "... the message can be negatively acknowledged to the broker and redelivered", not clear of sequence of events here?
不是使用计时器，而是在每次 C 收到一条消息时进行轮询，该消息由客户端 BC 内的内部代理发布（不是 C 和 S 之间的消息队列）。 return 对代理的否定确认是对代理说它必须重新传递消息（因为无法执行对 S 的调用）。因此代理将再次向 C 发送相同的消息，C 将重试对 S 的调用。
更新：
以下是 Vaughn Vernon 在他的另一本书 "DDD distilled" 中关于此主题的说法：
"与 REST 实现异步
可以使用基于 REST 的轮询顺序增长的资源集来完成异步消息传递。使用后台处理，客户端将持续轮询服务 Atom 提要资源，该资源提供不断增加的领域事件集。这是维护服务和客户端之间异步操作的安全方法，同时提供服务中持续发生的最新事件。如果服务由于某种原因变得不可用，客户端将简单地按正常时间间隔重试，或通过重试退出，直到提要资源再次可用。
这种方法在实现领域驱动设计中有详细讨论。"