很多同學(xué)對(duì)技術(shù)派項(xiàng)目非常感興趣，目前技術(shù)派教程已經(jīng)更新了三十篇，今天就給大家講講技術(shù)派的架構(gòu)設(shè)計(jì)，讓你對(duì)該項(xiàng)目有一個(gè)整體的認(rèn)識(shí)。

通常對(duì)于技術(shù)人員而言，在開啟一個(gè)新的項(xiàng)目之前，做了前期的調(diào)研、立項(xiàng)之后，第一件事情并不是開始搭建工程、擼代碼，一個(gè)整體的架構(gòu)方案設(shè)計(jì)、評(píng)審都屬于不可忽視的環(huán)節(jié)。

接下來我將盡量追溯還原技術(shù)派的整體架構(gòu)，是如何從 0 到 1 進(jìn)行敲定的。

不 BB，上目錄：

1. 業(yè)務(wù)模塊拆解

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

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

1.1 角色拆解

作為一個(gè)社區(qū)系統(tǒng)，用戶角色非常容易劃分

• 讀者：普通瀏覽文章的用戶
• 作者：發(fā)布文章的用戶
• 管理員：整個(gè)系統(tǒng)的超管

權(quán)限劃分

那么這三個(gè)角色的權(quán)柄是怎么劃分的呢？

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

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

差異性劃分

接下來就需要抓重點(diǎn)，看一下上面三個(gè)角色的主要差異點(diǎn)在哪里

• 讀者：主要是閱讀文章
• 作者：發(fā)布文章，作為信息輸出
• 管理員：整個(gè)系統(tǒng)的運(yùn)營管理，如標(biāo)簽、分類管理，文章審核等；通常不怎么參與文章的閱讀發(fā)布

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

• 普通用戶：作為社區(qū)的注冊用戶，圍繞文章主體展開其覆蓋的業(yè)務(wù)功能點(diǎn)
• 管理員：作為官方角色，主要負(fù)責(zé)整個(gè)社區(qū)的生態(tài)運(yùn)營

1.2 業(yè)務(wù)拆解

整個(gè)社區(qū)系統(tǒng)，按找業(yè)務(wù)邊界先進(jìn)行一版本初始劃分：

• 用戶
• 文章
• 評(píng)論
• 專欄
• 消息通知

然后再針對(duì)上面的進(jìn)行簡單的細(xì)化拆分

再上面進(jìn)行簡單拆分之后，會(huì)發(fā)現(xiàn)幾個(gè)關(guān)鍵點(diǎn)

• 專欄：實(shí)際上是一些文章的合集，因此專欄的很多功能點(diǎn)可以直接建立在文章的基礎(chǔ)上
• 評(píng)論：評(píng)論實(shí)際上也是依托于文章的點(diǎn)評(píng)，因此它于文章的關(guān)聯(lián)性很強(qiáng)
• 消息通知：

消息通知的觸發(fā)點(diǎn)需要進(jìn)一步確認(rèn)，但是它本身又屬于一個(gè)相對(duì)獨(dú)立的業(yè)務(wù)板塊，因此重點(diǎn)關(guān)注交互方式

什么樣的需要通知？如何觸發(fā)通知？

怎么通知給用戶？

• 點(diǎn)贊、收藏、計(jì)數(shù)統(tǒng)計(jì)獨(dú)立于核心業(yè)務(wù)功能之外的能力：

      這種與業(yè)務(wù)相關(guān)，但是又可以抽離于業(yè)務(wù)之外獨(dú)立存在，可以考慮建設(shè)通用的服務(wù)能力

      社區(qū)的搜索、推薦，雖然不影響核心業(yè)務(wù)功能，但是否需要考慮？

      社區(qū)運(yùn)營

基于以上，我們進(jìn)行業(yè)務(wù)模塊拆分，先確定以下板塊：

1.3 小結(jié)

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

在這一階段，我們可以先對(duì)技術(shù)派的整體拆分，得出以下結(jié)論：

角色

• 普通用戶：作為社區(qū)的注冊用戶，圍繞文章主體展開其覆蓋的業(yè)務(wù)功能點(diǎn)
• 管理員：作為官方角色，主要負(fù)責(zé)整個(gè)社區(qū)的生態(tài)運(yùn)營

業(yè)務(wù)模塊

• 業(yè)務(wù)側(cè)：

文章

評(píng)論

