2013-01-29 10:18 "@
banq"的内容
作者总结:对事件驱动系统采用的主要障碍是人们以事件驱动EDA的方式思考,而不是传统的请求驱动的方式思考。 ...
如果是以请求驱动的方式思考,那是否可以理解为请求就是事件?
另外一个疑惑想请教一下:
我发现我们会引入领域事件(Domain Event)到我们的领域模型中,而我在网上摘录了这样一段话:
Domain events has nothing to do with system events, event sourcing, any technical patterns or architectural pattern like CQRS.
Domain events are something that actually happens in your customers business, not in your software.
Below is an excerpt(摘录,引用) from the domain event pattern, as defined by Eric Evans.
Model information about activity in the domain as a series of discrete(不相关联的,非连续的) events.
Represent each event as a domain object. These are distinct from system events that reflect activity within the software itself, although often a system event is associated with a domain event, either as part of a response to the domain event or as a way of carrying information about the domain event into the system.
A domain event is a full-fledged(羽翼丰满的) part of the domain model, a representation of something that happened in the domain.
Ignore irrelevant(不相干的,不恰当的) domain activity while making explicit the events that the domain experts want to track or be notified of, or which are associated with state change in the other model objects. – Eric Evans
这段话的意思是,Domain Event是领域中的概念,非软件系统中的概念,软件系统中的叫System Event.一个Domain Event可能会衍生出多个System Event.
那我的想法是,我们是否应该在领域模型中定义Domain Event?如果应该,那我发现有些领域事件实在知道该由谁来触发该事件。比如一个电子商务系统,一个客户提交了一个订单,那在领域中会有一个OrderSubmitted的领域事件,但是我发现我们无法在领域模型中定义该事件?如果要定义,那该由谁来触发呢?
如果用Event Sourcint模式,那我只会定义一个OrderCreated,该事件在Order类的构造函数内触发。但是就像上面所说,OrderCreated事件不等于OrderSubmitted,前一个是系统事件,后一个是领域事件。OrderSubmitted触发时所影响的对象是很多的。
不知banq如何看待这个问题。