《Domain-Driven Design》中对实体有这样的话：
对于实体而言，我们关注的重点不是它们的属性或行为，而应该把繁枝茂叶从定义中剔除出去，只留下那些固有的特征，特别是那些用来惟一标识对象，以及经常用来查找和匹配对象的特征。只加入核心概念所涉及到的行为，以及行为需要的属性。
本人对其中所说到的 “核心概念所涉及到的行为”不太明白，不知道这是什么样的行为？ 比如说 人 是一个实体，那 吃饭 是不是就是应该加入的行为？就应该被封装入实体中？ 那 打架 是不是核心概念所涉及到的行为？
哪位大哥能不能举几个更具体的例子？如果能用jivejdon中的例子那就更好了。
只能说按照特定的需求，特定的环境来判断。举个例子，人是实体，吃饭在某个场景中是他的行为。而在另外个场景中，打架是，而吃饭不是。我理解的就是这样，不知道其他人的看法是怎么样？
楼上的，非常非常正确。
看你前一个帖子的提问，其实用同样的方式进行思考你也可以找到答案的。呵呵，那里我就不回啦
这其实是计算机弱智的表现，奔腾芯片的智慧能力并不比蚯蚓高级，而人是更智慧（至少我们自己这样认为）的生物，所以您很容易教会一个孩子（新系统）各种事情（打架和吃饭当然都在其中，但绝非仅这两种），却很难让计算机拥有同样复杂的处理能力。
虽然在智慧上计算机比不了人，但是计算机却拥有比人更强大的存贮和计算能力。
企业软件不只是档案库，记完就了事，它需要分析状况，并做出一些简单的判断，尽管不能代替人，却可以给出一些有效的指导，甚至有时候给出一些指定的逻辑，让它自己完成某部分非常规则的判断，吃饭和打架显然是更复杂的逻辑判断，企业软件只能给出近似的模拟。所以就需要简化世界模型，让软件变得更“专”。这就说明吃饭的动作在某种意义上不至于对打架的行为产生影响（虽然实际上吃得饱打起来更有利，但假设您并不需要分析这一状况），在这种互不干涉的情况下就需要忽略细节问题，把握主要问题。
而对于那些总是要求在项目结束后自己可随意亲自定义软件（比如加个属性，整个查询什么的）的需求，我们一般都持否定意见。尽管不太恰当，但我认为这里面很好地应用了热力学第二定律。
"只能说按照特定的需求，特定的环境来判断。举个例子，人是实体，吃饭在某个场景中是他的行为。而在另外个场景中，打架是，而吃饭不是。我理解的就是这样，不知道其他人的看法是怎么样？ "
这话不假,但是有误导性。
一个更现实一点的问题是,如果在设计前期,设计"人员"这类的时候,是否应该将吃饭加入到其行为之中?可能同一个系统有些场景需要用到吃饭,有些场景需要用到打架,但你能因为部分不需要用到吃饭的场景而将"吃饭"排除在外？或者作两个人员类，一个吃饭一个打架？我的意思是先将所有可能的动作包装在一起，如若有问题，后来再重构。
看帖子的时间，真是有意思。07年发的帖子，09年各位来回复，现在2010年，我又看到我的帖子了。真有意思。
很久没看java了，对实体的概念更加模糊了。呵呵。
[该贴被free49498445于2010-10-11 19:08修改过]
呵呵，多见了，如那篇“JAVA真没前途”的帖子，JAVA一天不灭，回贴的话年年都有。
既然有人回复了，也就证明已经更多人关注这项技术。而且本来就是比较前卫的技术，只是中国更新得比较慢而已（有多少人关注国外论坛？主动点去吧）。
仍然不懂的，大可愉快参与o(∩_∩)o
[该贴被SpeedVan于2010-10-15 11:36修改过]