很多同學對技術派項目非常感興趣，目前技術派教程已經更新了三十篇，今天就給大家講講技術派的架構設計，讓你對該項目有一個整體的認識。

通常對于技術人員而言，在開啟一個新的項目之前，做了前期的調研、立項之后，第一件事情并不是開始搭建工程、擼代碼，一個整體的架構方案設計、評審都屬于不可忽視的環節。

接下來我將盡量追溯還原技術派的整體架構，是如何從 0 到 1 進行敲定的。

不 BB，上目錄：

1. 業務模塊拆解

在查看本文之前，請確保已正確了解技術派的主營業務，覆蓋的功能點，如有疑問，可以先體驗一下技術派網站，訪問地址：https://paicoding.com

在業務模塊拆解這一過程中，除了業務屬性維度之外，還有一個非常重要的屬性是參與者角色。

1.1 角色拆解

作為一個社區系統，用戶角色非常容易劃分

• 讀者：普通瀏覽文章的用戶
• 作者：發布文章的用戶
• 管理員：整個系統的超管

權限劃分

那么這三個角色的權柄是怎么劃分的呢？

從上圖可以比較清晰的看出三個角色的劃分

• 讀者的所有功能，作者都擁有；但是作者存在部分讀者用不了的功能（如文章編輯、修改、發布等）
• 管理員權限最大，覆蓋讀者、作者的所有功能點

差異性劃分

接下來就需要抓重點，看一下上面三個角色的主要差異點在哪里

• 讀者：主要是閱讀文章
• 作者：發布文章，作為信息輸出
• 管理員：整個系統的運營管理，如標簽、分類管理，文章審核等；通常不怎么參與文章的閱讀發布

基于以上分析，我們可以將技術派的用戶分為

• 普通用戶：作為社區的注冊用戶，圍繞文章主體展開其覆蓋的業務功能點
• 管理員：作為官方角色，主要負責整個社區的生態運營

1.2 業務拆解

整個社區系統，按找業務邊界先進行一版本初始劃分：

• 用戶
• 文章
• 評論
• 專欄
• 消息通知

然后再針對上面的進行簡單的細化拆分

再上面進行簡單拆分之后，會發現幾個關鍵點

• 專欄：實際上是一些文章的合集，因此專欄的很多功能點可以直接建立在文章的基礎上
• 評論：評論實際上也是依托于文章的點評，因此它于文章的關聯性很強
• 消息通知：

消息通知的觸發點需要進一步確認，但是它本身又屬于一個相對獨立的業務板塊，因此重點關注交互方式

什么樣的需要通知？如何觸發通知？

怎么通知給用戶？

• 點贊、收藏、計數統計獨立于核心業務功能之外的能力：

      這種與業務相關，但是又可以抽離于業務之外獨立存在，可以考慮建設通用的服務能力

      社區的搜索、推薦，雖然不影響核心業務功能，但是否需要考慮？

      社區運營

基于以上，我們進行業務模塊拆分，先確定以下板塊：

1.3 小結

通常，在業務拆解這里，希望達到的目的是讓參與者，能知曉這個項目的整體情況，可以劃分為多少業務域，明確業務模塊的主營范疇，確定彼此的邊界

在這一階段，我們可以先對技術派的整體拆分，得出以下結論：

角色

• 普通用戶：作為社區的注冊用戶，圍繞文章主體展開其覆蓋的業務功能點
• 管理員：作為官方角色，主要負責整個社區的生態運營

業務模塊

• 業務側：

文章

評論

專欄

用戶

運營

• 基礎功能測：

     推薦

     搜索

     統計

     消息通知

注意

• 一般來說，在整體設計階段，每個業務模塊，需明確的是主體業務功能，但并不需要拆解到一個一個具體的功能點，具體的功能點，放在詳細設計中來體現
• 業務的拆解不是一蹴而就的，相反實際情況下，這個拆解經常會出現反復、變動的情況（如果有留心公司的組織結構調整的小伙伴，應該對這種情況不難理解）

2. 模塊交互方案

接下來我們就需要將上面拆分的角兒和業務模塊串聯起來，看一下我們的整個系統是怎么玩的

2.1 整體交互設計

對于技術派的核心玩法，在于作者發布文章，讀者閱讀文章；整體交互相對清晰簡單，實際上這一塊是可以省略的；當然我這里也補上這個流程，主要以文章發布，到讀者閱讀文章，并點贊，作者獲取通知這個流程，來串一下這個系統的整體交互流程

上面這個交互過程中，用戶中心、文章、消息中心，可以是獨立部署的服務，也可以是一個進程內的服務；但是從邏輯上，他們彼此是獨立的；針對上面的操作流程，可以提煉下面幾個點

• 用戶首先通過用戶中心登錄系統

具體的登錄方式可以是傳統的用戶名/密碼，也可以是手機號驗證碼，亦或者是第三方OAuth2.0登錄

登錄之后，用戶身份識別，可以是單機的cookie/session, 也可以是分布式會話，jwt等形式

• 文章發布
• 正向邏輯為作者發布文章
• 文章審核對于作者而言，則屬于被動接收，即存在一個依賴關系，是自動審核，還是人工審核？人工審核怎么通知管理員來審核？
• 消息通知
• 讀者給文章點贊之后，如何將點贊通知給作者？
• 這個點贊事件是同步觸發給作者，還是異步？

2.2 登錄交互方案

登錄交互我們最終選擇的方案是基于微信公眾號來實現的，下面這個交互方案適用于個人公眾號（如果是企業公眾號，可以直接使用微信的相關的API）

2.3 消息通知方案

消息通知采用異步驅動，通過Event/Listener方式來實現解耦

3. 整體架構方案

上面的流程走完之后，接下來就是敲定整體的架構方案，通常一個好的架構方案一張圖就完事了，注意越是前期在意的越不是細節

3.1 初版設計方案

下面這張圖來自于技術派開始做之前繪制的，與最終的實現版稍有差異，無需在意細節??

最初版的方案設計非常簡陋，當然思路還是比較清晰的

從上面這個圖，是否能抓住整個技術派的業務模塊？是否能確定業務模塊的定位（哪些偏業務屬性，哪些偏技術屬性）？是否能確定不同角色的側重點？

能滿足上面三個點，和其他人進行溝通時，不會產生歧義即可；當然上面這個圖是缺少交互方案的，通常在業務架構圖中，不太會整這個，有放在細節里進行鋪開，也有放在詳細設計中的

3.2 業務架構圖

接下來看一下技術派最終定稿的整體業務架構圖，如下：

再看一下前后臺的業務拆分

最后再看一下技術派的技術架構圖

4. 小結

這一篇不算是正規的技術架構方案說明書，更多的是將整個方案的落地過程給大家刨析了一遍，算是拋磚引玉，希望可以給大家今后寫架構方案提供一點幫助。

現在總結的方案設計思路如下：

是不是還沒看爽？