事件模型-下一个前沿

来自"Event Processing in Action"一书的作者Opher Etzion发表博文认为:事件模型将是下一个前沿

事件一词是语义上的词语。

作者推崇David Luckham 和 Roy Schulte发表的:Why Companies Should Develop Event Models,该文对Event Model事件模型进行了定义:

一个事件代表某个发生的事情,在计算机系统中,事件是由一个对象表达,其包含有关事件的数据,比如发生的时间,地点等等。这个事件对象可以存在在一个消息或数据库记录或其他组件的形式中,这样一个对象称为“一个事件”,事件这个概念有两个含义,既代表已经发生的某个事情,也可以表达一个正在发生的对象。

至于事件到底是这两个含义中哪一个,取决于事件发生的场景(上下文)。(banq注:正如同光到底是波或粒子,取决于具体观察的场景)。


作者自己的另外一篇文章:面向事件的思考认为:生活中我们都是以事件驱动的:手机铃声响我们要么回答它或忽略它等等。当涉及到计算机系统的思考是,很多人都以一个请求驱动方式,认为这意味着:一个人发送一个请求给计算机,然后它响应。

另外一种非常典型的思维线是:事件是一个数据,我们应该将它插入到数据库中,然后请查询。(banq注:将事件当成状态数据保存,我称之为面向数据库思维)。

事件驱动EDA正在定义是:我们不知道他们何时会发生,我们甚至不知道他们是否会发生,但是当他们发生时我们做的相应事情——有时很快(例如地震检测)。

作者认为:事实上,人们试图用模型和采用传统的请求响应实现事件驱动是一个思维不匹配,并增加了不必要的复杂性。作者也在其博文用一个例子来说明。


作者总结:对事件驱动系统采用的主要障碍是人们以事件驱动EDA的方式思考,而不是传统的请求驱动的方式思考。


[该贴被admin于2013-01-30 14:32修改过]
[该贴被admin于2013-04-22 12:49修改过]


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如何看待这个问题。

2013-01-30 13:17 "@tangxuehua"的内容
Domain events has nothing to do with system events, event sourcing, any technical patterns or architectural pattern like ...

对于这段Domain Events的理解我是这样思考的:

首先,我也认为事件是一个语义词语,何为语义词?

对于计算机科学来说,语义一般是指用户对于那些用来描述现实世界的计算机表示(即符号)的解释,也就是用户用来联系计算机表示和现实世界的途径。(百度百科)

事件是一种联系计算机表示和现实世界的途径。所谓现实世界,即为领域,或者可以说,事件是跨领域和计算机的统一语言,如同实体 值对象和服务都是一种统一语言一样。这应该和Evans强调DDD是统一语言的宗旨一致的。

事件作为语义词,在不同场景下又有不同的理解,发生在领域中的事件称为领域事件,Evans这段着重领域事件区别于其他系统事件的描述,我理解应该是对不同场景下的事件语义进行精细定义,以区分其他场景下的事件语义。


这只是一个理论性的阐述,也可能是预测,请问是否有实现“事件模型”的框架,不可能每做一个项目,就重写一次关于事件的底层代码吧? Axon算不算是其中一个

2013-01-29 10:18 "@banq"的内容
另外一种非常典型的思维线是:事件是一个数据,我们应该将它插入到数据库中,然后请查询。(banq注:将事件当成状态数据保存,我称之为面向数据库思维)。 ...

我一直认为事件就是一个实体,就象聚合根是一个实体一样。
有持久化的需求,不等于面向数据库

2013-01-30 23:39 "@clonalman"的内容
我一直认为事件就是一个实体,就象聚合根是一个实体一样。
有持久化的需求,不等于面向数据库 ...

事件与实体概念没有关系,事件只是说明发生了什么或正在发生什么事,包括事件产生时的一些信息,可以认为是一个POJO,而实体则不同,实体具有状态和行为,代表现实世界的活动主体或业务主体,其能表达独立的现实意义,至于需不需要持久化取决于业务需求或系统设计需要,所以事件不是实体,也不一定需要持久化

我的问题是,既然事件是对已经发生的事情或正在发生的事情进行建模,并且大家也都认同我们可以用代码来定义domain event,即在domain中发生的事件。那一般大家如何定义事件的名称的呢?

比如我的例子,在领域中有一个事件:客户提交了一个订单,那这个事件大家是否会在领域模型中对它进行建模?如果会,那会如何命名该领域事件,该领域事件的触发者又会是谁?

