我觉得你的想法很好，很正确，我也和你完全一样的理解。

如果一个对象想通过事件去通知另一个对象做事情，那意味着这件要做的事情还没发生。那就不能用事件，而应该用command。我请求你做做什么，我就发一个request给你，或者command给你，然后你处理就行；所以，聚合根内，发出来的事件一定是告诉别人我发生了什么，而不能是请帮我做什么这样的事件；请帮我做什么实际上已经带有目的性，也就是说它实际上已经知道了谁会去处理该事情。如果这种情况你也用事件，虽然从技术角度来说勉强解耦了，但从语义上来说并没有解耦，也就是你说的逻辑上的依赖；聚合根之间的通信应该总是由一个第三方的对象来协调，如event handler。

所以，在国外，才会有saga的存在，或者叫ProcessManager的存在。这个就是实现聚合根的异步通信而设计的产物。
[该贴被tangxuehua于2013-04-22 12:40修改过]

感谢你的回复。
正如你提到的，没有必要将两个逻辑上具备依赖关系的聚合根使用event去“勉强解耦”。那么当我们发现当业务演化至一定程度导致我们不得不去做很多的“勉强解耦”时，我们应当去考虑重新进行系统的设计，重新去划分聚合根，而不是去纠结于“要不要去使用IOC"或者“是否使用event更好"。

言之有理，这个代码我主要是强调聚合，顺便写个事件代码，严格改写如下：

public class BacklogItem{
      private ProductVO productVO;

      public void updateProduct(){
         //向Product聚合根发事件消息实现调用
       domainevents.send(new 
                      ProductUpdatedEvent(productVO.getProductId));
      }
}

方法名称改为updateProduct，那么ProductUpdatedEvent确实是在这里发生了。

我的观点是：消息是信封，信封内的内容可以是发生的事件Event，也可以是命令Command. (如果你一定要区分事件和命令的话)

相关讨论：
CRUD in DDD
面向对象编程的关键目标
伪命题:Java传递的值还是引用?

[该贴被banq于2013-04-22 14:12修改过]