注：此文來自新浪微博網友@哲學家灰太郎 的推薦。
在做系統設計的時候，常常遇到這樣的設計，如某個技術牛人，他對某個技術非常熟 悉。那麼在設計中，他會使用該技術作為主要設計，還有的看到什麼流行就用什麼技術。 有的採用二次開發框架減少開發量來做設計。但所有這些設計都共同犯了個錯誤，即你的設計是要適應使用者的需求和環境，
也許他說，我的很適應啊？那麼在你說這句話之前，你是否調查過呢？如果你認為使用者提出的就可以了，那麼就錯了，使用者是很難提出全面的問題，因為你是解決商，你必須得會去解決。
一個好的設計師除了瞭解需求，還得要挖掘使用者真實的意圖，有些意圖雖然使用者說不出，但一旦你挖掘出說給使用者，使用者會說啊，就是這樣的。
一個好的系統設計師需要的是站在使用者的立場去考慮問題，然而我遇到的許多設計師 卻從來都是從自己的框架技術上考慮問題。當他們在預設，限制因素等等上出現問題的時候，那麼系統就會變得和預期的差別很大。
舉個例子：一個設計師設計了一個系統，採用訊息佇列和MDB，來操作業務，整個設計看起來的確很清晰和完整。 當我接手他們已經做好的系統，我用流程圖和序列圖把整個業務畫了一遍，
發現流程線有多餘及迴路，複雜度高，這樣的設計會有問題。
但接下來的問題來了，其系統對環境依賴很大，大量的xml配置檔案，WAS相差0.0.19個版本 也出現系統不能執行，即使是測試環境和生產環境一致，也出現，系統不能執行。
結果我們花在環境部署上的時間達1個月。 另這樣的設計由於技術有點難度，導致開發週期增長。
如果開始設計成簡單的技術servlet+socket實現 將縮短2個月時間。且效能也很高。
總算部署好了，接下來問題又來了，系統記憶體暴漲。。在測試環境一點問題也沒有，但到了生產環境出問題，由於生產環境不能隨便裝東西，不能隨便去除錯，導致沒法找出問題。
後來總結髮現，我們的系統是部署在客戶的共享環境-就是你得和其他人的7、8個系統共享系統環境，不是獨立部署，不能隨便改設定，改了影響別人怎麼辦？比如你把MDB時間調高。。
也就是說必須沿用以前系統的設定，要麼你的系統對設定不依賴性。否則就容易出問題。結果不得不走原路，用servlet+socket最簡單的技術實現
從這個例子的教訓告訴設計師：給使用者的設計原則：
1、效能要符合要求
2、要注意具體環境是什麼？設計之初就要考慮
3、要考慮以後維護人的成本，是不是一個畢業生學一二個月就能維護呢？還是需要高手？
對於使用者來說，穩定和可用性是第一的，技術不是主要，除非你的技術提高效能很高或很容易擴充套件。再好的技術，再牛的技術，造成不可用，或費勁，那麼都是垃圾。
在設計中還有個現象，就是有的設計者試圖設計一個二次開發框架，給客戶做系統，配置配置就好了或稍加改動，這樣對於自己來說是成本最低。 這的確是個好想法，許多地方應用也是很不錯的，但這樣的框架不是所有的使用者環境都適用。
有的明知道不適應，還是先忽悠使用者，以後再改再加，結果未來的系統將是一個四不像。
用這樣的系統最大的風險就是 ，對廠商依賴，離開了二次開發框架則無法繼續業務，需要擴充套件改框架還必須得原廠商來做，這時候可以報告價格了，也就是說客戶被吊死在這個系統上，除非以後可以重新做一套。
有設計師說，你說的不對，我的二次開發時可以擴充套件的，沒錯，是可以擴充套件，但擴充套件的力度，複雜業務的擴充套件，導致，你必須在系統外再構建介面，或者系統內構建修改業務。 這樣的系統那還算是二次開發框架嗎，
最後發現修改的成本和開發新的差不了多少？ 另外，框架升級怎麼辦？你總不能像WAS，weblogic那樣吧具有通用性升級？你難道把所有J2EE、SOAP協議層也加進去？
因此一個好的設計師必須是：站在使用者的角度（當然要兼顧自己的利潤），
除了設計滿足使用者體驗度的產品，對應系統的架構，必須考慮前面三點。
==============================================
系統框架設計一般分為三種，一種是基於中介軟體的可擴充套件的框架，一種是可重複的框架，一種是可擴充套件及重複的款架。
第一種是依賴於第三方中介軟體如struts，spring等等，這是通用做法的框架。
優點：使用多，不含業務，可以任意架構業務。，缺點：業務邏輯和業務元件必須要自己開發。
第二種做法是把業務邏輯抽象出來，形成自己的框架，通過配置可生成介面或操作，客戶端通過服務端的資料解析生成介面和操作。
優點：方便，複用性，特別適用於展現架構。可通過視覺化展現出來，通過二次開發即可，二次開發技術要求低。適應簡單業務變化，適合於OA，類瀏覽器（如UCWeb等等）、內容管理，CRM，業務展現部分等等
缺點：不是所有的業務都可以抽象出來，可抽象的僅僅是共性的東西。如果擴充套件的話，必須客戶端和服務端都要修改。（比如金鑰和安全系統，賬務，對賬清算等等不是靠配置配置就可以的）
手機端和客戶端的作業系統變化太快，客戶端存在版本升級的問題，不能利用新的手機系統UI，要麼就修改客戶端，服務端也相應修改。維護工作並不減少。
由於這樣的架構是單個廠商開發的，不具備通用性和開發性，如果你要接入其他系統，或其他系統接入，框架必須做大的修改（因為框架設計之初是不會考慮太多負責環境的），
整個架構依賴於廠商，離開了廠商將無法維護和增加（即使他們提供原始碼，也難底層程式碼維護）。
想擴充套件的時候，不得不繼續，導致未來成本增加。
也就是說：方便性高，服務框架的引擎複雜度越高，反而靈活性，可維護擴充套件性低，環境適應差（比如環境忽然換到內網，或者不同網段，訪問受限制等等就難擴充套件了）。
適應範圍有限，特別複雜業務和安全的不適應。
第三種：根據不同的業務來設計框架，並利用成熟的如中介軟體等等，組合應用，保證底層的穩定複雜和安全，並可擴充套件新業務元件，以元件方式不斷增加方式的遞增擴充套件。
這種框架常用：訊息佇列，EJB,MDB,服務匯流排，服務排程和反射等等。
優點：不依賴於產商，具有靈活、可擴充套件性好，環境適應強，業務不需要如第二種做高度抽象出來，可直接實現到可擴充套件元件中。全部元件化管理，適在此基礎上可方便擴充套件生成出第二種框架。
用不同層次的平臺，從內容管理，CRM等（大材小用）到適用於內部系統，各種平臺資源的結合和呼叫，適合各種安全體制，適用於政府、大型企業系統。
維護擴充套件方便，部署熱部署方便。
缺點：和第一種一樣，不方便直接視覺化展現架構業務，不對技術要求高些，架構要在初期設計中設計完善,。