我也说说我对大家发表的讨论的一些看法吧,我觉得大家说的都挺有道理,至少都能自圆其说。
这里我也想从我的理解总结大家说到得一些重要的观点,并发表一些自己的看法:

jdon007:业务规则表达进入场景的前置条件及对角色交互的约束。场景体现的业务规则,并非角色行为本身,而是约束角色行为;模型行为或属性,是不依赖于场景的实体抽象;碰巧在图书馆领域中,图书馆似乎都是本色出演而已。tangxuehua对此话的理解:前面的都正确,但最后一句现在似乎有不同的理解了,请看我在后面几点中的评论。

SpeedVan:图书馆理解为借出者角色,即便这个角色总是由图书馆扮演;当一个角色总是由同一个实体扮演,那真的有必要吗?会不会显得很累赘?tangxuehua对这个问题的思考:何时才真的需要用角色的概念去理解场景参与者?场景参与者真的一定是角色吗?如果一个对象扮演角色后状态或行为没有发生任何变化,那此角色还有意义吗,因为只是名称叫法不同而已?从而我想到的规律是:我们是否可以理解为:如果角色会给对象赋予新的属性或行为,则有必要引入角色,否则只需要将原始对象看成是一个角色即可,也不需要引入类似于借出者这样的角色,因为借出者角色总是由图书馆对象扮演;另外,我也认为对象在场景中所具有的额外的属性或行为是属于对象所扮演的角色的;我觉得角色的本质是一种对场景参与者的一个抽象的描述,其本质也是一种泛化,和类的作用类似,类的功能是对对象进行抽象和泛化,而角色是对场景参与者进行抽象和泛化。比如取款人角色是对一种在取款场景中从银行中取钱的那些人的一个统称。

jdon007:图书卡是借书工具,自动记录(或辅助记录)借阅史,其原始的形式是笔和纸。卡可以没有任何用户信息,卡不是用户的映射。tangxuehua对此话的理解:结合SpeedVan的理解,我的看法如下:除了“其原始的形式是笔和纸”这一句之外,我都没有异议,卡不代表用户,卡的本质是卡号。但可以通过卡再加上某种关联关系找到一个使用该卡的人,这种关联关系可以不放在卡上,可以放在一个第三方的地方,实际上这我们的关系数据库中的多对多的时候,关系表是独立的一张表的这个概念类似;卡和用卡人在不同的时候表现出来也是多对多,一张卡可能在10年里被多个人使用过,1个人在10年里也可能使用多张卡。我觉得卡只需要一个卡号即可,并且仅有一个卡号就足以;卡就是卡,卡不代表任何人或使用者;卡只是一样被卡使用者使用的具有唯一标识的东西而已;之所以说它具有唯一标识是因为卡中包含的卡号对于发卡方来说是唯一的;在我看来银行卡、理发卡是一个性质的,都只包含了一个卡号而已,不包含任何持卡人信息。只不过银行卡比理发卡更注重安全,如必须实名制,必须用卡时做身份验证之类的,而理发卡则不用做这些复杂的但却不是领域相关的事情,这些仅是在应用层考虑的事情;持卡人信息是一种关联信息,表示这个卡当前正在被谁用,而这种关系是弱化的,即卡与某个使用卡的人的关联关系可以随时被修改。举个例子,图书卡的使用者原来是张三,后来换成李四了;综上,我觉得领域中出现的应该是卡号,而不是卡或用户映射之类的概念;

SpeedVan:关于jdon007说的第一点,我对“卡,其原始的形式是笔和纸”这样的观点是严重不同意的,也就是根本分歧点。现实中,卡并不用作记录历史记录,它只记录一个卡号,该卡能借书,是因为授权(间接授权,卡指定一个授权的人)。若果把卡作为原始的形式,则此卡非彼卡了。其实很好理解,卡丢了我的信息还有没有?卡是指定我,还是代表我?当然每个人的认识都于自身认识相关,到底卡指人,还是卡代表人,看着领域办吧。tangxuehua的理解:我的看法完全与你一致;

jonathanks:是角色把行为带到了场所,并非场所自己诞生出行为,场所是因为角色的行为而改变了相应的场景。不理解把行为加入到场所的做法,行为应该跟着角色走。tangxuehua对此话的理解:首先我想你说的场所就是PPT中的Place;我现在觉得如果我们把场所理解为是一个地点时,那它是不可能有行为的;但是如果把场所理解为是一个场景参与者时,那它就有行为了,但是此时的场所其实已经被拟角色化了。比如你跑到银行去取款,此时银行是个地点,它没有行为,有行为的是银行操作人员角色(如出纳)和取款人角色;但是如果你在ATM机上取款,我们会认为取款人角色在和银行打交道,此时我们其实已经无形之中把银行看成是一个取款活动的参与者了,而不是一个地点;此时的银行就应该有类似出纳角色的行为了;因此,我觉得对于人跑到图书馆借书的例子而言,如果借书的过程是有图书馆工作人员参与的,类似于银行的出纳人,那么我会把图书馆简单的理解为一个地点,他没有借出书的行为;如果借书的过程完全是类似于ATM机那样是全自动的,那么我会把图书馆拟角色化,把它理解为是有行为的。

