architecture - 您如何在 Udi 风格的 SOA 架构中聚合数据？

Question

我们正在以 Udi Dahan 方式实现 SOA 架构，这意味着服务是与业务对齐的自治组件(我们有很少的服务，每个服务都拥有域的一部分，并且不允许它们相互调用)。我们正在使用 nservicebus 发布/订阅。我试图找出处理“跨领域”数据问题的最佳方法。

让我给你举个例子:

我们有一个游戏服务，用户可以用它来玩游戏。游戏有截止日期，我们想通过向用户发送邮件来警告截止日期何时结束。邮件将包含来自多个服务的数据。现在，由于服务不能调用其他服务，我看到了几种不同的方法:

1)在game-service中处理

从其他服务发布足够多的消息，以便游戏服务可以存储其所需数据的自己版本，因此在编写邮件时不需要依赖其他服务的数据。

缺点:

-更多消息需要发布
- 数据的非规范化
- 繁琐的数据所有权(一个事实在多个地方)
- 向邮件添加新数据很麻烦(更多消息，将东西存储在游戏服务中)

2) 创建聚合服务。

创建一个聚合服务，它将监听服务事件，存储创建邮件所需的所有内容，并在游戏服务通知截止日期即将结束时将其关闭。

缺点:

- 与 1) 几乎相同，但数据所有权更清晰

3)创建客户端

创建一个“客户端”(这个客户端将没有 gui 并且将被 nservicebus 托管，与服务几乎相同，但也有一些非常不同的东西)。客户端将订阅总线事件，就像 2) 当截止日期结束时，它会收到游戏服务的通知。客户端将通过查询所需的服务来撰写邮件以收集所需的信息。

缺点:

- 客户端服务(模糊架构)
- 撰写邮件所需的一切都必须是可查询的(公开)

您是如何在出色的 pub/sub Udi 风格 SOA 架构中做到这一点的？ :-)

Answer 1

如果您可以处理 HTML 电子邮件，那么让您的电子邮件组件获取执行常规形式的组合的 URL 的 HTML 输出。如果您不能使用 HTML，那么您将需要 IT/Ops 服务来收集信息(但这是通过与安装在同一端点上的各种业务服务的组件进行的进程内通信来完成的)。