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

項(xiàng)目結(jié)構(gòu)

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

消息通知

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

注冊(cè)機(jī)制

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

支付

• 不同客戶端同一支付入口，讓支付變的更簡(jiǎn)單

觀察者模式

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

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

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

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