uda1341:可以描述清楚的只有事实。完全认同,那么我们在设计模型时为什么仅仅让我们的模型去描述事实呢?这样不就没有任何歧义了吗?沟通也会毫不费力。但是我们为什么还要去搞什么角色,抽象呢?我想是因为要重用,要可扩展,要抓住事实的本质规律之类的考虑吧,这样才能让我们的软件尽量可以在更多的场合都是用。因为实际上事实是大量重复的,比如流程性的东西,这个世界每天都在发生重复的流程性的东西,如果我们不对这些流程加以抽象、建模,那么我们的软件中的对象也将大量重复,那几乎是无法想象的。

flyingrobot:角色是相对于“关系”或“过程”而言的(关系和过程在时空背景上是可以统一的,但不妨简单地理解为角色出现的两种基本情形)。“扮演”这个词,很好地揭示了“角色”的实质。我没看到引文中说的例子,但从这里字面透露的意思看,“源帐号”和“目标帐号”,是转账过程中的角色,这是非常典型的“角色”例子。至于“卡”是否要分为借和还的角色,取决于你在“借/还”两个过程中是否将它作为参与者——简单的模式,卡就是借/还者,那么,它就同时是一个账户。理解的要点是,同一个对象(例如卡,账户,姑且叫对象吧)在不同的关系或过程中,可以扮演不同的角色。再者,卡与人之间不是映射关系,而是“使用/拥有”关系。复杂一点的设计,例如,也可以允许“多-多”关系,以及变更。tangxuehua对此话的理解:我完全同意你说的观点。1)你能详细说明一下为什么说扮演一词很好的揭示了角色的实质吗?角色的实质是什么?2)我的理解:是否要把对象看成是某个活动的角色关键是看我们是否把它看成是活动的参与者,一个对象在不同的场景中有时可能是参与者,有时则不是。就像我上面说的银行以及图书馆的例子;

终于也过瘾的发表了一些我的看法。姑且不论我的看法是否正确,至少是思考过后的产物,总有点价值吧,呵呵。我慢慢发现我进步了,不是技术上的,而是开始会学习和总结别人的优秀言论并在此之上慢慢思考直至让自己慢慢吸收从而让自己逐渐成长。感谢大家的精彩讨论!

[该贴被tangxuehua于2011-07-14 01:13修改过]

图书馆和图书卡都是模型,在场景中发挥了其作用(所谓角色扮演),我的意思是这些基础能力是领域赋予它们的,而不是场景赋予它们的。

场景赋予的能力,才需要构建新的角色类去表达,否则只需要让对象名包含角色的含义即可,表示其在场景中发挥了怎么样的作用(扮演了怎么样的角色)。

图书馆的例子。
Card borrower = new card(); // 你可以通过名字,而不是新建一个角色类,让模型去扮演。
Libarary lender = new Libaray(); // 同样你可以通过名字,而不是新建一个角色类,让模型去扮演。

相似的例子,如银行转帐的例子。
Account source = new Accout(); // 你可以通过名字,而不是新建一个角色类,让模型去扮演。
Accout sink = new Accout(); // 同样你可以通过名字,而不是新建一个角色类,让模型去扮演。

总之,角色这个说法,很容易让我们忘记其本来的含义:发挥作用;角色类的泛滥,就是过分形式化的表现。只要我们能清晰地表达模型在场景发挥了怎样的作用,表达方式越简洁越好。

2011年07月14日 11:39 "@jdon007"的内容
场景赋予的能力,才需要构建新的角色类去表达,否则只需要让对象名包含角色的含义即可,表示其在场景中发挥了怎么样的作用(扮演了怎么样的角色)。 ...

恩,同意。看来问题的关键还是在于如何辨别对象的职责是领域赋予的还是场景赋予的。

关于角色,jdon007说得很不错。但我个人对于一些“本色演出”的,是当作场景元素的,相当于NPC存在。当我把NPC也归到场景中,那么问题也更简单了,即不把它当做“演员”。因为场景都在领域中发生,所有场景都带有领域这一前缀,于是在图书馆领域,借书场景,不确定要素只有人和书,图书馆(借出者)存在成为必然,也就是借书场景概念本身就带有图书馆。举个例子,想着有这么一个场景:A君拿着木棒,在打地上的角色。从这句话看出“A君打人”已成为场景,谁进去被打而已。场景犹如一个事件发生的模板,它已经包含已可确定的东西,等待确定不能确定的东西,满足事件(场景)要求,进而发生。

