架構人生

記得大學里數據庫老師說過一句話，可以拿到這里做總結。“做任何事，應該把它當做一項工程來做，才能做好。軟件工程是一項工程，只有這樣認識它，才能做好軟件。”，無論是在某某架構中，還是在某某軟件開發流程中，最后總結的建議就是：軟件必須重視設計，才像軟件工程，才能持久做好。

一、    某某架構

1．從“層”上認識某某軟件架構

軟件業中Web最經典的架構必然是三層架構：表現層，業務層，數據層。那么讓我們看看某某軟件在三層架構上是如何實現的（如圖1）：

層	項目	認識
表現層	Zivsoft.CRM Zivsoft.CRM.Controller	表現層應該只對界面的表現形式做控制
業務層	Zivsoft.Business Zivsoft.Ajax Zivsoft.Email Zivsoft.Resource Zivsoft.Report	業務層應該只跟具體需求有關系，是商業軟件的真正核心。
數據層	Zivsoft.Comm	數據層必須是獨立，是必須可擴展的一層。

                      圖1某某軟件項目以三層劃分

從上面的表格中，可以看出，有三層的影子，但再具體看項目，發現三層分得不太明確，但又像MVC分層(如圖2)：

層	項目	認識
Model	Zivsoft.Business Zivsoft.Report Zivsoft.Ajax	代表系統的模型層
View	Zivsoft.CRM	模型的展現層
Controller	Zivsoft.Controller	負責業務的流轉

                       圖2某某軟件以MVC層劃分

總體上，感覺某某軟件比較像MVC架構，這是我的認識。總體感覺有架構的影子，但是似乎又沒盡力做到最好。

 

2.從“開發模式”上認識某某軟件架構

首先，我們從軟件流程上來分析：

假設我們現在從客戶得到了一個新的需求，那么，會有很專業的人員理解需求，并將需求帶回公司。某某在這一環節做得很好，如圖3：

 

                                                                                              圖3 客戶需求提出

 

但是，需求分析后的下一步，需求人員開始與程序員溝通，于是開始編碼， 即使程序員在編碼前花了一些時間做了設計工作，甚至還拿到了文檔（注：此文檔一般都是需求文檔，而非設計文檔），具體流程如圖4：

 
圖4 需求到編碼的跨越

于是，接下來，就開始走一下流程(如圖5)：

 

 

那么現在讓我們繼續看下面的流程，如圖6：

 

圖6 軟件實施

現在對以上流程談一下看法：

在需求提出上，我個人認為做得很好，當客戶想要新的功能，無法用軟件表現時，需求人員提出自己的解決方案，讓客戶滿意，并將需求與解決方案帶回公司。回公司，只要溝通沒問題，其實需求文檔并不重要，但一般軟件開發還是要寫需求文檔，因為需求文檔畢竟是文檔，它可以便于以后復查，這是它的主要好處。

但是，我總認為，軟件是一項工程，某某的流程走得似乎過于簡單，編碼前的設計與分析，以及擴展性，還有可行性，另外現有的框架是否滿足這個新需求的到來，等等，這些似乎沒過多考慮，而直接開始了編碼工作。

先看看軟件設計要做的事如圖7：

階段		事務描述
概要設計文檔		對需求人員提出的需求變成開發文檔，并分析是否可行，可行繼續寫詳細設計文檔，不可行和需求人員溝通對需求做出調整，以適應開發，繼續做概要設計分析；另外有可能需要調整系統架構等等，然后來適應開發和軟件的后續穩定性和擴展性。
詳細設計文檔	接口設計	設計者此時必須以開發人員的角色去分析需求。并設計好接口，數據庫結構，各表關聯，以及界面表現形式。還有可能需要對架構等等加以調整和擴充，從而滿足新需求不會影響到已經存在的模塊。
	數據庫設計
	界面設計
備注：		以上是我個人認為很重要的環節，因為很多的Bug都是因為事先考慮不周，或者設計不合理導致的，以及擴展性難，當然作為框架設計不合理，也會導致新需求的加入造成不穩定性，而這一切如此重要，卻被某某忽略，于是總有“不穩性”的陰影，從而大家都在改永遠改不完的Bug。因為沒有事先的設計，從而讓我們陷于如圖5的死循環中，再回頭已不能自拔（如Zivsoft.Comm,DataGrid一動全驚動,殺掉一個bug，而另一個新bug卻悄悄誕生）。

 圖7 軟件設計的重要環節被忽略

作為流程后面的發布與測試，我認為沒有多大問題，還是佩服某某花了大力氣，大人力來做這件事。只是感覺禍源不在此。

 

其次，也就是最后要分析的是研發內部的開發模式：

同樣，從新需求開始分析。

