可以这样理解,借书者是客户,图书馆是资源,提供服务。而卡是一种对客户的借书的行为的控制。现实中应该是这样,一个人想去借书,必须先去图书管登记,而卡则是一种形式。有些人可以一个月可以借3本书,而有些人可以借6本书,有些人可以借英文书,而有些人则只能借中文书。所以卡有不同类型的卡,不同级别的卡,收费或者免费的卡。这时候的卡隐含着权限的意思。它就犹如角色,或者部门一样,你得在这个角色,或者部门才会有这种权限。卡只是人的一种映射,就如SpeedVan说的。其最终目的还是对客户的权限的审核。即可以借什么样的书,借多少书,借多少时间等等。

2011年01月31日 06:28 "OweJDao"的内容
MI就是DCI的场景 ...

准确说MI是交互(I),而Context是角色和交互外面的一层膜。
[该贴被SpeedVan于2011-01-31 09:51修改过]

嗯,freeboy能了解我的理解,也是我为啥理解为登录(认证)。其实可以这样去解析,若果没有卡,直接人去借书不行吗?其实是可以的,但是必须每次都要审查一样确认身份。卡只是一种方便手段,就如DNA一样,回想一下没有卡的年代,呵呵。无论用DNA的图书馆,还是卡的图书馆,我的基本模型都不用改变。其实我为什么认为卡是人的一种映射,你把Card这个名字改为Borrower就能明白了,因为卡(你理解的卡)和人的共通点在“借方”这个角色。而你理解的卡像人一样,而我不这么认为,多人使用的系统,肯定会存在身份确认,到底在那一步呢?就在刷卡那一下,系统知道了谁在借书,或者书被谁借了。

再拿个例子,登录式的留言版(假设帐号和留言信息是一同输入的,留言后登出),留言版只有留言这一动作,跟图书馆只有借书这个动作一样,留言版核心是“言”,图书馆是“书”,那么登录就如刷卡了。
[该贴被SpeedVan于2011-01-31 10:24修改过]

1、首先我是根据我在学校多年的借书经验来思考,不是DDD的术语,我觉得这些术语在概念上一定程度是具有入侵性的,甚至妨碍我进行独立的思考。唯一限制我思考能力是我对自然和现实的认知程度。我学了四色原型,随后就开始淡忘了四色原型,学了DCI,随后也开始有点淡忘了DCI,取其意忘其形,似乎一直是处于“得意忘形”的状态,年纪大了,记忆力开始退化,开始有点健忘,很多时候能说出其背后的意义,却想不起来最初的名字。

2、书就是书,为何要加一个书是实体或书是聚合根这些多余的概念?如果这套概念有利于统一管理领域模型,并驱动技术实现,那么这也是之后的该做事情,不要用这些概念来思考,领域该是怎样的,就是怎样的,领域之多之丰富,任何一套理论意图驾驭在现实之上或自然之上,都会捉襟见肘,顾此失彼。“理论是灰色的,而生活之树常青”。

3、卡的权限是借阅规章制度规定的,持卡资格与卡本身的权限或类型,是相对独立的。别的同学可以使用我的卡去借书,卡是借书工具,尽管此卡已经注册了我的名字,但是可以更改卡的拥有人,卡的借书功能依旧。

4、信箱是信箱,收信人是收人,即便收信人已经搬家或者去世,信箱依旧存在;即便学生已经毕业,不再持有该学校借书卡的资格,借书卡的权限、借书卡的借书功能,依旧存在;即便员工已经辞职,这个公司规定的各个部门的不同级别的职位访问各种资源的权限依旧存在。即便你做了皇帝,不要以为你不在了,皇帝这一职位或角色就不在了,青山不改,绿水长流,江山代有新人出,一代新人换旧人而已。

5、也许这座图书馆从未有人来借过书,也就是不管用户是否存在,但是“借阅规则”依然存在,其中规定包含了对各种类型卡的权限的的规定。用户持卡,只是“拥有”并可以“使用”这张卡。对用户是否有资格拥有某类型的卡,则是对用户进入领域资格的审查。

家里有两个孩子,孩子们对妈妈说,妈妈我要喝水。
妈妈说好,分别给孩子倒了一杯水。
学校里有两个学生,学生们对老师说,老师我借书,
老师说好,分别给孩子一张借书卡。

孩子 = 学生 = 用户
妈妈 = 老师 = 程序员
水 = 书 = 用户需求 = [用户对领域的主观认识,领域模型之一]
杯子 = 借书卡 = 领域模型之二