额外地:

关于“转账”这一例子,过去总是和我原有思维冲突。经过深思之后得以下判断。

其实现在谈的“转账”过程,或者说“转账”系统,有一个隐含意思,就是活动对象是“账号”,并不是人。也就是说这样的系统,只能满足钱从“账号”到“账号”,而不是钱从“人”到“人”了,所以谈“转账”的时候,就与人无关,其领域,是一个与“人”没关的世界。也就是说连“人持有卡”的概念也不应该存在。

“转账”一词,只谈账,不谈人。而这个跟图书馆的区别在于:多个账号不是指向一个人,而是指向“各自”的一份信息。1人拥有多个银行账号,银行账号中拥有人的信息,但这个信息内容不具有唯一性,各账号各自一份,也就是说,这个信息同值对象一样,没有唯一标识,也就是说,它们是独立存在的。所以说“转账”,从根本上说不存在人,更不应该说是代表人。

其实引入“存款”更能发现“转账”和“借书”是很不相同的,如这个账号有着第三方和临时存放的味道,存款才跟人相关,转账却无关。

而(我去过的)图书馆不一样,都是一个人就一张卡,必须指定一个人(jdon007指的可能是我的例外,不过这种例外还真没见过)。尽管在系统看来,它是一份信息,但请认清楚这份信息与上面的区别:这份信息是人的映射,是具有唯一性的,而前面例子的,就真是一份实实在在的信息,并不是作为人的映射。(其实图书馆都有个规矩:一个人只能借多少本。若果可以多张卡,则这个规矩就形同虚设了)。


2011年07月14日 16:41 "@tangxuehua"的内容
tangxuehua对此话的理解:我完全同意你说的观点。1)你能详细说明一下为什么说扮演一词很好的揭示了角色的实质吗?角色的实质是什么?2)我的理解:是否要把对象看成是某个活动的角色关键是看我们是否把它看成是活动的参与者,一个对象在不同的场 ...

看了一下你前面回帖提到的文章。很好的分享!大多数的理解都是比较一致的。

回应你的提问:
“角色”就相当于谓词的变项。而任何实体要参与到特定关系或过程(活动)中,必定扮演某种特定的角色。角色是构成关系或活动的要素,该关系或活动决定了参与者的特征、作用或相互关系等等,扮演者必须符合其条件。如果要将“角色”实体化,这个实体的属性就是上述特征、作用、相互关系等。“扮演”就是“角色”与“充当角色的实体”之间的关系(谓词)。例如,对于一个婚姻关系,可以有:扮演(张三,丈夫);扮演(李四,妻子)。对于一个抓小偷活动,可以有:扮演(张三,小偷);扮演(李四,警察)

(看来论坛功能似乎有点问题?@引用者的名字显示的不对啊,我手工改了)
[该贴被flyingrobot于2011-07-14 17:09修改过]

现在基本明白扮演一词的含义了.
1)对于一个活动或过程的参与者,我能很形象的理解为角色,如警察抓小偷场景中的:警察与小偷都是两个角色,都由人扮演;
2)对于一种关系的构成者,我也能很好的理解为角色,如夫妻关系中的丈夫和妻子,他们都由人扮演;

但是对象除了可以构成关系和参与活动外,可能还会有其他情况,比如借书场景中,图书馆只是个地点;或者在人民大会堂举行的中国达人秀节目,人民大会堂也只是个地点而已;按照flyingrobot的说法,因为场景中的任何对象都应该以某种角色来理解,那么图书馆这个对象是否应该理解为"借书发生地"角色?人民大会堂是否该理解为"表演舞台"角色?

2011年07月14日 20:58 "@tangxuehua"的内容
那么图书馆这个对象是否应该理解为"借书发生地"角色?人民大会堂是否该理解为"表演舞台"角色? ...

这么想吧:“跳舞”是场景,还是“在舞台上跳舞”是场景?还是两者都是?

场景就是:中国达人在中国人民大会堂秀,它包含:中国大人、观众、评为、现场工作人员、人民大会堂、秀;其中中国达人、观众、评为、现场工作人员都是角色,人民大会堂是一个表演舞台,而秀则是活动,如果你吧秀理解为场景,那它只是一个狭义的场景,说狭义是因为秀不能说明其他的很多问题,完整的场景就是:中国达人在中国人民大会堂秀;
所以一个完整一点的抽象一点的场景表示就是:各种对象扮演各种角色在某个地方进行活动,当然有时我们会忽略地点,那就是各种对象扮演各种角色进行活动,而这也就是四色原型的核心,其实我们小学语文课本中早已给我们上过这个思想了:人物、地点、事件,呵呵。

