建站
咨詢
售后
建站咨詢
新聞中心
很多同學對技術(shù)派項目非常感興趣，目前技術(shù)派教程已經(jīng)更新了三十篇，今天就給大家講講技術(shù)派的架構(gòu)設(shè)計，讓你對該項目有一個整體的認識。
創(chuàng)新互聯(lián)建站不只是一家網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司；我們對營銷、技術(shù)、服務(wù)都有自己獨特見解，公司采取“創(chuàng)意+綜合+營銷”一體化的方式為您提供更專業(yè)的服務(wù)！我們經(jīng)歷的每一步也許不一定是最完美的，但每一步都有值得深思的意義。我們珍視每一份信任，關(guān)注我們的做網(wǎng)站、成都網(wǎng)站制作質(zhì)量和服務(wù)品質(zhì)，在得到用戶滿意的同時，也能得到同行業(yè)的專業(yè)認可，能夠為行業(yè)創(chuàng)新發(fā)展助力。未來將繼續(xù)專注于技術(shù)創(chuàng)新，服務(wù)升級，滿足企業(yè)一站式成都全網(wǎng)營銷需求，讓再小的成都品牌網(wǎng)站建設(shè)也能產(chǎn)生價值！
通常對于技術(shù)人員而言，在開啟一個新的項目之前，做了前期的調(diào)研、立項之后，第一件事情并不是開始搭建工程、擼代碼，一個整體的架構(gòu)方案設(shè)計、評審都屬于不可忽視的環(huán)節(jié)。
接下來我將盡量追溯還原技術(shù)派的整體架構(gòu)，是如何從 0 到 1 進行敲定的。
不 BB，上目錄：
1. 業(yè)務(wù)模塊拆解
在查看本文之前，請確保已正確了解技術(shù)派的主營業(yè)務(wù)，覆蓋的功能點，如有疑問，可以先體驗一下技術(shù)派網(wǎng)站，訪問地址：https://paicoding.com
在業(yè)務(wù)模塊拆解這一過程中，除了業(yè)務(wù)屬性維度之外，還有一個非常重要的屬性是參與者角色。
1.1 角色拆解
作為一個社區(qū)系統(tǒng)，用戶角色非常容易劃分
- 讀者：普通瀏覽文章的用戶
- 作者：發(fā)布文章的用戶
- 管理員：整個系統(tǒng)的超管
權(quán)限劃分
那么這三個角色的權(quán)柄是怎么劃分的呢？
從上圖可以比較清晰的看出三個角色的劃分
- 讀者的所有功能，作者都擁有；但是作者存在部分讀者用不了的功能（如文章編輯、修改、發(fā)布等）
- 管理員權(quán)限最大，覆蓋讀者、作者的所有功能點
差異性劃分
接下來就需要抓重點，看一下上面三個角色的主要差異點在哪里
- 讀者：主要是閱讀文章
- 作者：發(fā)布文章，作為信息輸出
- 管理員：整個系統(tǒng)的運營管理，如標簽、分類管理，文章審核等；通常不怎么參與文章的閱讀發(fā)布
基于以上分析，我們可以將技術(shù)派的用戶分為
- 普通用戶：作為社區(qū)的注冊用戶，圍繞文章主體展開其覆蓋的業(yè)務(wù)功能點
- 管理員：作為官方角色，主要負責整個社區(qū)的生態(tài)運營
1.2 業(yè)務(wù)拆解
整個社區(qū)系統(tǒng)，按找業(yè)務(wù)邊界先進行一版本初始劃分：
- 用戶
- 文章
- 評論
- 專欄
- 消息通知
然后再針對上面的進行簡單的細化拆分
再上面進行簡單拆分之后，會發(fā)現(xiàn)幾個關(guān)鍵點
- 專欄：實際上是一些文章的合集，因此專欄的很多功能點可以直接建立在文章的基礎(chǔ)上
- 評論：評論實際上也是依托于文章的點評，因此它于文章的關(guān)聯(lián)性很強
- 消息通知：
消息通知的觸發(fā)點需要進一步確認，但是它本身又屬于一個相對獨立的業(yè)務(wù)板塊，因此重點關(guān)注交互方式
什么樣的需要通知？如何觸發(fā)通知？
怎么通知給用戶？
- 點贊、收藏、計數(shù)統(tǒng)計獨立于核心業(yè)務(wù)功能之外的能力：
這種與業(yè)務(wù)相關(guān)，但是又可以抽離于業(yè)務(wù)之外獨立存在，可以考慮建設(shè)通用的服務(wù)能力
社區(qū)的搜索、推薦，雖然不影響核心業(yè)務(wù)功能，但是否需要考慮？
社區(qū)運營
基于以上，我們進行業(yè)務(wù)模塊拆分，先確定以下板塊：
1.3 小結(jié)
通常，在業(yè)務(wù)拆解這里，希望達到的目的是讓參與者，能知曉這個項目的整體情況，可以劃分為多少業(yè)務(wù)域，明確業(yè)務(wù)模塊的主營范疇，確定彼此的邊界
在這一階段，我們可以先對技術(shù)派的整體拆分，得出以下結(jié)論：
角色
- 普通用戶：作為社區(qū)的注冊用戶，圍繞文章主體展開其覆蓋的業(yè)務(wù)功能點
- 管理員：作為官方角色，主要負責整個社區(qū)的生態(tài)運營
業(yè)務(wù)模塊
- 業(yè)務(wù)側(cè)：
文章
評論
專欄
用戶
運營
- 基礎(chǔ)功能測：
推薦
搜索
統(tǒng)計
消息通知
注意
- 一般來說，在整體設(shè)計階段，每個業(yè)務(wù)模塊，需明確的是主體業(yè)務(wù)功能，但并不需要拆解到一個一個具體的功能點，具體的功能點，放在詳細設(shè)計中來體現(xiàn)
- 業(yè)務(wù)的拆解不是一蹴而就的，相反實際情況下，這個拆解經(jīng)常會出現(xiàn)反復、變動的情況（如果有留心公司的組織結(jié)構(gòu)調(diào)整的小伙伴，應(yīng)該對這種情況不難理解）
2. 模塊交互方案
接下來我們就需要將上面拆分的角兒和業(yè)務(wù)模塊串聯(lián)起來，看一下我們的整個系統(tǒng)是怎么玩的
2.1 整體交互設(shè)計
對于技術(shù)派的核心玩法，在于作者發(fā)布文章，讀者閱讀文章；整體交互相對清晰簡單，實際上這一塊是可以省略的；當然我這里也補上這個流程，主要以文章發(fā)布，到讀者閱讀文章，并點贊，作者獲取通知這個流程，來串一下這個系統(tǒng)的整體交互流程
上面這個交互過程中，用戶中心、文章、消息中心，可以是獨立部署的服務(wù)，也可以是一個進程內(nèi)的服務(wù)；但是從邏輯上，他們彼此是獨立的；針對上面的操作流程，可以提煉下面幾個點
- 用戶首先通過用戶中心登錄系統(tǒng)
具體的登錄方式可以是傳統(tǒng)的用戶名/密碼，也可以是手機號驗證碼，亦或者是第三方OAuth2.0登錄
登錄之后，用戶身份識別，可以是單機的cookie/session, 也可以是分布式會話，jwt等形式
- 文章發(fā)布
- 正向邏輯為作者發(fā)布文章
- 文章審核對于作者而言，則屬于被動接收，即存在一個依賴關(guān)系，是自動審核，還是人工審核？人工審核怎么通知管理員來審核？
- 消息通知
- 讀者給文章點贊之后，如何將點贊通知給作者？
- 這個點贊事件是同步觸發(fā)給作者，還是異步？
2.2 登錄交互方案
登錄交互我們最終選擇的方案是基于微信公眾號來實現(xiàn)的，下面這個交互方案適用于個人公眾號（如果是企業(yè)公眾號，可以直接使用微信的相關(guān)的API）
2.3 消息通知方案
消息通知采用異步驅(qū)動，通過Event/Listener方式來實現(xiàn)解耦
3. 整體架構(gòu)方案
上面的流程走完之后，接下來就是敲定整體的架構(gòu)方案，通常一個好的架構(gòu)方案一張圖就完事了，注意越是前期在意的越不是細節(jié)
3.1 初版設(shè)計方案
下面這張圖來自于技術(shù)派開始做之前繪制的，與最終的實現(xiàn)版稍有差異，無需在意細節(jié)????
最初版的方案設(shè)計非常簡陋，當然思路還是比較清晰的
從上面這個圖，是否能抓住整個技術(shù)派的業(yè)務(wù)模塊？是否能確定業(yè)務(wù)模塊的定位（哪些偏業(yè)務(wù)屬性，哪些偏技術(shù)屬性）？是否能確定不同角色的側(cè)重點？
能滿足上面三個點，和其他人進行溝通時，不會產(chǎn)生歧義即可；當然上面這個圖是缺少交互方案的，通常在業(yè)務(wù)架構(gòu)圖中，不太會整這個，有放在細節(jié)里進行鋪開，也有放在詳細設(shè)計中的
3.2 業(yè)務(wù)架構(gòu)圖
接下來看一下技術(shù)派最終定稿的整體業(yè)務(wù)架構(gòu)圖，如下：
再看一下前后臺的業(yè)務(wù)拆分
最后再看一下技術(shù)派的技術(shù)架構(gòu)圖
4. 小結(jié)
這一篇不算是正規(guī)的技術(shù)架構(gòu)方案說明書，更多的是將整個方案的落地過程給大家刨析了一遍，算是拋磚引玉，希望可以給大家今后寫架構(gòu)方案提供一點幫助。
現(xiàn)在總結(jié)的方案設(shè)計思路如下：
是不是還沒看爽？
分享名稱：對標大廠的技術(shù)派架構(gòu)設(shè)計
網(wǎng)頁網(wǎng)址：http://www.5511xx.com/article/cdipedg.html