领域模型要捕捉和包容的是用户需求,而不是用户本身。用户需求是用户对客观领域的素描,所以也是领域中的模型,我们(程序员)可以借鉴其宝贵的经验和认知,将水或书作为领域模型之一。

为了身体健康,妈妈对两个孩子说,以后喝水只能用自己的杯子,不能用别人的杯子。
为了便于管理,老师对两个学生说,以后借书只能用自己的借书卡,不能用别人的借书卡。

这样每个孩子只能使用自己的杯子,杯子有了特定的使用者;每个学生只能使用自己的借书卡,借书卡有了特定的使用者。

过年到了,两个孩子对妈妈说,妈妈,我们长大了,想喝酒,妈妈说好,使用你们的杯子盛酒吧。
可是拿杯子的时候,不小心把杯子摔坏了,于是妈妈给孩子们拿出新的杯子,这种杯子的类型可能与之前完全不同。

信息电子化时代到了,两个学生对老师说,老师纸质书太重了,想看电子书,老师说好,使用你们的借书卡借电子书吧。
可是借书的时候,找不到借书卡了,于是老师给了学生们两张新的借书卡,这种借书卡的形式可能与之前完全不同(或者采用最原始的笔和纸的记录方式)。

多年之后。。。。。。。

两个孩子去外地读书了,两个杯子,别的人还可以用来喝水,但妈妈可将其珍藏起来。
两个学生毕业去工作了,两张借书卡,别的学生还可使用,只不过老师将两张卡注销了。

用户有了新的需求:酒和电子书, 这是对领域新生事物的素描,是新的领域模型,我们为用户增添新的模型就可以了(对扩展开放)。领域中的事物更新换代,杯子变了,借书卡的形式也变了,但盛水和借书的功能是不变的(对修改封闭),我们用新的模型替换旧的模型就可以了

与现实稍微不同的是,在代码中,我们可能需要事先预测未来可能的变化,在一些地方应用设计模式去包容变化,将来改动代码的地方降低到最少。

不过,这里包容“借电子书的需求”,比较简单,不需要设计模式,只要在BookDetail中增加一个字段,区分“纸质书”与“电子书”就可以了。

无墨之韵,方能韵味无穷;无为之治,方能应需而变。领域模型只有将用户置于模型之外,方能包容用户参差多态之需求。建立领域模型,是“有之以为利”,包容用户需求,是“无之以为用”呀。设计模式的精髓其实亦然。

大概可以分为三种观点:
1)用户在系统中存在镜像,是重要的领域模型,甚至是核心的领域模型(从张逸先生的设计UML图可以看出, 各位基本上与其一致)。
2)用户在系统中存在镜像,但不是(在此案例中)不是核心领域模型。(banq)。
3)我的观点是用户应在领域之外,在用户进入领域之中前,并没有用户。用户进入领域后激活了(担当或使用)某些角色,参与完成了某些活动。

完成活动的技术实现方式可以有多种,直接或显式完成,比如我写的代码;或者间接或隐式完成,比如通过事件驱动的风格;也可以采用其他风格,比如直接调用与基于事件集成的风格互补的方式。我在Jdon看到的对领域事件的讨论,感觉与其说是领域事件,还不如说是持久化事件。领域事件也许可以地分解为或对应为持久化事件,但多少有点技术驱动,而不是领域驱动。

我在学校接触过两种借书方式,一种是刷卡的,学校图书官使用的方式,可借的书较丰富,超期有罚款;一种是人工记录的(没有借书卡),学院藏书室使用的方式,可借的书较单一,没有时间限制,没有罚款。两者的借阅规则不同,可采用策略模式进行设计,但这里不说这个,说的是卡是什么?

从我的代码可以看出,卡上面记录了借书人、借书时间、归还时间、所借何书、借书数目。实际上,我接触的人工记录的借书方式,就是用白纸黑字来记录。我以为卡就是一种自动记录借书活动的方式,代替了笔和纸。

今天中午去银行取钱,看见一个同事在银行内排队取款,而我在外面的自动取款机取款,我想到了存折和银行卡都是记录取钱和存钱活动的一种实现方式。联想到,电视上看到一些讲述革命年代的电视剧,里头去银行存钱和取钱的方式,不是使用银行卡,使用的也是比较原始的笔和纸的记录方式,至于验证取款资格,可能要通过本人、亲笔信或其他信物等等。只是现在的银行卡通过密码的方式来样验证资格,并将这个资格审查的功能集中在卡上。

