Event Sourcing and Domain Event

目前看到的Event Sourcing的框架和例子,为了能够用event replay来恢复系统状态,event中需要包含所有变化的信息,而且是静态的信息。比如MatchFinishedEvent 要包含日期,比分等,


public MatchFinishedEvent(String matchId, Date matchDate, int homeGoals, int awayGoals) {
super();
this.matchId = matchId;
this.matchDate = matchDate;
this.homeGoals = homeGoals;
this.awayGoals = awayGoals;
}

因为都叫event, 我一直认为这里的event和domain event是一致的,这个event最终也会发布到event bus上供外部的subscriber消费。但是仔细想想,又觉得十分的不妥。Domain event为什么要包含那么多的信息?外部的订阅者完全不需要根据这个event来恢复状态,他们需要的只是一个“谁发生了什么类型事件”的提醒,domain event只要是下面这样就足够了。如果订阅者感兴趣,他可以根据实体id去直接查询实体的最新信息。

public MatchFinishedEvent(String matchId) {
super();
this.matchId = matchId;
}

所以我的感觉是event sourcing 中的event并不等同与domain event, 而且不应该被发布到event bus上供外部的订阅者使用。只有domain event才应该被发布到event bus上。
实际上event sourcing 中的event叫做change更合适, 他和event的概念还是不一样的。
[该贴被supernavy于2013-11-28 12:57修改过]

你的思考是有道理的,EventSourcing是导致发生Domain Event的命令,这两者都是导致聚合内部状态变化的同一个来源,应该是彼此相差不多的。

见这个代码:http://www.jdon.com/45903


2013-11-28 11:23 "@
supernavy"的内容
如果订阅者感兴趣,他可以根据实体id去直接查询实体的最新信息。 ...

依赖的存在,导致不是所有情况都能根据id查到实体,
比如:一个订单发货地址修改,关联的交货单并不一定能访问订单实体

Domain Event这个问题很重要,也思考了很久,至少在BoundedContext内部与BoundedContext之间是很不一样的。