在我前面有很多篇隨筆介紹了Web API 介面層的架構設計，以及對微信公眾號、企業號、小程式等模塊的分類劃分。例如在《C#開發微信門戶及應用(43)--微信各個項目模塊的定義和相互關係》介紹了相關模塊的劃分，在《基於微信小程式的系統開發準備工作》介紹了Web API的架構設計思路。本篇隨筆對之前介紹... ...
在我前面有很多篇隨筆介紹了Web API 介面層的架構設計，以及對微信公眾號、企業號、小程式等模塊的分類劃分。例如在《C#開發微信門戶及應用(43)--微信各個項目模塊的定義和相互關係》介紹了相關模塊的劃分，在《基於微信小程式的系統開發準備工作》介紹了Web API的架構設計思路。本篇隨筆對之前介紹的架構內容進行統一的調整更新，以便更加方便實際項目的應用開發，以期達到統一、重用、清晰的目的。
1、公眾號、企業號、小程式模塊的劃分
我們知道，目前微信企業應用，分為公眾號、企業號（企業微信）、小程式三種應用模式，對於常規的開發來說，我們對每個模式的應用都分為了兩個不同的部分，一個是和業務數據相關的數據管理、一個是和API介面相關的API管理，兩者整合為一個完整的應用。
公眾號、企業號（企業微信）、小程式三種應用模式的模塊劃分如下圖所示。
業務數據管理模塊，一般還需要調用API介面進行相關的處理操作，因此他們之間的項目引用關係如下所示
另外，這三種類型的API介面也公用了一些業務對象和實體類，因此把它們抽取出來作為公共項目模塊，如這三類介面項目統一使用了一個公共實體類項目。
除了這些之外，我們做項目，一般還涉及到一些基礎功能模塊，如公用類庫，以及附件管理、通訊錄管理、許可權管理模塊等內容，我們可以把後者幾個模塊放在一起，組成基礎模塊。
2、基於微信的Web API 架構設計
隨著基於JSON格式的Web API的廣泛應用，越來越多的企業採用Web API介面服務層，作為統一介面的核心所在，也成為Web API核心層。基於JSON格式的介面，可以廣泛地、跨平臺的應用於IOS、安卓等移動端，也可以應用在常規的Web業務系統，Winform業務系統、微信應用、微信小程式等方方面面，因此企業內部形成自己是的一套Web API標準和詳細的文檔非常重要，一旦完善了，就可以供各個業務場景使用，這些業務可以外包給其他軟體公司或者團隊，各自分離開發，而自己內部則只需要花費精力來統一維護Web API核心層和提高整個核心層的功能介面穩定、緩存處理等方面事情即可。其他業務團隊開發的系統只需要遵循整個大介面平臺的統一規劃，完成各自的功能需求即可，不會造成資料庫的不一致，更不會讓某家公司掌握核心的技術資源，尾大不掉的尷尬情形。
基於上面的分析，我們企業最終圍繞著Web API核心層做了不同的業務應用，如下圖所示。
再進一步詳細各個模塊的分層，我們可以細化為下麵的架構設計圖，所有模塊均圍繞著Web API 介面層進行擴展，底層的數據存儲對上層的應用是完全透明，我們可以根據需要拆分各種業務資料庫，以及使用我們認為合適的資料庫。
其中我們在Web API介面層上還看到一個微信消息交互的模塊，這個模塊我們為了方便功能變數名稱埠的處理，和Web API 是統一放在一起的，它負責和騰訊微信伺服器進行消息的交互處理，從而實現各種消息推送處理。
微信的伺服器架起了客戶手機和開發者伺服器的一個橋梁，通過消息的傳遞和響應，實現了與用戶的交互操作，下麵是它的消息流程圖。
通過對這幾類業務應用的模塊分析，我們就可以建立相關的項目了，來分別對這些數據和API進行管理，如我們根據這些分類，在Visual Studio的項目管理中看到的項目如下所示。
其中由於我們這裡的Web API 是一個統一的出口，因此會整合很多Web API控制器，以提供所有業務的介面，因此對Web API 控制器的管理就顯得很重要，這裡建議引入Area區域進行管理控制器類，這種各個模塊就能夠很好分門別類的進行管理了。
如下圖所示是我們的Web API項目的控制器Area區域分類，把微信公眾號、企業號、小程式、基礎框架、第三方介面、CRM等內容進行不同的劃分。
