你的疑问可能和这段理解有关，对象的行为由事件触发，但是不代表两者是同一个概念。
如果你区分了对象的行为和事件，那么就会思考事件到底是什么，其实在传统技术架构比如SSH中，我们的对象行为是被用户的请求触发的，用户的请求提交给Struts，然后通过Struts 的Action提交到Spring的服务，调用服务的一个方法行为。
这个思维方式是一种请求/响应思维，而我们现在要以事件替代请求/响应(request/response)，这就是EDA最大不同。
因为思维方式不同，那么肯定有不同的框架，Jdonframework就定位在事件角度。
上面流程就变成：用户发出一个命令command，被富领域模型的行为接受处理，在这里会有多个命令操作同一个模型的同一个状态的问题，一般要引入堵塞锁，Jdonframework通过Disruptor的队列实现某个时刻只有一个线程调用模型的行为进而修改状态，非堵塞无锁。
第二点，当模型中的状态被修改以后，会有一个事件触发，称为领域事件，实现EventSourcing，关于DDD和ES的关系见：http://www.jdon.com/46041
除了对业务的思考方式不同，技术特点也不同：
比如在一个典型SSH应用案例中，用户界面中的用户请求（在浏览器中，REST客户端或其他地方）发送到web层进行解析，然后分发到中间件服务组件，通过它的高速缓存然后下推到数据库。如果这些层中任何一个层都不参与以下操作：阻塞调用数据库，依靠共享的易变状态，使用昂贵的同步操作进行调用，那么整个请求处理响应的流水线就不会停顿，用户就不会将遭受延迟通过增加和减少的可扩展性。
An application must be reactive from top to bottom
一个应用必须从顶层到底部都是reactive的。
http://www.jdon.com/45811#23143632
Jdon框架提供了整个技术堆栈都是可异步和高并发的。
[该贴被banq于2014-01-02 20:00修改过]
请求和响应是一对，谈到请求就要有响应，请求不能单独存在，就象谈到服务就有客户端一样，两者是配对的模式。
问题来了，因为请求和响应是一起的，所以谈到请求就必要有响应，而实际中有时请求只需要有一个http 200的响应就可以了，这时响应就没有意义，就剩余请求了，这个请求就蜕变成事件了。变成事件的好处是，原来请求必有响应其实是同步，而没有响应的请求其实是异步，异步并发概念可以引入了。
请求(事件)在多层之间传递时，身份其实有改变的，在进入聚合根实体模型之前是命令(有时也称为事件 比如UI的javascript点击按钮也称为事件)，改变实体对象状态后是领域事件，也就是在领域中发生的事件，不是UI发生的事件。
行为是对象的能力，打个比喻，如果把行为看成是炸药的引子，那么事件就是点燃引子的火种。行为是在我们设计类时根据业务特点设计好的，而事件是在运行时才产生，事件类似交互的行为，而普通行为是对象职责行为，按照单一职责SOLID等等设计的。
行为是静态的，事件是动态的。
在事件驱动场景下，一个用户发出命令要修改聚合根实体模型的状态，这个命令是通过守护状态的行为实施的，打个比喻，状态是宝贝，守护行为是警卫，大盗是通过警卫才能取得宝贝。在事件驱动情况下，这里我们引入单写原则，同一个时间只有一个线程修改状态，虽然锁也能达到这个目的，但是我们这里没有用锁，而是如何让Java以光的速度跨线程通信中的Railway算法或RingBuffer算法，而传统请求/响应模型，这里引入的是 ACID事务，比如 JTA(Spring or EJB session bean) 或者使用HHibernate/JPA的乐观锁rOptimistic lock(Hibernate/JPA)。两者比较见：http://www.jdon.com/performance/singlewriter.html
[该贴被banq于2014-01-02 20:48修改过]
这很正常，我觉得大部分是受现有技术的误导，为什么认为是被误导呢，因为在Node.js中这种行为事件驱动的方式很自然(http://www.jdon.com/46024)，或者在面向函数编程中就很自然。
修改内存中数值，然后将触发修改行为的事件作为日志保存到日志文件中，MongoDB等NoSQL内部机制都是这样，可能我们更多知道memcached的内存读，很少知道NoSQL这种内存写的原理。
谈到这里，你可能发现Node.js + MongoDB其实和Jdonframework的殊途同归。这也是为什么看好Node.js的原因所在。
请问模型的变化怎么刷新到UI？Ajax轮询还是基于长连接(WebSocket?)，说点实在的吧
1.敏捷可参考：http://www.jdon.com/agile.html
2.关于请求/响应中如何返回客户端问题，当我们转移到EDA思维时，关键是UI界面已经也不是传统UI了，而是一种响应式的UI，传统UI是一种表单几十个字段，不管先后主次都罗列平铺在界面上，用户提交这种大表单后，当然希望后台返回一个出错，出错在哪里的响应。
但是如果在移动界面下，你不可能这样做，我们在手机上看视频时，视频界面操作界面是隐身的，当我们需要时，点触屏幕，发出命令或事件，屏幕响应，会浮现出控制界面，然后你点触“停止播放”或“加快”等等按钮。这就是原本将空间上并排罗列的元素变换成在时间上的根据事件先后显示。
所以，用户每次输入的是很少数据，输完一段，按下一步，通过流程上安排，如果必须同时输入很多，我们也是通过AJAX对这些数据逐条验证，确保用户按提交保存按钮时，除非技术原因，业务上出错基本排除。而技术上原因，可以从http码上反映，可以查查http码大全。
见：任务驱动的UI
JS讲究事件驱动，AJAX，甚至单一应用，如Angular,js只在一个网址下实现各种应用，没有我们通常提交表单后显示另外一个页面的URL，Java程序员一般喜欢主导这个响应结果页面，而面对Angular.js这样客户端MVC，后端Java不再主导前端，而是平等的对话。
我现在很有体会为什么Paypal将后台换成javascript，让JS前端来主导后端，可能效果更好些。