对用户进入领域资格的审查可以放在领域之外,也可以放在领域之内,这可能取决于领域安全的重要程度。

图书领域中需不需要一个图书馆管理员,之前有人跟我提过这点,当时我的回答是可以考虑将一部分借阅条款的功能分配给管理员,毕竟管理员是借阅条款的执行人。

但是,现在我觉得可以不需要管理员,但管理员的执行功能需要保留。为什么呢?还是从银行取款这事看,使用卡进行自动取款实际上没有营业员的,使用存折则需要。但两者之间有共同点,自动取款机和营业员都是充当执行银行业务规则的角色。我在代码实现中,将业务规则和业务规则执行人集中在BorrowingTerms,可以考虑将部分功能分配给业务规则执行人,但这里业务规则并不复杂,集中实现感觉也没有什么大问题,就我而言,在代码上感觉更紧凑一些。

商店可以没有销售员,就像自动售货机;银行可以没有业务员,就像自动取款机;图书馆可以没有管理员,如果也有一种自动的装置的话。这些只是形式的变化,他们扮演执行业务规则的角色是一致的。

说远一点,历史虽然是人的活动,但历史规律却又不以人的意志为转移,这多多少少看起来像一个悖论;经济活动也是人的活动,竟然也同样如此,市场经济比计划经济更有效,大概也是人放下了人自以为是的控制;刑事法律似乎为罪犯量身定做的,惩罚罪犯,可惜法律的意志似乎并不在于此,初听可能有点怪,法律惩罚的是犯罪行为,而不是罪犯本身,也就是说惩罚的是行为或具有某种行为的角色,而不是人。

上面涉及的一些解释已经超出我的知识范围,只能作为一种理解的思路,以供参考。你们所说的,我理解。我只是提供了另一种视角来审视领域,试图以更客观的方法去接近领域的真相,如果这么看,似乎有点“无情”,有点令人“悲伤”,人,你在哪里?
[该贴被jdon007于2011-02-09 15:59修改过]

感谢jdon007的祝愿,同时也对各道友送上新年祝福。

以下是三个问题:
一、
回到帖子主体,我觉得banq和jdon007都和我说的不是同一样东西,为了避免出现误解,我先说出可能有误解的地方。

现实生活中的用户(或者应用层的用户),我称为驱动者(应用驱动者,执行者也可,应用执行者也可)。而模型中的实体,我称为参与者(业务参与者,或者场景参与者)。

我觉得,banq和jdon007一直说不要加入驱动者,而我说的是参与者,参与者可以扩展到作为任何聚合根的称谓。因为我认为的参与者是在领域内的,所以排除人就奇怪了。有待banq和jdon007验证是否是这种情况。


二、
另外一个问题,Context场景到底是在领域内,还是领域外的。我一直是认为是领域内的,场景是领域的划分,根据的是DDD中所指的上下文。banq认为是领域外,到底是如何理解呢?


三、
最后一个问题,卡还是人?在我的领域模型中是没有卡的,只有人,卡放到应用层作为认证的。看到“内存我在借书”=“内存中的我和书以相关身份进入借书场景”。现实中的我与内存中的我,不是同一个,所以说内存中的Reader("我")是现实中的我的镜像,映射。所以也由此引出jdon007的模型中描述的Card,是用户的映射。卡借书,犹如杯子喝水一样奇怪,这样的模型,自然?为啥DDD中用Customer而不用其工具呢?Customer就是行为执行者,干嘛还要找个工具映射到Customer上呢?执行者拥有行为的执行权,工具拥有的是行为的效果(策略模式)。

而且在图书馆系统模型中,不应出现卡的,原因是,其是一个身份认证工具,并非执行借书的,和身份证一样,身份证对的是国家,借书卡对的是图书馆。

还有该注意的一点是,无论是“你”,还是“我”,还是B君C君,只要用的是A君的卡,那么在图书馆看来,使用者是A君,不会去理会真实使用者身份的。相当于一具受A君控制的行尸走肉——系统认为使用者就是A君,没有其他可能。
[该贴被SpeedVan于2011-02-01 13:33修改过]

在这里先祝各位道友新年快乐,万事如意!

我们首先确定领域范围:图书馆(不是学校)。
场景就是借书还书这个动作过程。

从jdon007的代码来看,好像这个图书馆的借书还书过程是个无人监守的场景。
也就是说是不需要图书管理员的参与。

