flyzb
2010-11-15 12:33
    看来我们都有共识,“相互作用是关键”。同时,我们也认识到,“事物之间相互作用非常复杂”。我觉得DCI所关注的核心——“场景”是事物行为的表现,但不是客观的存在。我们还是以“人体”为例,试想一下,“打一套太极拳,做个广播体操,360度空翻。。。”都是复杂的场景。如果把人体能够做的各种“运动场景”加起来,会可能出现“场景爆炸”。当然,这些复杂场景里存在大量的重复的子场景,但这些子场景在数量上仍然是爆炸性的。所以我建议学习“经过亿万年进化而来的客观存在的生物控制模型”,我们都知道“人体是通过神经网络来控制不同的肌肉、骨骼来做出各种复杂的动作的”。“刺激和响应”是客观存在的,而“场景”只是我们对客观世界的主观认识。

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

donglangjohn
2010-11-15 14:33
“刺激和响应”

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

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

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

banq
2010-11-15 14:40
我记得在你的(三)中,有这样一段:在这些不同的业务场景下,user都可以聚合根,这很正常,因为人可以干不同的事情。但如果把这些业务集成起来就有问题了。所以说作为聚合根的领域对象应该是业务场景类,而不应该是类似user的这样的类

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

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

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

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

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

flyzb
2010-11-15 22:58
    其实,我并不认为DCI和事件是对立的,相反它们是从不同角度去描述对象行为,如下图所示:

场景和事件

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

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

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

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

banq
2010-11-16 08:51
2010年11月15日 22:58 "flyzb"的内容
我并不认为DCI和事件是对立的,相反它们是从不同角度去描述对象行为 ...

嗯,这句话很有启发,让我联想到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重大架构发展。

猜你喜欢