嗯，其实在这里面临架构方向选择，目前jivejdon是我对事件方向的一个尝试，在另外一个方向上还有DCI(Data Context Interaction)，关于关于职责 事件 DCI，如何有机结合实现，还需要继续在理论上探讨一下，哪个可能是未来趋势。

用事件来实现职责，在过去SOA以及传统架构比较常见，也有Scala的邮箱通讯机制，如果说事件机制类似观察者模式，是一种分布式通讯；那么DCI则类似Mediator模式，它是一种封装通讯，其实比Mediator更彻底，根本就没有事件概念，直接和角色 职责 场景等业务建模概念结合。

事件的导入是否对非技术人员等多一个概念，事件到底是不是技术概念，这些还需要多多探讨，愿听其详。

    相互作用原则全面、深刻地揭示了事物之间的因果联系，是因果关系在逻辑上的充分展开。在客观世界的普遍联系链条中，原因和结果经常互移其位、相互转化。受原因作用的事物在发生变化的同时也反作用于原因，从而把因果性关系转变为相互作用的关系。其中每一方都作为另一方的原因并同时又作为对立面的反作用的结果表现出来。整个物质世界就是各种物质存在普遍相互作用的统一整体,相互作用是事物的真正的终极原因,在它之外没有也不可能有使它运动和发展的原因。相互作用也是系统内部诸要素的关系和联系的形式。要素之间相互作用的方式构成系统存在的基础，系统中要素的相互作用是决定系统发展方向的因素。相互作用只有借助于特殊的物质载体才能实现，相互作用的内容取决于组成要素的物质层次和性质。例如，现代生物学把相互作用划分为分子的、细胞的、器官的、机体的、种的、生物圈等不同水平的形式。社会生活是最复杂的相互作用的形式。

    相互作用是客观的、普遍的。具体的相互作用是整个物质世界相互作用链条的环节和部分，相互作用的普遍性和绝对性通过无限多样的具体的相互作用而体现出来。相互作用是事物的属性、结构、规律存在和发展的条件。

    相互作用范畴具有重要的方法论意义。认识事物意味着认识它们的相互作用，要揭示事物的本质属性，就必须研究事物之间具体的相互作用的特殊性。相互作用的实质是矛盾以及矛盾诸方面的相互依存和斗争。在诸多因素的相互作用中，必有一种起着主导的决定的作用。在实际工作中，只有认清事物之间相互作用的特点和规律性，才能认识和把握事物的本质。

    “事件”这个词的确有技术范畴的嫌疑，但说到“相互作用”、“输入和输出”，大家都会明白的。我不知道banq有没有这样一种感觉：过去的OO过于僵化、教条，偏重于静态场景，忽略了客观世界运动和相互作用的本质规律，而最近出现新技术和对OO的反思“正在回归自然”。

[该贴被flyzb于2010-11-14 17:52修改过]

在我发的《Hello, World! 我心中的道》帖子中，uda1341提到“得救之道”，这个使我联想到其它领域比如生存等，人们的终极思考竟然极其相似。《天道》（《遥远的救世主》）对得救之道的回答，竟然也是“道法自然”式的结论（神即道，道法自然，如来）。

在讨论中，我也认为“世界是有事物及其活动组成”或者“世界由事物及其相互作用组成”是非常朴素、直观的世界观。uda1341引用维特根斯坦“世界是事实组成的”观点，也解释的通，个人感觉也比较简单、易于理解，只是如何运用这个观点我还没有想清楚。还望uda1341能系统地整理自己的思考，给大家更多的启发。

我个人认为目前的“领域建模”可能大多只停留在描述或者仿生“领域的事物(what)及活动(how)”，可能并没有深入研究领域的模式或规律(why)。研究领域的模式或规律，也许也没有这个必要，因为我们只是在做工程；甚至也没有这个可能，研究规律谈何容易。这似乎可以看作工程与科学的一个边界。

举个例子，复杂网络的建模，复杂网络的具体例子有生物网络、交通网络、互联网、神经网络、社会网络等，科学家要从这些网络抽象一个通用的模型，这个模型要足够简单，又不能太简单（比如，只将网络当成点与边的集合），一旦成功建模后，科学家们便可以研究模型找出规律，用于指导实践和预测未来。可是构造一个通用的模型几乎不可能，建立起来的模型往往只能反映现实的部分特性。不幸中的万幸，是作为工程师，我们可以选择避开这个难点，很多时候也只能这么做。正是避开了这个难点，四色模型我才感觉很简单。

Object-Oriented，object这个术语在台湾被翻译为“物件”，这个词本来是可以接近“事物”这个概念，可是从这个术语被发明以来，其含义远没有勾勒出“事物”丰富的内涵（在我的帖子中提及了一些），此外这个“术语”也没有表达出程序领域自身的特性。对OO不满的人大有人在，比如stl的发明者对OO嗤之以鼻，linux之父也曾经炮轰C++,这与OO本身的表达能力的局限性不能说没有关系；OO的特性，在PO中模拟实现也不复杂。（在帖子中有个简单的例子以及相关谈论。）

相对PO，对OO的运用我更娴熟，最近的思考使我开始也意识到其不足到底在哪里，以前我只是思考过PO与OO的相通与相异之处，却从未思考过它们具体的缺陷在哪里，未来的语言会怎样解决这些问题？

还有一点，关于建模与需求分析的关系，之前我只是简单的认为是“需求分析的目标是就是建模，建模后指导技术实现”。最近在思考即时通信的领域模型，发现模型本身也有助于我们做好需求分析，如果有可能，甚至可以放在需求分析之前，或者对两者以拉锯式、互相推动的方式进行思考。

[该贴被jdon007于2010-11-14 20:01修改过]

“相互作用”这是毋庸置疑的，关键是是如何表达它们？用事件 还是DCI?

这个问题比较纠结。呵呵。