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給的是所以然。而所謂的貧血充血其實并不那么重要。