當一個程序員接到新需求，由于軟件架構分了層，那么分層的另一個好處卻沒有利用起來（本可以利用），我們先看圖8：

 

圖8 縱向開發

分層的好處不僅可以把業務獨立，讓數據庫容易擴展，同時界面可以隨意適應客戶需求的改變，這是它的主要好處之一；另外，分層在開發上，它可以讓不同特長的程序員發揮它的專長。如對需求把握比較好的人，它可以去做表現層的開發，這樣界面就比較統一，而且對需求的實現也比較精確；若對需求把握不準，可以去業務層開發，因為它只需要實現被設計好的接口，另外所有的業務之間的關聯，如采購，訂單，發貨，將會非常清晰；至于底層的開發，一般需要性能分析，以及架構的知識，但這一塊變化不大，架構，設計者可以開發這一塊。現將上面的縱向開發模式改成橫向開發模式，如下圖9：

 

圖9 橫向開發

將圖8，圖9兩張圖進行比較，你會發現，程序員不需要知道跟它無關的事情，而且統一了代碼風格，如表現層不會出現key和PKValue兩種不統一的字段，也不會出現按鈕樣式或按鈕在各模塊放的位置不統一；做完訂單流程，同時也知道到了發貨流程該怎么走，它們的關聯一清二楚，之間有什么關系，做這一層的人肯定非常清楚。而橫橫向之間的銜接，就是SOA思想下的請求與響應。你請求，我響應，這不會給程序之間帶來溝通問題。其實如果有設計文檔，這些提前已經設計好。

以上是從開發模式上認識某某軟件架構。

 

二、    架構改進

有了認識必然有一堆想法與建議，以下我用圖的形式加以簡略說明,這樣比較直觀。

1．數據層架構圖

 

圖10 數據層架構

好的數據層一旦建立，隨著業務的擴充，一般不做修改，只需要稍微維護即可，在某某架構中，數據層是非常薄弱的，而且被分到OKComm中，這是不獨立的，上面的數據層架構比較復雜，但從圖可以看出它的最大好處是：跟業務無任何關系，只要是用到數據庫的軟件都可以用到此數據層，而且數據庫是無限制擴展的，因為它是以SOA(面向服務架構)模式搭建，只需要擴展服務即可使用新的數據庫，而且借鑒了開源NHibernate的ORM機制，讓業務不出現任何Sql語句，同時與物理表脫離，從而達到數據庫一旦修改而不影響業務代碼的修改。

下面是數據庫的擴展方式，如圖11：

 

圖11 如何擴展數據庫

2．業務層架構圖

 

圖12 業務層架構

業務層架構相對數據層架構，稍微簡單一些，但是隨著需求的變化，業務的擴充，業務的比重將是整個架構的核心，從而成為軟件企業重復利用的商業業務庫。它好比一個工廠在鑄造零件，當零件漸漸積累多了，用它們來生產產品將越來越輕松，軟件企業亦是如此。

其實某某架構在業務上做得很不錯，只是有一些遺憾，因為它像三層架構，但更像MVC，所以Controller對于某某架構比重占得比較大，如果是MVC架構，那么可以說得過去，但如果它采用的是MVC架構，那么我看到了OKBusiness這樣一個項目，所以又不全是MVC架構。

以上架構圖是對某某架構的改進。它增加了業務索引，因為我覺得業務代碼像是一個工廠的零件庫，而業務索引就像書簽，便于查找的作用。同時去掉了Zivosft.Comm這個四不像的項目，因為它似乎什么都是，但卻什么都不是，于是我個人文為應該將它部分功能封裝在IO層的API中，因為它畢竟是表現層與業務層銜接的樞紐。

 

3．表現層架構圖

 

圖13 表現層架構圖

如圖13，由于SOA架構是面向服務的架構，所以業務層是表現層的服務，那么這就讓表現層是最簡單的一層，因為它只做界面控制，只需請求業務而已。而實際上某某架構中，剛才業務架構中提到，它的比重卻占得比較大，而且是把Zivsoft.CRM與Zivsoft.Controller分開，改起來不方便。在這一層中將Plug-in引入，是因為很多東西可以獨立出來，或者應用第三方的組件，某某架構中的DataGrid是一個最典型的見證。而中間件的定義和要求在圖13中做了說明。

 

三、    總結

記得大學里數據庫老師說過一句話，可以拿到這里做總結。“做任何事，應該把它當做一項工程來做，才能做好。軟件工程是一項工程，只有這樣認識它，才能做好軟件。”，無論是在某某架構中，還是在某某軟件開發流程中，最后總結的建議就是：軟件必須重視設計，才像軟件工程，才能持久做好。

 

本文鏈接:http://www.rzrgm.cn/architect/archive/2009/03/18/1414994.html
作者相關:http://www.zivsoft.com