事件一般我个人是名词+动词过去式,比如:OrderSubmitedEvent
对于订单提交例子,订单提交是一个Command,不属于领域事件,领域事件一般粒度要细些,订单提交后,会有OrderCreatedEvent的事件,如果订单自动审批,还会有OrderApprovedEvent事件,触发者前者是登录用户,后者是Order,再例如,Bank transfer, 是个Command,该Command执行后,会有SourceAccountDecreasedEvent事件,也会有TargetAccountIncreasedEvent事件,触发者是Account

[该贴被thinkjava于2013-01-31 14:05修改过]

2013-01-31 13:42 "@thinkjava"的内容
比如:OrderSubmitedEvent
对于订单提交例子,订单提交是一个Command,不属于领域事件,领域事件一般粒度要细些,订单提交后,会有OrderCreatedEvent的事件 ...

那就是说你在代码中不会出现OrderSubmitedEvent,而是只会出现OrderCreatedEvent了,对吗?

难道OrderCreatedEvent这就是领域事件么?呵呵,这个看起来更像是我在前一个回复中提到的系统事件。

事件如monad。

事件组合性决定了有:(事件1>>=事件2)>>=事件3 = 事件1>>=(事件2>>=事件3)。而且这种组合性,可使多个事件的组合被称为一个事件,如:“吃饭>>=洗澡>>=睡觉”,这是三个事件,同时也是 “吃饭洗澡睡觉” 这一整体事件。

同时,事件具有失败情况,同monad的fail。

这样的构造方式,可以类似人类自然语言的描述来表达。


大家这样行而上学地讨论“事件”这个概念,只会越说越乱。

在我开看,“在合适的地方使用事件”才是关键。应该说,事件是解决复杂业务逻辑设计的,一般的小系统根本就没必要。如果没有“多场景下单领域模型设计”的经历,是无法真正体会事件的妙处的。

2013-01-31 15:30 "@tangxuehua"的内容
那就是说你在代码中不会出现OrderSubmitedEvent,而是只会出现OrderCreatedEvent了,对吗?

难道OrderCreatedEvent这就是领域事件么?呵呵,这个看起来更像是我在前一个回复中提到的系统事件。 ...


代码是是没有OrderSubmitted的这样的事件的,Submit只是一个动作而已,领域事件就是产生于领域模型的事件,当然没有一个Submitted的事件了,只有Created的事件,
System Event应该指的是普通意义上的事件,比如Windows开机事件,应用登录事件等,概念比较大而广,所以OrderSubmitted是一个System Event, OrderCreated才是Domain Event

2013-01-31 23:49 "@thinkjava"的内容
代码是是没有OrderSubmitted的这样的事件的,Submit只是一个动作而已,领域事件就是产生于领域模型的事件,当然没有一个Submitted的事件了,只有Created的事件,
System Event应该指的是普通意义上的事件, ...

终于有人正面回答我的问题了,呵呵。

嗯,我也是这样想的,代码中应该无法表达OrderSubmitted这样的领域事件。但是有一点我有不同意见,就是:只有OrderSubmitted才是从领域的角度出发来命名领域事件,而OrderCreated从其名称看是指某个订单被创建了,它应该是从OO的角度来命名,表示某个对象创建了这样一个事件。而OO我觉得更贴近于软件系统,OO是软件系统开发的一种范式;所以我宁可把OrderCreated这样的事件叫做系统事件。当然我这里说的系统事件不是操作系统这样的通用事件,而是领域模型用各个领域对象(聚合根)表达后(即用代码表达后)由聚合根触发的事件。我想,这才符合Eric Evans所说的意思,就是代码中只有System Event,Domain Event只是领域中的概念,是无法用代码直接表达的东西。

还有,记得你上面提到,OrderCreatedEvent由用户触发,其实我觉得用户不是直接触发OrderCreatedEvent,直接new OrderCreatedEvent并触发该事件的对象应该是Order自己。
[该贴被tangxuehua于2013-02-01 10:57修改过]

1. DDD中有事件概念么?应该没有吧?你说的System Event和Domain Event是哪里提到的?banq先生有什么想法?
2. OrderCreatedEvent是由谁触发的,看你的观察角度了,从外部角度看就是由用户触发,从内部角度看就是Order对象创建了一个OrderCreatedEvent的事件,只是用户是源触发点,Order是直接触发,无所谓的事,都是对的

2013-02-01 12:12 "@thinkjava"的内容
你说的System Event和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