6.0的序列号还可以用到08年。下过来用了用，速度果然如承诺的一样变快了，不过很快发现了一个小bug——web.xml的filter-mapping使用servlet-name有问题，只好该成url-partten。
还有一个问题不知道是不是bug——偶关掉idea，再启就怎么也启不起来。只好reset我的电脑。
—————————————————————————————————————————————————————
公司的这个项目很快就开发玩了（web），下一步老板调我去rcp那个项目开发。于是看了点rcp的资料，说实话，我对rcp并不看好，对swt并不看好，对eclipse也不看好。
相反的我对swing很感兴趣。
现在我正在做的这个项目，做的让我很郁闷。一个企业的erp系统，客户要求用b/s开发。其实我觉得企业erp更适合用c/s或者rich client技术开发，信息发布平台或者主页或者bbs等更适合用b/s开发；前者不在乎部署成本，在乎的是方便强大；后者不在乎什么强大，在乎的是速度和信息。
——————————————————————————————————————————————————————
看了点banq的文章，谈了rich model，正好javaeye这边对什么贫血充血讨论的不亦乐乎。偶觉得banq那边应该更有道理一点，不过对争鸣没什么兴趣，于是懒的转来论坛。
1，DDD（DOMAIN DRIVER DESIGN）告诉我们如何设计业务层。
软件流程：分析、设计、编码、测试、部署。过去分析和设计是分开的。eric告诉我们：最好不要分开，你的架构师最好懂得业务，能灵活的依据现实的情况选择/设计框架。
软件模型和领域模型是一个东西。
（ps：要求太高鸟，偶觉得还是两者分开比较现实。解决问题的关键在于多沟通，最好双方合作建模，单一模型。）
2，eric将业务层分为两层：应用层和领域层
应用层：定义软件可以完成的工作，并且指挥具有丰富含义的领域对象来解决问题，保持精练；不包括业务规则或知识，无业务情况的状态
领域层：负责表示业务概念、业务状态的信息和业务规则，是业务软件核心。
（偶的理解是应用层负责和ui和db交互；其他的交给领域层来干。
带来的问题是：如何建模，区分模型/对象，区分责任、定义协作关系。毫无疑问，这些问题如果解决了，软件的可扩展性，业务的可扩展性将变得非常简单。于是问题回到的起点：如何建模!!!!!!!!!!!!）
//下面介绍了MDD的办法
首先，因为四色原型（按重要性从高到低排列）
1，moment-interval
2，role
3，party, place or thing
4，catalog-entry-like description
mi模型，我觉得是表述的一系列事情。
role模型，是一系列事情中的事物。 （能动的？）
ppt模型，事物。业务对象，被动的？ （被动的？）
description模型，事物的归类。 （描述性的？）
（偶觉得这个模型提供了一个分解业务的办法。）
//下面是banq的发挥？还是eric的意思？
传统模型分为两种：实体（Entity）和值对象（Value Object），现在服务（Service）成为第三种模型元素。
实体（Entity）定义：通过一系列连续性（continuity）和标识（identity ID）来定义；个人认为它和分析领域的四色原型中的PPT原型非常类似，可以看成是PPT原型延续。
实体必须拥有自己的唯一ID，主键，如果没有一个ID标识，为每个实例加上一个具有唯一性ID，可能是内部使用。
值对象（Value Object）：如果一个对象代表了领域的某种描述性特征，且没有概念性的标识。个人认为它是四色原型中Description原型延续。如果我们只关心模型中一个元素的属性，那么把这个元素划为值对象。值对象是不可变的，不要给它任何标识，避免实体的维护性，降低设计复杂性。我们不关心值对象是哪个实例。
Eric认为：服务Service是描述领域概念最自然的方式，是四色原型的MI原型的延续，优秀服务3个特征：
1.与领域概念相关的操作行为、但不是实体和值对象中固有的部分。
2.接口根据领域模型中其他元素定义
3.操作是无状态的。
//banq这里的表述没有问题，我的理解是：他按照四色模型设计了业务层责任。不过我觉得他最后得到的模型和他上面所说的两层责任分配很矛盾。
我查看了jivejdon他提的代码，事实上责任并没有按照他说的那样划分（其实我觉得robin在rich domel里面的代码很符合eric对业务层责任分配的描述）
问了banq，他告诉我service是一个分析模型（我倒!!!!分析模型和软件模型又被分裂了）
￥%……&*（）我觉得eric的理论有一定道理。robin给的是然，eric给的是所以然。而所谓的贫血充血其实并不那么重要。