接下来陈述下我个人的观点。

我比较赞同SpeedVan的大部分观点。
重点是把用户看成是“图书馆”这个领域外的实体还是“图书馆”这个领域内的角色(Role)。

真实世界场景可以描述成:用户(学生或者老师)用借书卡在图书馆借还书。
转化成软件系统的领域中的场景后应该变成:登录用户(Reader)借还书。(现实世界的借书卡可以理解成这里的登录用户)
由此可见:
1.领域中的用户就是登录用户,是一种依赖领域的角色。是这个角色可以在图书馆中借书还书。
2.借书卡是现实世界中领域外用户(学生或者老师)用来登录图书管理系统并借还书的工具。虽然是领域中的Thing,但是由于有登录用户存在,登录用户(Reader)和借书卡的信息一样,所以借书卡可以从领域建模中去掉。
3.图书馆就是聚合根,借书条款(值对象)和属于图书馆的书(值对象)都是它的属性

接下来的动作就是:
登录用户通过触发借书还书领域事件来驱使图书馆聚合根来执行借书还书这个动作(其实就是改变图书的状态)。
也就是说借还书这个操作是图书馆这个聚合根的行为,没有必要单独成为一个四色原型中MI。

欢迎讨论。

[该贴被liam于2011-02-01 12:58修改过]
[该贴被liam于2011-02-01 13:19修改过]

其实主要是对卡的理解,很多人认为卡中有很多信息,什么个人信息,什么余额,什么记录都在里面。其实不是的,为什么?要是我的卡丢了,我在图书馆的信息就永远消失了?明显不是,用户信息都在系统的某个容器当中(结构体,对象,或者数据库等),而并非在卡中,卡内只存在一个卡号而已。而其与领域实体中的某个用户的唯一标识绑定而已。银行何尝不是这样呢?存折丢了,不等于交易记录消失,它只是一个帐号和一张纸而已,他的交易记录在系统的某个容器当中,而并非在这张纸上。我不打印就没记录?明显不是,可以把这理解为功能需求。

没有系统时代的纸张记录信息,相当与系统内容器记录信息,而并非卡,或存折,卡和存折等都是登录手段,相当与认人和认信物一样。理解这一点的话,应该对各种交互系统都能了解了。

我理解的“卡”是记录活动的一种方式,不妨想象为“纸”。卡是原始的“借条”或“欠条”的进化形式。卡里头存储的信息,我们一般都看不到,所以对其只是凭自己的认知进行判断,各言其是,都有可能出现错误。但是存折我们是看得到的,银行存折上打印的每一行上记录着什么时间,存取了多少钱。

银行系统有各种交易记录的备份,平常的欠条也是一式两份的,一份在用户手中(比如存折或卡等形式),一份在银行手中(比如数据库中的表或财务室的账本等形式)。

不妨想象两个场景:
1)银行被原子弹炸毁了,也就说银行内所有的记录都消失了。那么,每个人在银行内存的的钱,就白白没了吗?我想谁都不会乐意,当然贷款的就开心了。只要我们手上有符合要求的记录,比如卡和存折,记录着银行欠了我们多少钱,相当于民间借钱时打的欠条。我们是可以找银行要回钱的。

2)存折或卡丢了,我们手上的记录丢了。可是欠条一式两份,银行系统上面还有同样的记录,我们通过身份证等证件,可以找回记录,补办卡或存折。人们之所以愿意往银行存钱或者说借钱给银行,这可以说是很重要的原因之一,不像生活中,欠条丢了,打官司都可能要不回钱。

同样,借书也如此,借者(借书人)要记录自己借了多少书,被借者(图书馆)也要记录自己出借了多少书。借书人每次借书都要打借条,卡可以理解为可复用和自动记录的借条,节约了纸张和手写记录的时间。

“借书人”使用“领域”或“借书人”进入“领域”时,参与了“借书活动”,其中,活动规则,活动的各种工具(比如卡和存折)都是“领域”所规定的。“借书人”离开“领域”时,这些规则以及对这些工具的功能都是领域事先决定好的。“借书人”,使用这些工具,遵循领域的活动规则或规律,完成借书的活动过程。无论“借书人”离开“领域”,还是进入“领域”,无论“借书人”是否存在,这些规则、这些工具的功能都是“领域”决定的。

