对领域驱动设计的初步认识(五)

10-11-14 flyzb
    一边看着Evans的书,一边学习jivejdon源码,同时印证着我的经验和想法后有这样一种感觉:DDD就像一颗闪光的明珠,但从目前来讲还不够完美。

    这不禁让我想到一个问题:随着各种新的建模技术出现,我们应该如何去把握?其实在论坛里也看到大家有时也会有很多迷惑,对各种建模技术名词不知道该如何去正确的区分和运用。当然,我自己也有。为了解决这个问题,我们应该知道真正的好的建模应该是个什么样子,以此来验证各种建模技术是否能够达到心中的目标。这就好像那些玄幻小说一样,每一本玄幻都有一套体系的设定,最终的境界都是一个“道”字,都会有明确的境界标准。

    那对于我们做企业业务建模,终极目标应该是个什么样子呢?我认为这个终极目标一定是非常复杂的(也就是我原来常说的大项目场景),因为只有在复杂的场景下才能真正检验各种建模技术的偏颇。想想看,我们的建模目标应该向谁学习。论坛也有人说过,“自然的就是最好的”。是啊,经历过亿万年才进化出来的模型难道不值得我们学习吗,难道不是我们的目标模型吗!呵呵,答案已经呼之欲出了,就是“仿生物建模”。是的,没错,如果说利用我们的建模技术能够去构建出一个复杂的仿真人,具备人的一些特征和功能的话,那这种建模技术就是完美的。记得前面的帖子里,我总是提到大项目建模,有人认同,有人不以为然,还有人茫然。其实离我们最近的最熟悉的大项目就是“人体”,我们可以学着用学到的建模技术去“对人体建模”,去检验你的建模技术,这样我们会少一些迷茫。其实对于像DDD、EDA、DCI、CQRS等这些新技术,你都可以在人体奥秘中找到影子,可以通过人体本身的模型机制去验证这些技术的完备性,从而学会在实践中应该如何正确地去运用这些技术,另一方面也为这些技术的发展指明了方向。

    对我前面几个帖子有一个总结:从层次上来讲,企业的业务建模可以分为两个层面,”宏观建模”和“微观建模”。“宏观建模”是指首先要对企业做一个整体的信息化规划,对企业进行整体的的业务架构建模,其成果就是业务组件。其中的方法论可以参照IBM的CBM,不过IBM好像也只是咨询,真正的落地还要靠自己对CBM的领悟。

    Evans的DDD主要属于“微观建模”部分。对于“微观建模”,我认为分为2个方面:“结构化建模”和“行为建模”,这是一体两面。我觉得Evans对DDD总结了几个关键的要素:实体、值对象、聚合、工厂和存储,但其中还少了一个非常重要和关键的要素:“事件”。虽然banq在JF中引入了事件的设计,但我感觉还不够彻底。众所周知,人体是由很多细胞构成的,那细胞之间是如何作用的呢,其实就是“刺激”和“响应”。其中“刺激”就是“事件”,所以“事件”是业务模型本来就应该具备的要素,而不是什么技术层面的东西。从这点来看,JiveJdon中的用户发帖这个动作激发一个“发帖事件”,这个事件会导致一系列的对象和值对象的状态变化(关于jivejdon的疑问我会在后面的帖子详谈)。同时,我记得论坛里有道友对职责的划分产生疑问。那首先要明白什么是“职责”,从“事件”角度看,“职责的本质就是事件的响应”。这也就是为什么我说jivejdon对事件的运用做的不彻底的原因了。

    “结构化建模”是指建模中除了静态的实体和值对象的结构关系外,从“事件”角度看,实体或者值对象还具备一些“本能的反应”,比如"手指会弯曲"。而“行为建模”是指通过神经中枢(消息总线)来控制不同对象的本能反应来完成一个复杂的组合,比如"用手弹钢琴"。

    呵呵,先说这么多,下面的帖子我会结合jivejdon谈谈自己的疑问和想法。

[该贴被flyzb于2010-11-14 10:02修改过]

                   

7
banq
2010-11-14 15:30
2010年11月14日 01:03 "flyzb"的内容
那首先要明白什么是“职责”,从“事件”角度看,“职责的本质就是事件的响应”。这也就是为什么我说JiveJdon对事件的运用做的不彻底的原因了。 ...

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

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

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

flyzb
2010-11-14 17:46
    banq说的没错,这确实是jdon架构方向的问题。我想,所谓“业务建模”本来就是对客观世界的抽象,同样也应该遵循客观世界的基本规律。我们复习下文一下:

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

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

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

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

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

jdon007
2010-11-14 19:57
殊途同归呀。

在我发的《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修改过]

banq
2010-11-15 10:36
2010年11月14日 17:46 "flyzb"的内容
相互作用范畴具有重要的方法论意义 ...

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

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

猜你喜欢
4Go 1 2 3 4 下一页