DSSHOP 設(shè)計架構(gòu)

以下將介紹dsshop的設(shè)計架構(gòu)，讓你更好的了解dsshop是如何工作的

項目結(jié)構(gòu)

• 多客戶端->API服務(wù)器->REDIS隊列->mysql數(shù)據(jù)庫

消息通知

• 消息通知是項目運(yùn)營必不可少的環(huán)節(jié)，比如用戶購買后，后臺管理人員能第一時間收到訂單提醒，用戶在平臺發(fā)貨后第一時間能收到發(fā)貨通知等等
• 因小程序服務(wù)消息受限，不能主動發(fā)送，故項目已整合微信公眾號的模板消息，并加入了引導(dǎo)，當(dāng)然也集成了郵件、站內(nèi)信通知

注冊機(jī)制

• 項目支持手機(jī)驗證碼注冊和授權(quán)登錄兩種方案

支付

• 不同客戶端同一支付入口，讓支付變的更簡單

觀察者模式

觀察者模式是為了更好的解耦，比如用戶下單付款這個動作，正常的流程應(yīng)該用戶在付款后，訂單狀態(tài)變更為已付款，這個流程應(yīng)該就結(jié)束了；但你可能需要在用戶下單付款后進(jìn)行其它操作，如通知、資金記錄等等，傳統(tǒng)的思路是直接將這些操作代碼直接寫在下單付款所在的代碼塊中；這種方式雖然能解決問題，但會存在高耦合的問題，也就是當(dāng)你要追加一個操作的時候，就需要修改下單付款對應(yīng)的方法，有可能需要修改多處（微信支付、余額支付、支付寶支付等等），時間長了，你可能只修改了某幾處，而其它幾處并沒有修改，大大增加了試錯成本。

• 觀察者模式，其實有多種實現(xiàn)方案，如事件和Observer觀察者模式，本項目采用了Observer觀察者模式；之所以不采用事件的原因是，事件并不能完成解耦，需要在業(yè)務(wù)代碼中添加觸發(fā)監(jiān)聽器的代碼，而且還需要事先知道需要傳遞的參數(shù)，不然當(dāng)后期監(jiān)聽器中需要用到?jīng)]有傳遞的參數(shù)時，需要修改觸發(fā)代碼
• 以下主要介紹Observer觀察者模式，該模式和vue的生命周期類似

retrieved,            #獲取到模型實例后觸發(fā)
creating,             #創(chuàng)建過程前                                * 常用
created,              #創(chuàng)建成功后                                * 常用
updating,             #更新過程前                                * 常用
updated,              #更新成功后                                * 常用
saving,               #代表這兩個方法的集合creating,updating       * 常用
saved,                #代表這兩個方法的集合created,updated         * 常用
deleting,             #刪除過程前                                * 常用
deleted,              #刪除過程后                                * 常用
restoring,            #恢復(fù)軟刪除記錄前觸發(fā)
restored,             #恢復(fù)軟刪除記錄后觸發(fā)

• 現(xiàn)在只需要在你想要追加的時候定義一個Observer觀察者，即可輕松的實現(xiàn)你想要的效果，而且不用修改原始代碼，在dsshop更新時，達(dá)到無縫升級
• 觀察者如何使用，將會在插件開發(fā)中進(jìn)行詳細(xì)介紹