所以,你觉得场景是什么呢?另外再问一句:你们所说的场景仅仅包含领域相关的东西吗?有没有包含事务控制,错误记录,日志处理等领域之外的技术层面的应用层面的东西呢?如果不包含,那么它和DDD中的领域服务有什么本质区别吗?在我看来仅仅多了一个角色的概念而已。
[该贴被tangxuehua于2011-07-15 09:19修改过]

2011年07月15日 09:17 "@tangxuehua"的内容
所以,你觉得场景是什么呢 ...

场景跟场地,还真的是有区别。场地只考虑地点,而场景,除了场地外,还考虑情景。把“各种对象扮演各种角色在某个地方进行活动”后面改为“进行某种活动”。Context不同与Place,建立场景主要是组织情景,而不是去布置场地。所以为什么我们在谈论场景时,都会取谓词来描述。

纯领域描述不包含其他东西,它关键是建立领域模型,而技术应该围绕模型来转。可以通过框架控制,或者通过自动注入或切入技术,如IOC、AOP等。与领域服务最本质的区别:在原DDD上,逻辑是尽量放到模型中(理解聚合根与实体的区别),而放到哪都不适合的就放到服务中,可见原DDD跟DCI的切分方式有很大不同,但某些概念上是相互促进的。

2011年07月15日 11:49 "@tangxuehua"的内容
按照flyingrobot的说法,因为场景中的任何对象都应该以某种角色来理解,那么图书馆这个对象是否应该理解为"借书发生地"角色?人民大会堂是否该理解为"表演舞台"角色? ...

我在前面讨论中,都是使用关系或过程/活动,而避免使用“场景”,因为它们更明确、容易确定……我不会说任何对象都应该以某种角色来理解,特别不会针对场景说——最多,说可以以某种角色来理解。这个必要性,取决于你拿它(这些模型)做什么,怎么做。

回到“角色”上,还是要强调,最基本的理解,它是关系的构成。即使在过程中,它们实质上也会归结为对象之间的相互作用关系。

另外一点,就是动态性。这也是许多时候我们将角色凸显出来,甚至实体化的缘由之一。比如:打篮球。进攻者与防守者、传球者、接球者、断球者……一名球员会扮演多种角色并不断转换。

补充:关于场地作为角色。任何实体都可以作为角色。作为特定角色时,你是将它当作一个整体来看的。比如借书例子中,最简单的方式,当然就是把借与还,看作“图书馆”和“读者”之间的过程(联系),所以,在借阅过程或借阅关系中的基本角色是图书馆与读者。更复杂一点,可能变成(图书室,读者),而图书馆此时就成为图书室的拥有者角色。只要抓住了关系这个实质,神马都是浮云。
[该贴被flyingrobot于2011-07-15 13:12修改过]

“关系”也可以归结为“场景”或“上下文”,英文Context。

2011年07月15日 14:39 "@banq"的内容
“关系”也可以归结为“场景”或“上下文”,英文Context。 ...

这个说法,似乎有点笼统?以我所知的“场景”一般是对应scenarios(Eric DDD一书中译也是这样的),“关系”通常是relations或relationships,前者就是“关系数据模型”那个关系,而后者是E-R模型那个关系,为了区别,某些学者建议后者用“联系”。contexts在语言学等领域的传统术语是“语境”,程序设计领域流行的是“上下文”,DDD一书中,“上下文”是重要的基本概念,但不是“场景”,且“场景”(scenarios)并没有列入其特别定义的概念表。我看得不多,不知前面各位讨论的“场景”是什么?

2011年07月15日 16:39 "@flyingrobot"的内容
DDD一书中,“上下文”是重要的基本概念,但不是“场景”,且“场景”(scenarios)并没有列入其特别定义的概念表 ...

这是我的理解,所以,我这里突出英文Context,上下文,从中文意思我认为等同于场景,Context还有一个中文翻译:前后关系。

我以前说过:任何真理都是有前提的,都有其语境,所以,我特反对教育孩子名人名言。

任何事情都有其前因后果,没有孤立存在的事物,只有我们进行深入分析时,才划定边界,进行相对独立分析。

我一直强调无为,无为有一种情况:就是让环境影响处于这个环境中的事物,很显然这里面存在通俗上讲的“关系”,用context可能更精确些,这种关系有紧 有松,各种各样,我不反对用关系数据库来表达,可惜关系数据库或E-R虽然名称中有“关系”词语,实际其对关系表达就是两种,要么外键要么不是。

虽然是几年前的贴子,但是我还是忍不住发表一下观点,以便别人可以看到;
还是以借书这个例子,看起来图书馆只有一个,但实际上借书这个行为可以在不同的地点发生,一个完整的系统分析就应该有一个图书借阅地的实体(P),扮演图书馆的角色(R);如果借书要限定永远只在一个地方,那么这个借书场景也不是一定要记录借书地点是图书馆,如果要记录,那么可以把图书馆当作书本的DESC。