DDD中关于实体的概念不太明白,请指教

07-02-23 free49498445
《Domain-Driven Design》中对实体有这样的话:

对于实体而言,我们关注的重点不是它们的属性或行为,而应该把繁枝茂叶从定义中剔除出去,只留下那些固有的特征,特别是那些用来惟一标识对象,以及经常用来查找和匹配对象的特征。只加入核心概念所涉及到的行为,以及行为需要的属性。

本人对其中所说到的 “核心概念所涉及到的行为”不太明白,不知道这是什么样的行为? 比如说 人 是一个实体,那 吃饭 是不是就是应该加入的行为?就应该被封装入实体中? 那 打架 是不是核心概念所涉及到的行为?

哪位大哥能不能举几个更具体的例子?如果能用jivejdon中的例子那就更好了。

         

jeffrey4chartcrm
2009-01-18 00:52
只能说按照特定的需求,特定的环境来判断。举个例子,人是实体,吃饭在某个场景中是他的行为。而在另外个场景中,打架是,而吃饭不是。我理解的就是这样,不知道其他人的看法是怎么样?

IceQi
2009-01-18 17:21
楼上的,非常非常正确。

看你前一个帖子的提问,其实用同样的方式进行思考你也可以找到答案的。呵呵,那里我就不回啦

freebox
2009-01-18 23:51
这其实是计算机弱智的表现,奔腾芯片的智慧能力并不比蚯蚓高级,而人是更智慧(至少我们自己这样认为)的生物,所以您很容易教会一个孩子(新系统)各种事情(打架和吃饭当然都在其中,但绝非仅这两种),却很难让计算机拥有同样复杂的处理能力。

虽然在智慧上计算机比不了人,但是计算机却拥有比人更强大的存贮和计算能力。

企业软件不只是档案库,记完就了事,它需要分析状况,并做出一些简单的判断,尽管不能代替人,却可以给出一些有效的指导,甚至有时候给出一些指定的逻辑,让它自己完成某部分非常规则的判断,吃饭和打架显然是更复杂的逻辑判断,企业软件只能给出近似的模拟。所以就需要简化世界模型,让软件变得更“专”。这就说明吃饭的动作在某种意义上不至于对打架的行为产生影响(虽然实际上吃得饱打起来更有利,但假设您并不需要分析这一状况),在这种互不干涉的情况下就需要忽略细节问题,把握主要问题。

而对于那些总是要求在项目结束后自己可随意亲自定义软件(比如加个属性,整个查询什么的)的需求,我们一般都持否定意见。尽管不太恰当,但我认为这里面很好地应用了热力学第二定律。

bloodrate
2009-01-19 09:05
"只能说按照特定的需求,特定的环境来判断。举个例子,人是实体,吃饭在某个场景中是他的行为。而在另外个场景中,打架是,而吃饭不是。我理解的就是这样,不知道其他人的看法是怎么样? "

这话不假,但是有误导性。

一个更现实一点的问题是,如果在设计前期,设计"人员"这类的时候,是否应该将吃饭加入到其行为之中?可能同一个系统有些场景需要用到吃饭,有些场景需要用到打架,但你能因为部分不需要用到吃饭的场景而将"吃饭"排除在外?或者作两个人员类,一个吃饭一个打架?我的意思是先将所有可能的动作包装在一起,如若有问题,后来再重构。

猜你喜欢
2Go 1 2 下一页