| 聲明 |
【PaPaPa】這個項目是以技術分享與研究為目的而做的，并非商業項目，所以更多的是提供一種思路，請勿直接在項目中使用。
上一篇隱藏開源項目地址實屬無奈，為了尋找一起做這件事的同伴不得已刷了一天推薦，在此希望大家能夠理解。
從此篇開始將完全公開項目地址以及所有項目中涉及到的細節，包括文檔、討論過程、設計思路、實現方法全部整理出來寫成一個系列，這個將在后續文章中一一揭開，敬請期待。
本項目與博文系列將秉承著“授人以漁”的方式寫作，盡自己綿薄之力為C#出一份力以回饋我從C#中得到的快樂和生活上的改善。
同時因為本項目不涉及分布式和大數據方面的內容，所以本博文系列也不會有這方面的內容，即便是應用了Redis，也只是以緩存的方式來使用。
最后本著不想誤人子弟的想法，歡迎各位同行斧正錯誤！
| 什么是軟件架構 |
軟件架構分邏輯架構、物理架構、系統架構。
一般情況下系統架構師會出起碼包含以上3個部分的文檔，而部分分工明細的公司，物理架構關于服務器配置與網絡的章節由運維部（或其他類似職責部門）來補充或修改。
有此可以看出一個合格的系統架構師，他/她的知識廣度是很恐怖的。
當然本文并不是一個維基百科或百度百科，所以只是淺談即止。
| 系統架構如何產生 |
首先明確一點的，萬能是因為它是一個兼顧與取舍的博弈，沒有一個系統架構可以拍著胸脯說：我可以應用到任何場景。
系統架構與業務有著強烈的依賴關系，業務左右系統架構，而系統架構有時在特殊情況下也可能會影響業務做適當調整。
既然說到業務左右系統架構，那么很明顯，要先有業務才有系統架構。
| 需求文檔 |
需求文檔是業務的可視化輸出。正常情況下此文檔由產品經理或需求專員來撰寫，用來描述軟件所包含的業務。
下面我們只簡單的拿個【PaPaPa】項目在建立時‘老虎’隨手畫的2個腦圖，現在的需求文檔已經從v0.1-v0.4了，目前正在整理新版中，預計下周會出。
上面2副只是其中討論過程中出現的比較典型的而已，當然正式的需求文檔肯定不會是這個樣子了。
| 系統架構搭建過程 |
| 淺析業務模塊 |
從上面圖中可以看出大概分為Web端和移動端兩個大的部分，
由于急著趕出一個雛形，我們當時確定了移動端的放到后面再做，所以暫時僅僅考慮了擴展而沒有規劃。
雖然延期了，但是系統架構搭建時必然是要考慮到這點的，否則后面的修改會讓你很是頭疼。
| 解決方案文件夾 |
解決方案文件夾有助于幫助我們將類庫進行歸類，比較常見的是類似下面這樣
當然，根據每個人的喜好命名會有所不同，有的項目需要可能會沒有Test，也有的可能會把Business和Core合并等等。
而我們的劃分則是上圖這樣，區分業務和核心是因為核心層提供了底層的數據操作。業務來組裝這些操作來滿足業務需求。
而這一塊則是配合上面說到的，將來要做移動端，而移動端業務跟Web端是有一些差別的，不論是從接口數量還是接口內容都會有出入。
| 類庫命名 |
以業務層為例，PaPaPa.Web.* 為一組。
其中PaPaPa則是項目名稱，Web則是分屬哪一個業務模塊，那么移動端的命名呼之欲出的方式則可能是 PaPaPa.Mobile.*
| 如何區分核心層、業務層、基礎設施層 |
由于其他分層并沒有什么可想說的內容，所以其他的就忽略了。有疑問可單獨提出。
我們先簡單了解一下：
核心層：被業務層包圍，給業務層提供底層操作支持，如DB、緩存等。
業務層：借助核心層提供的功能封裝不同模塊的業務。
基礎設施層：給所有的層提供最基礎的底層支持（不包含任何業務邏輯），以PaPaPa項目為例，包括但不限于：通用緩存操作（緩存監控）、通用類庫、DB操作、通用的模型與實體映射、緩存操作。此層還應該有很高的移植性，在創建新項目時，此層可直接拷貝使用是一個隱含的標準。
在創建新的類庫時，根據當前類庫所承擔的責任將其放到對應的層級中是對一個類庫在系統中所處角色的一個重要的標識。
如果你不小心把一個處于核心層的類庫放到業務層，后果則是出現各種冗余代碼，因為不同業務模塊間按理說是不允許互相重用的，除非你再創建一個 PaPaPa.BasicBusiness.* 類似這樣的一個專門歸類基礎業務的模塊。
當然這只是從合理角度來說的，如果設計者到后期無法維護自己心目中的系統架構時，則會出現各層級交叉調用的一種混亂局面，而那時，項目的維護成本將會很高！
| 類庫職責劃分 |
有不少同行看到我的類庫后覺得類庫數量太多，有些類庫內沒幾個類表示不解。
其實類庫內類的數量多少不是關鍵，關鍵是類庫的職責是否有明確劃分，否則就會變成各個功能放在同一個類庫。
一方面是會導致類庫內文件夾層級過深，另外一方面則是升級時不相關業務會因為升級而中斷，最最總要的一方面則是加大系統分層的難度，因為一個功能龐大的類庫很可能會跨多個層級。
下面是PaPaPa項目中每個類庫所擔任的職責，這只是眾多分類方式的一種。
只要你在做類庫劃分時，按照一定的規則來歸類即可。
這能讓開發者更明確的知道系統搭建者的意圖。
| 源碼 |
這只是這個系列的一個開篇，后面會把我們在寫這個項目過程中的一些比較重要的環節以及實戰經驗加入到其中。
當然會包括很多人關注的緩存決策，如何在不破壞系統搭建意圖的情況下加入新的底層支持。
簡單說下，緩存決策又分自動決策和手動決策兩部分，底層支持跨了2個層級，且因為靈活性問題部分區域為何放棄自動決策。
當然了，這個說起來名字很高大上，其實也就是普通的C#語法的一個組合罷了。
最后，源碼地址：http://git.oschina.net/doddgu/PaPaPa
新聞熱點
疑難解答