專欄

用戶

運(yùn)營

• 基礎(chǔ)功能測：

     推薦

     搜索

     統(tǒng)計(jì)

     消息通知

注意

• 一般來說，在整體設(shè)計(jì)階段，每個(gè)業(yè)務(wù)模塊，需明確的是主體業(yè)務(wù)功能，但并不需要拆解到一個(gè)一個(gè)具體的功能點(diǎn)，具體的功能點(diǎn)，放在詳細(xì)設(shè)計(jì)中來體現(xiàn)
• 業(yè)務(wù)的拆解不是一蹴而就的，相反實(shí)際情況下，這個(gè)拆解經(jīng)常會(huì)出現(xiàn)反復(fù)、變動(dòng)的情況（如果有留心公司的組織結(jié)構(gòu)調(diào)整的小伙伴，應(yīng)該對(duì)這種情況不難理解）

2. 模塊交互方案

接下來我們就需要將上面拆分的角兒和業(yè)務(wù)模塊串聯(lián)起來，看一下我們的整個(gè)系統(tǒng)是怎么玩的

2.1 整體交互設(shè)計(jì)

對(duì)于技術(shù)派的核心玩法，在于作者發(fā)布文章，讀者閱讀文章；整體交互相對(duì)清晰簡單，實(shí)際上這一塊是可以省略的；當(dāng)然我這里也補(bǔ)上這個(gè)流程，主要以文章發(fā)布，到讀者閱讀文章，并點(diǎn)贊，作者獲取通知這個(gè)流程，來串一下這個(gè)系統(tǒng)的整體交互流程

上面這個(gè)交互過程中，用戶中心、文章、消息中心，可以是獨(dú)立部署的服務(wù)，也可以是一個(gè)進(jìn)程內(nèi)的服務(wù)；但是從邏輯上，他們彼此是獨(dú)立的；針對(duì)上面的操作流程，可以提煉下面幾個(gè)點(diǎn)

• 用戶首先通過用戶中心登錄系統(tǒng)

具體的登錄方式可以是傳統(tǒng)的用戶名/密碼，也可以是手機(jī)號(hào)驗(yàn)證碼，亦或者是第三方OAuth2.0登錄

登錄之后，用戶身份識(shí)別，可以是單機(jī)的cookie/session, 也可以是分布式會(huì)話，jwt等形式

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

2.2 登錄交互方案

登錄交互我們最終選擇的方案是基于微信公眾號(hào)來實(shí)現(xiàn)的，下面這個(gè)交互方案適用于個(gè)人公眾號(hào)（如果是企業(yè)公眾號(hào)，可以直接使用微信的相關(guān)的API）

2.3 消息通知方案

消息通知采用異步驅(qū)動(dòng)，通過Event/Listener方式來實(shí)現(xiàn)解耦

3. 整體架構(gòu)方案

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

3.1 初版設(shè)計(jì)方案

下面這張圖來自于技術(shù)派開始做之前繪制的，與最終的實(shí)現(xiàn)版稍有差異，無需在意細(xì)節(jié)??

最初版的方案設(shè)計(jì)非常簡陋，當(dāng)然思路還是比較清晰的

從上面這個(gè)圖，是否能抓住整個(gè)技術(shù)派的業(yè)務(wù)模塊？是否能確定業(yè)務(wù)模塊的定位（哪些偏業(yè)務(wù)屬性，哪些偏技術(shù)屬性）？是否能確定不同角色的側(cè)重點(diǎn)？

能滿足上面三個(gè)點(diǎn)，和其他人進(jìn)行溝通時(shí)，不會(huì)產(chǎn)生歧義即可；當(dāng)然上面這個(gè)圖是缺少交互方案的，通常在業(yè)務(wù)架構(gòu)圖中，不太會(huì)整這個(gè)，有放在細(xì)節(jié)里進(jìn)行鋪開，也有放在詳細(xì)設(shè)計(jì)中的

3.2 業(yè)務(wù)架構(gòu)圖

接下來看一下技術(shù)派最終定稿的整體業(yè)務(wù)架構(gòu)圖，如下：

再看一下前后臺(tái)的業(yè)務(wù)拆分

最后再看一下技術(shù)派的技術(shù)架構(gòu)圖

4. 小結(jié)

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

現(xiàn)在總結(jié)的方案設(shè)計(jì)思路如下：

是不是還沒看爽？