winter 2009-10-20 17:14
看了几篇Udi的文章，通过Domain event确实可以避免Repository和Service的介入，使Entiry专注于业务逻辑，不过对于不同的业务需求我们就需要增加大量的handler其实现就是repository和service的相关代码，感觉有些不爽
Abramdy 2009-12-02 14:43
bastion框架中的适配监听器的触发机存在这样的问题:
领域消息事件与适配监听器是一对多的关系，按照现在的设计，同一个消息事件可能会触发多个适配监听器，不甚合理。例如，A、B模块需要在同一个查询消息事件下绑定各自的查询适配监听器，A模块的发送的查询消息事件同时会触发B模块的查询服务。是否需要为在同一消息事件下绑定的不同适配监听器设置标示符，从而能够和领域消息事件中存储标示符匹配？
[该贴被Abramdy于2009-12-02 14:47修改过]
banq 2009-12-03 09:18
2009年12月02日 14:43 "Abramdy"的内容
bastion框架中的适配监听器的触发机存在这样的问题:
同一个消息事件可能会触发多个适配监听器，不甚合理。
[该贴被Abramdy于2009-12-02 14:47修改过]

是的，我从JdonFramework 6.2开发中也感觉这个问题，原来设置观察者模式是一对多，结果发现使用变得复杂，现在改为一对一，简单。

qiuriyuchen 2011-12-29 11:19
首先感谢下banq的Domain Events – 救世主，看了很有启发，但又有些不太一样的观点，我认为实体可以调用服务或Repository，但不能用Repository来加载自己，但可以使用Reepository中的其它方法。Domain Events – 救世主中的观点是实体要通过事件机制来访问服务及Repository,我觉得绕了一圈不还是调用了吗？还费了些效率，直接调用不就好了吗？其实核心应该是应该实体里实现的业务逻辑，不能放入实体调用的服务中，让实体贫血，但这和调用机制是直接调用，还是通过事件机制调用是没有关系的啊，就算是通过事件机制，一样可以在实体里贫血，然后触发个事件，事件都是在事件机制调用的服务中来做。所以我觉得没有必要引用事件机制，该调用就直接调用，但哪些逻辑写在哪才是关注的重点，不能调用了服务就把本该实体的代码写到服务里。实体，服务，及Repository都是领域层的概念，直接调用从分层上说的过去。
学习过程中的想法，望大家指点。
zyskm 2012-03-07 17:41
没这么玄乎吧，还整出救世主来了。
我前段时间分析了下tomcat源码，tomcat引擎调用其它外部组件就是通过事件进行。tomcat6是很早之前的实现方式了。
banq 2012-03-08 11:40
2012年03月07日 17:41 "@zyskm"的内容
没这么玄乎吧，还整出救世主来了 ...

有些误解，事件一直存在，但是业务领域模型发出事件Domain + Event则是事件在软件中一个新的应用方向。

业务对象BO在SSH或EJB架构下，是被“奸”的，被传来传去，自己不能做主，一个软件是其所表达的业务重要还是其表达语言重要呢？无疑是业务，但是业务重要，在软件系统中又不占据主导支配地位，而是被支配地位，这就名不符实了。

Domain Event领域事件给领域模型以命令所有技术语言的权力。还权力回归核心。