【发布时间】：2021-01-11 00:29:57
【问题描述】：
在事件源中，我对究竟必须在哪里应用业务逻辑有点困惑？我已经在 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 个场景：
1) 应用事件之前：先做业务逻辑，然后应用(IntervieweeSelectedEvent)，然后是eventstore.save(intervieweeSelectedEvent)
2) EventHandler 内部：在 EventHandler 类中应用业务逻辑，例如 handle(IntervieweeSelectedEvent intervieweeSelectedEvent) ，检查业务逻辑，然后更新 ReadModel 表中的 Object 状态。
3）在两个地方都应用业务逻辑，即在应用事件之前以及在处理事件时（结合以上 1 + 2）
请在上面澄清一下。
【问题讨论】：
-
有什么想法吗？
-
您应该能够从事件流中重建实体在特定时间点的状态，这意味着应用事件可能不应该负责随时间变化的逻辑，而应该只负责投影实体的状态。业务逻辑将进入生成事件 IMO 的实体方法中。如果今天的
performance < 3, then...规则与当时不同，您仍然希望能够像使用旧规则一样投射旧状态。 -
不，
apply只是为了投影状态，不应该有任何业务逻辑。entity.doSomething() --> apply(SomeThingHappened)。逻辑在entity.doSomething()。 -
是的，否则如果在您从事件重新创建实体时业务逻辑发生变化，如果逻辑位于
apply中，您将不会具有相同的状态。 -
例如在您的情况下，您可能有
interviewee.assessPerformance(POOR)产生IntervieweePerformanceAssessed和IntervieweeRejected我认为的事件。然后，如果规则发生变化，您可以致电interviewee.reevaluateSmartScreeningPolicy()或类似的名称。
标签： microservices domain-driven-design cqrs event-sourcing event-driven-design