张逸先生把一些业务规则集中或映射于“借书人”身上,认为系统之中存在用户之“镜像”。这样,业务规则变化时,“借书人”的职责可能也要随之变化。而我将“借书人”置于“领域”之外,业务规则发生变化,是领域本身的事情,“领域的变化”与“借书人”可以说是无关的,尽管“借书”时,存在着“借书人”的角色。

借书人使用卡借书,饮水者使用水杯来盛水,至于借书人怎么看书,饮水者怎么喝水,这是他们自己的自由。

领域中只有书和借书卡,只有水和水杯,不同的借书卡借的书数量可能不同,不同的水杯能盛的水也可能不同。卡可以有唯一的使用者(借书人),水杯也可以有唯一的使用者, 使用者是否有资格使用卡或者杯子,都是领域规则所决定的。至于卡的形式,水杯的形式,怎么发展,怎么变化,这也是领域决定的。

领域中如果出现了新生事物,其发展也是自身规律在起作用。使用者可以引导或促进领域的发展,进入领域时要遵循领域的自身规律。

给大家拜个晚年。

我大概看了这个帖子,对于图书借阅这个案例来说,如果凭直觉来说,那么图书应该是聚合根。就象地址在不同场合可能是值对象或实体一样,如果有其他需求重点,那么图书这个聚合根就可能只是一个参与者。

大家对“卡”争执,卡确实类似存折,我发现需求分析如果没有一些模式遵循,大家会争执得“面红耳赤”,所幸是,关于银行系统,Martin Fowler的“分析模式”有关"Inventory 和 Accounting"模式,我认为适用于这里“图书卡”。
关于"Inventory 和 Accounting"模式,如下定义:
1.很多领域,不仅强调记录某个事物的当前值或状态,而且强调记录影像该值的每次事件变化细节。
2.一个银行账目需要记录每一次存款和取款记录,不能只记录当前余额。
3.库存记录要记录每次物品入出库明细。
3.事务:仅仅记录明细还不够,记录它们来自哪里?去了哪里?

参见一个转账模式或称为记账模式的实现贴:
http://www.jdon.com/jivejdon/thread/39859

原理同样适用于图书借阅卡。



[该贴被banq于2011-02-11 19:33修改过]

我可能忽略了一个细节,银行卡与借书卡存储的信息应该是不同的。因为卡里头存储的信息,我们一般都看不到,只能从使用方式来推断。取钱时必须每次刷银行卡(饭卡也是如此),但借书卡只需要刷一次就可以借多本书。

“银行卡”是“欠条”,记录银行欠了我们多少钱,(饭卡也如此);“借书卡”是“借条”,记录我们像图书馆借了多少书。“借条”与“欠条”记录的信息应该是一致的,“借条”放在“借方”手里,“欠条”放在“被借方”手里。

对于“借方”来说,丢了“借条”于自己来说并无利益损失,也就是说“借条”本身可以不包含任何借书记录。师生们手中的图书卡似乎就是如此。但是在“被借方”图书馆里头有每个借方“完整的借书记录”—即“欠条”,“欠条”与“借条”记录的信息本应是一致的,只是因为角度不同(一个从被借方,一个从借方),说法不同而已。

我代码中的卡与师生手中的卡是不同的。

代码中的卡是从“被借方”的角度记录借书活动的一种方法,是“欠条”,师生手中的卡是从“借方”的角度记录借书活动的一种方法,因为丢了借书记录于“借方”并无利益损失,所以师生手中的卡可以不记录借书活动的信息。

“欠条”记录的信息进行持久化,保存在数据库中,相当于把每个师生的“欠条”保管起来。

稍微总结一下,如果“卡”是“借条”,可以不存储借书信息,因为记录丢失于“借方”并无利益损失;如果“卡”是“欠条”,要存储借书信息,因为记录丢失“被借方”将受到利益损失。如果“卡”既可以充当“借条”又可以充当“欠条”,则根据不同阶段分解为前面两种情景。

图书领域模型中的卡本质对应的是“欠条”,现实中借书人手中的卡对应的是“借条”,本来是一一对应的,可是从利益的角度考虑,“借条”可以不记录“借书信息”。


我发现在这个具体的例子我并没有做到完全遵循“无之用”的观点。将“卡”理解为“借条”而不是“欠条”,无意间又将用户包含进来了,尽管它们本来是一一对应的,在代码上也不需要修改。一个这么简单的例子,要贯彻一个观点都不容易。“无”有很多很多含义,这里有“不以人(用户)的意志为转移”之意(即无用户意志,这大概也是“无”的最核心的含义),用户进入领域要遵循其活动规律。

