【问题标题】:Accessing different bounded context data from saga从 saga 访问不同的有界上下文数据
【发布时间】:2012-08-29 07:57:50
【问题描述】:

我使用 NServiceBus 创建了一个 saga,它请求外部服务以获取客户信息并超时。超时后,传奇检查外部服务是否有响应。作为回应,我有相应客户的数据,现在我必须检查相应客户是否存在于我们的系统中(如果他不存在 - 我必须创建他),然后我必须创建一些额外的审计实体来引用那个客户(如果我拥有创建它们所需的所有信息)。

我想知道我应该如何检查特定客户是否存在以及何时不存在如何创建他。

到目前为止,我有一些想法:

  • 从消息处理程序内部调用 WCF 服务(检查、创建)

  • 通过 NSB 将消息发送到客户有界上下文并等待带有 ID 的响应。

【问题讨论】:

  • 你能描述一下你的第一条消息是什么吗?这可能会影响答案。
  • 嗨 Udi,我澄清了我的问题。
  • 外部服务也是 NSB 端点(客户 BC)还是类似 RPC 的 Web 服务?
  • @eulerfx - 我请求的外部服务是外部公司提供的类似 RPC 的 Web 服务。我们系统中的客户 BC 将用作 NSB 端点和 WCF(尤其是 UI 层)。
  • 检索客户数据是从 saga 的角度进行的查询(我假设这在 BC 中与 Customer BC 不同)。我会将此责任封装在客户 BC 中,以便它处理对外部服务的调用并根据需要创建/更新本地数据。然后,当 saga 需要客户数据时,它将向 Customer BC 中的服务发出查询。 NSB 并不意味着处理查询,因为通常查询需要立即响应。

标签: domain-driven-design nservicebus saga bounded-contexts


【解决方案1】:

您可以为此利用 NServiceBus 消息处理管道。将“客户服务”中的处理程序配置为首先运行,该处理程序检查客户的存在并在必要时创建它们,最后在正在处理的原始消息上设置 CustomerID 属性,以便下一个处理程序知道它是什么。

这让您受益于整个流程的事务一致性。

您描述的发布/订阅模型也可以工作。我不太喜欢它,因为您要对事件进行一种请求/响应,并且不清楚谁真正对客户信息负责(因为所需的数据来自不负责的发布者)客户)。

如果不深入您的领域,就很难更有规范。

【讨论】:

    猜你喜欢
    • 2020-01-01
    • 1970-01-01
    • 2016-12-07
    • 2022-01-23
    • 1970-01-01
    • 2018-10-02
    • 1970-01-01
    • 2013-08-03
    • 2011-11-30
    相关资源
    最近更新 更多