POJO和盡量多的分層，一個類只負責一個功能，這樣子，管它什么框架什么技術(shù)都可以很容易的加個新的包裝

世界是由分子構(gòu)成的，我覺得這也是XP的核心思想。任何復雜的事情（物質(zhì)）都是由最簡單的事情構(gòu)成的，都可以分解為簡單的事情

留個記號先
慢慢看來

@errorter
我們還有C/S應用的部分，也用Ruby，未知的陷阱太多了

@idior
把評價因素改了，長遠的技術(shù)選擇要兼顧，更重要的眼前，呵呵
對于我們的項目而言，有兩個因素：
1.找到一個半成品（開源框架），解決企業(yè)應用中的一些共性問題，加快進度
2.解決B/S與C/S下的圖形繪制問題，目前Java和Dotnet下都在做這方面的工作。且圖形的交互能力，比如拖動圖片上的元素，暫不考慮

當然到最后發(fā)現(xiàn)，真正決定因素：
1.領(lǐng)導/開發(fā)團隊喜歡什么
2.開發(fā)團隊熟悉什么
3.哪種技術(shù)能讓開發(fā)團隊先熟悉起來

我說電驢和BT的時候，其實就是指的整個的系統(tǒng)而不是BT客戶端。BT也算是一種網(wǎng)絡傳輸協(xié)議了吧？

Bitcomet的DHT網(wǎng)絡的引入應該降低了對數(shù)據(jù)中心的依賴；最新的exeem，則干脆不需要數(shù)據(jù)中心了，只是因此速度很慢，所以不再用了。

這是能夠接觸到分布式系統(tǒng)。商業(yè)環(huán)境中沒用過：（

首先感謝canonical對我在上個Blog中提出的問題進行了解說

這次兩段的文字雖然不長，又讓我考慮了老半天，感覺仍有推敲之處：
架構(gòu)的無侵入性，指的是架構(gòu)對于外部接入對象沒有特殊的形式要求，這種無侵入性在事實上“降低”了外部對象與框架本身的依賴關(guān)系－－是“降低”，而不是沒有了。所以從這個角度講，所謂“無侵入性”是根本就不存在的，只能降低“侵入性”，即術(shù)語應該是：“低侵入性”。剛剛搜到一篇文檔也是說這個問題：
http://www.dingl.com/view.shtml?xh=474

再來看可退化性和低侵入性的關(guān)系：
低侵入性，指出了框架在進行擴展時的復雜度降低，對框架的依賴降低，通常就是我們希望的靈活的擴展能力
可退化性，則描述了，可以把增加的這些擴展，很方便的unload
這樣，低侵入性造就了可退化性。

關(guān)于Blog中舉出的RPC層，這個很讓我困惑：因為它看上去，真的是“無侵入性”的。不過后來想想，這個RPC層實際上還是有所依賴的：它必須處理request和response？

@非魚

IE、FF不是：按照分布式系統(tǒng)“每個節(jié)點都有自己的應用服務器和數(shù)據(jù)庫系統(tǒng)”，它們沒有提供服務的功能

eMule和BT則不同，每個節(jié)點都有自己的應用服務器和數(shù)據(jù)庫系統(tǒng)（雖然簡單了點，確實提供了服務；數(shù)據(jù)庫系統(tǒng)可以認為他們使用的是文件型數(shù)據(jù)庫）；

分布式系統(tǒng)未嘗不可以采用emule和bt協(xié)議來進行信息的訪問和復制吧？分布式系統(tǒng)是P2P的一種，或者P2P也是一種分布式系統(tǒng)？

Sybase Replication Server能夠復制的信息對象有哪些？

象電驢、BT這種算是大型分布式系統(tǒng)嗎？

能否試舉一例？比如銀聯(lián)，這個是否算是大型分布式了？

@非魚

好半天才鑿摸過勁兒來，"robber's boat"，強盜的船，原來就是俗語的“上了賊船”啊，貼切

英語也有這種說法？

◎非魚

Enterprise Level的界定就是你上次描述的四條？
『
1. Is it a information collecting/organizing/OLAP system?
2. Are you preparing to use Workflow in the coming system?
3. Do you have any complex business process?
4. Is it a real distributed system?
』
或者說Java比之Dotnet在Enterpise Level方面到底強在哪里？

今天化了一天的時間開評論會；邀請了其中一人是以前的同事，現(xiàn)在在微軟中國。他有著對微軟的強烈認同感、榮譽感，對dotnet的技術(shù)體系也非常熟，一整套分析方法分析下來，大家填寫評估表的時候基本都選擇了Dotnet...

到場的Java開發(fā)者，缺少架構(gòu)師級的能力，所以被比下去了；另外讓我感到困惑的是：似乎使用Java同時做B/S版和C/S程序的公司并不太多？大多使用Java更多聚焦在Web模式的開發(fā)上，做Web開發(fā)使用的技術(shù)又不盡相同，即使選擇了Java，還得在一堆Web框架里進行選擇...

請大家繼續(xù)大力支持！（看完了，給出寶貴意見啊～～）

公司在北京，有能力有時間的朋友想提供技術(shù)支持的話，歡迎與我聯(lián)系 ！

@Fantasysoft

“各種各樣的技術(shù)都有它所適合的應用場景”，說得好！
本文雖然也描述了一個業(yè)務場景，只是之后的評估并沒有直接針對這個場景的關(guān)鍵決定因素來展開－－僅僅是對幾個因素的宏觀對比，這幾個對比的結(jié)果，僅僅讓我親Java而遠Dotnet。