卡的含义,不是这里最核心的矛盾所在,我的观点是“领域独立于用户,不以用户意志为转移,不论用户是否进入领域,是否参与领域的活动”。

2011年02月11日 19:58 "jdon007"的内容
图书领域模型中的卡本质对应的是“欠条”,现实中借书人手中的卡对应的是“借条”,本来是一一对应的,可是从利益的角度考虑,“借条”可以不记录“借书信息” ...

不要纠结于图书卡了,图书卡实际是图书借阅活动的一个结果,也就是活动的结果。这里的“活动”可以表述为四色原型的MI,可以使用领域服务来;“结果”可以落实为存储的数据表数据。

在没有计算机软件系统时,大家就通过一个卡来替代数据表记录,就像财务手工帐簿一样,就像库存系统的入库单和出库单一样,如果你根据入库单和出库单去建模,那就走了数据表建模老路了,要认识到:实际领域中是没有图书卡或入出库单,这些都是人工记录的(起到类似数据表持久保存的作用),在有计算机介入情况下,这些就不需要了,如果你还将他们移植到软件中,就复杂化,我不知用什么来形容。

从四色原型重新看需求,很简单啊,“活动”当然需要角色人参与啊,四色原型四个,我感觉纠结的原因可能还在于数据库背景,在OO思维中,数据表就是对象拉的屎,是结果,不要把结果当原因,否则就容易纠结。

[该贴被banq于2011-02-12 17:28修改过]

2011年02月12日 17:23 "banq"的内容
实际领域中是没有图书卡或入出库单,这些都是人工记录的(起到类似数据表持久保存的作用),在有计算机介入情况下,这些就不需要了, ...

呵呵,纠结,如果是原地踏步,当然没有啥意义。但SpeedVan等人的说法确实促进我进一步的思考。卡的原意是“欠条”,其命名可能需要修改。

张三向别人借一笔钱,借钱的过程中,张三要写一张欠条。欠条记录了这次借钱的一些信息。欠条不不等于张三,尽管欠条是张三写的。

我对卡的含义说了又说,主要是其他几位道友一致认为“卡是用户的映射”,而我认为不是。

图书领域中可以出现“借书人”这一角色,完成写“欠条”的职责,
也可以出现“管理员”这一角色,在参与“借书活动”时执行“借阅规则”。

我的代码中存在这样的问题,即“欠条”可以“自己写”,“借阅规则”可以“自己执行”。而事实,“欠条”写的“职责”应分配给“借书人”,“借阅规则”执行的“职责”应分配给“管理员”。

但是“欠条”(卡)本身是可以替“借书人”完成“写”欠条的过程的,“借阅规则”本身也可以替“管理员”执行。

也就说,这里又可以不需要“借书人”和“管理员”,因为“欠条”(卡)和“借阅规则”身兼二职,既担当“被执行的角色”,又担当“执行的角色”。如果两种角色分开设计,也可以,看情景而定。

现实中“卡”确实替“借书人”完成了“写”欠条的过程,所以在这个具体的案例中不妨把“借书人”这一角色去掉,如果还有其他职责非“借书人”来做不可,那么可以添加“借书人”这一角色,比如卡丢了,执行补办“卡”的职责。

角色不能简单地理解为用户的映射,尽管用户进入领域可以扮演某种角色。张三在公司担任经理,但张三不等于经理。

我并没有排除用户参与活动时扮演的角色,而是在领域中排除“张三”这个具体的人,甚至更多具体的人“李四、王五、赵六”等等。因为“领域的活动规律不以人的意志为转移”,即不以“领域的用户意志为转移”。

2011年02月12日 19:05 "jdon007"的内容
我对卡的含义说了又说,主要是其他几位道友一致认为“卡是用户的映射”,而我认为不是。 ...

讨论这个问题本身,我认为就没有真正理解我上贴对“卡”的定义,首先,“卡”是借阅活动的结果记录,是借阅这个MI(四色原型)拉的一泡屎,根本不就应该是讨论的重点,你们应该都被迷惑了,把结果当本质了。

而“卡是用户的映射”则更加极端,因为卡是借阅活动的静止结果,通常是数据表持久保存结果,所以在“卡”这个表中肯定有用户ID。这实际是在数据库思维上深入表现。

我的意思是,你们讨论方向可能完全走错了,还是清零回头重新再思考一下可能比较好,新年新开始吧。

[该贴被banq于2011-02-13 10:47修改过]