DSSHOP 设计架构

以下将介绍dsshop的设计架构，让你更好的了解dsshop是如何工作的

项目结构

• 多客户端->API服务器->REDIS队列->mysql数据库

消息通知

• 消息通知是项目运营必不可少的环节，比如用户购买后，后台管理人员能第一时间收到订单提醒，用户在平台发货后第一时间能收到发货通知等等
• 因小程序服务消息受限，不能主动发送，故项目已整合微信公众号的模板消息，并加入了引导，当然也集成了邮件、站内信通知

注册机制

• 项目支持手机验证码注册和授权登录两种方案

支付

• 不同客户端同一支付入口，让支付变的更简单

观察者模式

观察者模式是为了更好的解耦，比如用户下单付款这个动作，正常的流程应该用户在付款后，订单状态变更为已付款，这个流程应该就结束了；但你可能需要在用户下单付款后进行其它操作，如通知、资金记录等等，传统的思路是直接将这些操作代码直接写在下单付款所在的代码块中；这种方式虽然能解决问题，但会存在高耦合的问题，也就是当你要追加一个操作的时候，就需要修改下单付款对应的方法，有可能需要修改多处（微信支付、余额支付、支付宝支付等等），时间长了，你可能只修改了某几处，而其它几处并没有修改，大大增加了试错成本。

• 观察者模式，其实有多种实现方案，如事件和Observer观察者模式，本项目采用了Observer观察者模式；之所以不采用事件的原因是，事件并不能完成解耦，需要在业务代码中添加触发监听器的代码，而且还需要事先知道需要传递的参数，不然当后期监听器中需要用到没有传递的参数时，需要修改触发代码
• 以下主要介绍Observer观察者模式，该模式和vue的生命周期类似

retrieved,            #获取到模型实例后触发
creating,             #创建过程前                                * 常用
created,              #创建成功后                                * 常用
updating,             #更新过程前                                * 常用
updated,              #更新成功后                                * 常用
saving,               #代表这两个方法的集合creating,updating       * 常用
saved,                #代表这两个方法的集合created,updated         * 常用
deleting,             #删除过程前                                * 常用
deleted,              #删除过程后                                * 常用
restoring,            #恢复软删除记录前触发
restored,             #恢复软删除记录后触发

• 现在只需要在你想要追加的时候定义一个Observer观察者，即可轻松的实现你想要的效果，而且不用修改原始代码，在dsshop更新时，达到无缝升级
• 观察者如何使用，将会在插件开发中进行详细介绍