天下熙熙攘攘，皆為利來利往

上述問題可以認為是過高的使用了利益杠桿來調(diào)節(jié)企業(yè)的行為

想要達成的其實是可持續(xù)發(fā)展這樣一個目標

呵呵，當成論壇來發(fā)東西了吧

榜樣啊，學習！

“最大的不足在于自己缺乏一套系統(tǒng)的、理論的系統(tǒng)設計過程的指導”

項目實施完畢，覺得萬事OK；每每碰到新項目的時候，就打怵，下不去手

期待分享更多心得

@非魚

Sorry,是我誤導了你，修改了Blog中關(guān)于業(yè)務場景描述的部分。

其中核心問題：作為一家行業(yè)軟件提供商，要形成自己的企業(yè)應用框架[6]，并在該企業(yè)應用框架上搭建行業(yè)的整體解決方案。也就是把各個系統(tǒng)中共性的、普遍性的問題提取出來，形成“企業(yè)應用框架”。其它的業(yè)務功能，用同一開發(fā)平臺重新實現(xiàn)為業(yè)務功能模塊。最后通過企業(yè)應用框架和業(yè)務功能模塊，組裝成產(chǎn)品系列。

關(guān)于你上面提到的幾個問題，由于現(xiàn)在我們服務的主要客戶是中小企業(yè)，所以關(guān)于工作流等，考慮使用免費的方案；數(shù)據(jù)挖掘，以前沒用，近期也沒有打算...

@非魚

我想是“解決企業(yè)信息化中的信息孤島，形成統(tǒng)一的整體解決方案”這句話，使你認為我應該focus on Enterprise Application Integration than technology choice

實際上，我這句話并不是通常所言“信息集成”，和EAI關(guān)系也不大。我說的信息孤島，是指我們現(xiàn)在幾個產(chǎn)品之間，互相獨立，各自有自己的組織機構(gòu)和權(quán)限管理，開發(fā)語言又各不相同，這帶來的問題是：我們需要用不同的開發(fā)工具（開發(fā)語言）維護多套產(chǎn)品中的組織機構(gòu)和權(quán)限管理，多次重復勞動；且代碼模塊不能很方便的被新的系統(tǒng)所重用。

現(xiàn)在要做的工作是，把PB寫的產(chǎn)品A使用Java(或C#)重寫,把用Delphi寫的產(chǎn)品B也使用Java重寫，把VC寫的產(chǎn)品C同樣也使用Java重寫，同時把各個產(chǎn)品共用的模塊，比如組織機構(gòu)、權(quán)限管理等，只要維護一份代碼就OK了。為企業(yè)實現(xiàn)定制功能的時候，由于全部功能模塊都是由同一語言實現(xiàn)的，所以可以靈活組裝成滿足企業(yè)多個要求的“整體解決方案”。

Do I make sense?

WideWeide,申請加入

因為在設計中遇到無數(shù)困惑，以砸磚為主...

每次看到樓主的文章，都有嘆為觀止的驚艷感覺，原來問題可以這么思考的，忍不住要上下其手的摸索一番...

------------------
架構(gòu)的可退化性---這個是說架構(gòu)的無侵入性嗎？

-------------------
架構(gòu)師不是預言家. 在多變的業(yè)務環(huán)境中, 架構(gòu)師的目標不應該是預測到所有的變化可能, 并把它們表達到系統(tǒng)架構(gòu)中. 這個世界上不乏一些耗資數(shù)十億,設計三四年,但最終每個談到它的人都要說一句shit的產(chǎn)品開發(fā)項目. 架構(gòu)設計所能做到的最好的程度是自然的標注出系統(tǒng)的結(jié)構(gòu)邊界,成功的delay各種技術(shù)抉擇.

這話真是太經(jīng)典了，到了最后發(fā)現(xiàn)，所有項目的相關(guān)人員的利益擺不平，都成不了事兒

剛起了頭呀，繼續(xù)關(guān)注

業(yè)務代碼重用的前提是它經(jīng)過業(yè)務專家的提煉、業(yè)務過程完整、可完全配置

這是一個長時間積累的過程，往往是不等到形成就game over了

關(guān)注...
正好要做圖表的東西

1. 版本主次不分

通常我們描述為標準版本、定制版本。標準版本是符合大多數(shù)企業(yè)的通用版－－標準版。為具體企業(yè)定制的版本，不是所有功能都適合放到標準版中，這樣定制的版本多了的時候，管理起來也很麻煩。定制的多個分支交叉開發(fā)的時候，有些是共性的能夠合并且應該合并到主分支，有些則不然

“不就是改幾個頁面嘛”

這個我看是需求的改進速度和技術(shù)水平的實現(xiàn)能力之間的差距造成的；從需求來看，就是改幾個頁面，結(jié)果跑到后臺怎么就那么多工作要做，要是跟其它模塊還有耦合，就更要命了。良好的架構(gòu)和設計，能夠預見可能的變化和調(diào)整，并在架構(gòu)上給以支持；自動化的測試、打包、發(fā)布機制等會有所幫助吧？探索中…

GBean和osgi比較呢？

幾個月前就讀過，再次讀還是大受啟發(fā)。

尤其最后“帶來的思考”更是我現(xiàn)在感到困惑的。JBoss會考慮把JMX換成osgi？

何為DJ？

繼續(xù)關(guān)注。
樓主不會是學物理的