事件采购有副作用的

我使用的是熟悉的事件采购模式构建服务：收到事件采购有副作用的

的请求。
聚合的历史被加载。
聚合重建（从它的历史）。
准备好新事件，并根据来自步骤1的传入请求更新聚合。
这些事件写入日志，并且可供任何订户使用（发布）。

就我而言，第5步分两部分完成。事件写入事件日志。后台进程从事件日志中读取并发布从偏移量开始的所有事件。

在某些情况下，除了与聚合有关的事件之外，我还需要发布副作用。就系统而言，这些也是事件，因为它们被其他服务所消耗并影响其他服务的状态。但是，它们不会影响此服务中聚合的历史记录，也不需要重建它。

我该如何处理这些代码？

选项1- 不要将副作用事件写入事件日志。在步骤5之前的主流程中发布这些文件。

选项2- 将所有内容写入事件日志，并在加载历史记录时忽略副作用事件。（这些不是历史的一部分！）

选项3- 将副作用事件写入虚拟聚合，以便它们发布但从未加载。

选项4- ？

在第一个选项中，如果存在并发冲突，可能会出现问题。如果在步骤5中写入失败，则副作用不容易回滚。第二个选项写入不属于聚合历史记录的事件。当在步骤2中加载时，这些副作用事件将不得不被忽略。第三个选项感觉像一个黑客。

这些看起来是对的吗？

来源

2016-01-04 Charles R

您通常会选择2.假设您有事件源应用程序，例如银行业务和第二个应用程序统计信息，这些统计信息根据第一个应用程序中发生的事件构建统计信息。假设统计应用程序订阅您的“副作用事件”。一切工作都不会挽救那件事，直到你的生意说：“我们想把它们作为单独的系统出售”。现在，在使用银行应用程序两年后，您的某个客户会购买统计应用程序，如果您之前未将“副作用事件”保存到ES，则会错过某些概念，甚至会失去同步效果。 – Dariss

@CharlesR你能举出这种“副作用”的具体例子吗？我不确定为什么不影响任何总计状态的东西应该首先作为域名事件来处理...... – guillaume31

@ guillaume31总计是“合作伙伴欠款金额”。这是发送出来的钱，我们需要回收。我们不是直接向客户开具账单，而是从未来的钱中拿出这笔款项。在我们分配资金之前，我们检查合作伙伴是否欠款，并收回欠款。然后我们发布域名事件来更新合作伙伴的现金余额并分配任何资金。从这项服务的POV中，这些是请求或副作用。我们需要发布它们，但它们不会影响汇总状态（欠款的合作伙伴金额）。 –

选项4 - 让其他服务订阅事件并产生副作用，以及任何与它们相关的其他事件。

事件应该是细致的。

来源

2016-01-05 06:08:46 KarlM

正确地命名事件

事件是“发生的事情”。 因此，如果您能够命名仅以“X发生”方式触发副作用的事件，它们将成为事件历史的自然组成部分。

根据我的经验，这总是有可能的，因为副作用不是凭空发生的。有时这个名称会变得有点虚假，但最好以这种方式命名事件而不是称它们为例如“发送电子邮件到该客户端事件”。

在你的备选名单而言，这将是选项2

例

而不是调用事件的“发送状态电子邮件客户事件”，称其为“状态电子邮件触发事件”。当然，如果没有为实际触发一个更好的名字，使用一个:-)

来源

2016-01-05 06:19:46 theDmi

选择1 - 不要写副作用的事件记录到事件日志。发布这些在之前的主要工艺步骤5

如果你以后通过建立一个新的界上下文需要历史的一部分？

选项2-将所有内容写入事件日志，并在加载历史记录时忽略影响事件的副作用。（这些不是历史的一部分！）

如何忽略某些没有任何效果的效果？：D

选项3-将副作用事件写入虚拟聚合，因此它们是已发布但从未加载。

为什么你需要一致的边界来围绕你永远不会改变的东西？

你说的是域事件的最常见形式，你用它来与其他BC-s通信。 OFC。你需要保存它们。

来源

2016-01-09 03:46:41 inf3rno

事件采购有副作用的

回答

正确地命名事件

例

相关问题