时间戳

首页 > 解决方案 > 在 EventSourcing 中应用业务逻辑的位置

microservices - 在 EventSourcing 中应用业务逻辑的位置

问题描述

在事件外包中，我对究竟必须在哪里应用业务逻辑有点困惑？我已经在 google 中搜索过，但所有示例都是非常基本的，即从事件对象更新 Handler 内对象的状态，但在我的其他场景中，对于必须应用业务逻辑的确切位置有一些困惑。

例如：让我们以一个场景来更新IntervieweeVO的状态，它存在于Interview 聚合类中，如下所示：

class Interview extends AggregateRoot {

  private IntervieweeVO IntervieweeVO;

}

class IntervieweeVO {
  int performance;
  String status;
}

class IntervieweeSelectedEvent extends BaseEvent {
  private IntervieweeVO IntervieweeVO;
}

我有一个业务逻辑，即如果受访者表现 < 3，则状态 = REJECTED，否则状态应为 SELECTED。

所以，我的疑问是：我应该把业务逻辑放在哪里？以下是3种情况：

1) 在应用事件之前：做业务逻辑，然后应用(IntervieweeSelectedEvent)，然后是 eventstore.save(intervieweeSelectedEvent)

2) 在 EventHandler 内部：在 EventHandler 类中应用业务逻辑，例如 handle(IntervieweeSelectedEvent intervieweeSelectedEvent) ，检查业务逻辑，然后更新 ReadModel 表中的对象状态。

3）在两个地方应用业务逻辑，即在应用事件之前和处理事件时（结合以上 1 + 2）

请在上面澄清我。

标签： microservicesdomain-driven-designcqrsevent-sourcingevent-driven-design

解决方案

事件溯源的主要问题是很难使用合成场景生成一个可行的示例。

但也许我可以提出比面试更好的建议。如果您比较计算机时代之前的事件源系统，您会发现事件流，它是构成某个实体生命周期的事件的存储，它相当长寿。实体中的事件可能跨越几天（跟踪某些文档流的列表）、一年（某些组织的会计期）或几十年（某些人的医疗记录）。

单个事件流通常代表单个实体——法律程序、分类帐或个人……每个事件都是对实体状态的事务性（如 ACID）更改。

在您的情况下，这样的实体可能是一个职位。开放，宣布，被面试者邀请，接受邀请，技能评估，提供报价，接受报价，职位关闭。从我的头顶。

当一个事件被添加到一个实体时，就意味着该实体的状态发生了变化。这是关于实体的新真理。你要小心改变真相。所以，这就是业务逻辑发生的地方。你运行一些业务逻辑来决定是否改变事实。如果您决定更新事实状态 - 您保存事件。话虽如此，“受访者被拒绝”在这种情况下是一个有效的事件。

由于一个事件是持久的，一个实体的所有保存的事件无条件地是关于该实体的真相的一部分，按照它们各自的顺序。然后，您无需决定是“接受”还是“拒绝”持久事件 - 只决定它如何影响投影。

推荐阅读