[该贴被flyzb于2010-11-15 12:50修改过]

举个例子，人的最外层的皮肤就如同“门面”，用来接受外界的“刺激”，内部再由“大脑”下达指令，指挥各个“肢体”进行“响应”。

“神经网络”是被这层皮肤覆盖加以保护。

“神经元”向“皮肤”注册可能完成的“响应”，而“皮肤”接受“刺激”后由大脑进行反馈而回调“神经元”,“神经元”再完成各个指令动作。

这里所说的业务场景类应该就是DCI实现合适的，不同的功能就对应不同的业务场景，你的系统有100功能，就有100业务场景。

这里的业务场景是软件运行的场景，而不是我们要专门定义个业务场景类，注意，这里要从被传统OO语言误导中走出来，谈到对象，就首先要建一个类，这不对的（相关讨论），我们这里业务场景实际是一个运行时动态混合对象，就类似MVC中Controller。

无论MVC的Controller 或Mediator模式，还是DCI模式，我们已经默认将他们划归为“行为模式”了，行为模式一种注重行为相互作用的大类别模式，其中有Command模式 观察者模式 等事件模式，而他们之间又分为两种类型了，一种事件模式；一种DCI模式(暂时这么分类)。

问题纠结在于：这两者到底各有什么优缺点？

[该贴被banq于2010-11-15 14:49修改过]

场景和事件

    我认为“DCI就是在一定的场景下不同的角色（对象）在交互，同时相互传递数据”。DCI强调对象在场景下变成角色，并参与交互；DCI中的对象的行为是动态的。而我认为事件更揭示了DCI的本质，在场景的刺激下，一个对象发生了行为，然后产生后果（事件）激励着一个或者更多个对象发生行为并产生更多的后果；通过这种连锁反应（我称之为“事件路由”）表现为多个对象相互作用并传递数据（消息）——这就是“功能”。

    从上面的图片就可以看出，事件对交互的描述更加精确和灵活。然而更重要的一个难题:"如何在复杂交互场景中解决一致性的问题？"。比如经常会遇到这样的问题：“哎呀，场景1：对象A的行为会影响到B，再会影响到D，反过来影响到C；场景2：A——》B——》D,哦，晕了。。好像还有A——》C”，这其中可能会产生大量的漏项或错项，使得领域对象的一致性很难得到保证。因为现实世界里事物的交互太复杂了，尤其是在中国，尤其是要做中国的管理软件产品。在我的项目实战中发现，“事件”可以让我们在对象产生行为后只需发出事件即可，不用去管谁会关心这个事件。这个优点非常重要，可以让我们只关心对象行为本身；而事件的影响是由场景决定的，场景的复杂多变决定了“事件路由”的形成，也就是“业务规则”。

    呵呵，上面的分析让我更加坚信：“业务建模应该遵守客观规律”。

[该贴被flyzb于2010-11-15 23:09修改过]

嗯，这句话很有启发，让我联想到Scala就是将异步事件消息和DCI结合起来，当我们编写第一Actor(相当于类)时，是使用DCI的方式加入这个Actor对应角色的行为职责；而Actor成为对象在运行时，Actor之间是通过异步消息事件(邮箱)通讯的。

DCI更侧重的是一种行为混合注射方式，是编程阶段一种模式，因此，将DCI归结为结构型模式可能更合适，就像MVC模式更多是一种结构型模式一样，MVC模式已死，而MVC中C是Mediator行为模式，DCI中I代表行为模式。

而事件就是一种完全运行状态名词，可以和“相互作用”直接对应。

重新想想前面我说jdonframework面临方向选择，也就是事件和DCI选择，为什么有这困惑，是不是Java这个语言不能象Scala那样，完美地将事件和DCI有机结合在一起呢？

总结一下：DCI概念更接近业务建模(业务建模代表客观事实)，因此使用DCI可以让我们抛弃传统“类”概念，而直接以一种职责分配思维方式来编程，去除了业务建模和技术设计实现的鸿沟，也就是翻译转换过程；而业务建模中相互作用的设计，则可以通过事件或直接调用(DCI内部)来完成。

当然，事件分异步和同步，同步事件实际就是直接调用，这些都可以根据实体的聚合边界来确定，聚合体之间使用异步，最大可能松耦合；聚合体内部直接调用，一个聚合体类似Scala中的一个Actor。

感谢flyzb让我思考清楚这个问题，顿悟快乐很好，下面我想思考的是：如何在jdonframewok(jivejdon)将事件和DCI柔和在一起，反正也有纯粹的DCI API开源包了，也欢迎有兴趣者一起来推进Jdonframework重大架构发展。