本课题主要是基于VUE和SpringBoot框架实现一个抽奖系统服务端，该抽奖平台是一个支持多种不同的抽奖方式且支持高并发的多种用户系统，抽奖系统角色共分为四类，包括基础的抽奖用户，抽奖发布者，进行数据信息管理的后端管理员以及自动执行抽奖的抽奖执行模块。普通用户可以查看并参加抽奖；抽奖发布者可以发布抽奖，管理自己发布的抽奖信息和参加该抽奖的用户，获取系统返回的中奖用户并发奖；管理员可以通过抽奖系统后端管理现有的抽奖及用户信息；抽奖执行模块则负责自动适时执行各类抽奖。
前台开发平台：web前端
后台开发平台：IntelliJ IDEA
数据库：MySQL & Redis
服务器：云服务器（BAE或SAE）
计算机硬件配置：
抓取服务器：内存1.5G以上
数据服务器：内存2G以上
3，使用的技术
前端：vue
后端
web框架：Springboot
持久层框架：JPA
认证授权框架：Shiro
分布式框架：Dubbo+Zookeeper
搜索框架：ElasticSearch
数据库：
mysql+redis
提到设计模式，我们首先需要了解设计模式的设计原则。
高层模块（稳定）不应该依赖于低层模块（变化），二者都应该依赖于抽象（稳定）。
抽象（稳定）不应该依赖于实现细节（变化），实现细节（变化）应该依赖于抽象（稳定）。
开放封闭原则（OCP）
对扩展开放，对更改封闭。
类模块应该是可以扩展的，但是不可修改。
单一职责原则（SRP）
一个类应该仅有一个引起它变化的原因。
变化的方向隐含着类的责任。
Liskov替换原则（LSP）
子类必须能够替换它们的基类（IS-A）。
继承表达类型抽象。
接口隔离原则（ISP）
不应该强迫客户程序依赖它们不用的方法。
接口应该小而完备。
优先使用对象组合，而不是类继承
类继承通常为"白箱复用"，对象组合通常为"黑箱复用"。
继承在某种程度上破坏了封装性，子类父类耦合度过高。
而对象组合则只要求被组合的对象具有良好定义的接口，耦合度较低。
封装变化点
使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合。
针对接口编程，而不是针对实现编程
不将变量类型声明为某个特定的具体类型，而是声明为某个接口。
客户程序无需获知对象的具体类型，是需要知道对象所具有的接口。
早绑定 -> 晚绑定
继承 -> 组合
编译时依赖 -> 运行时依赖
一般的new 违背了 依赖倒置原则(依赖抽象，而不依赖具体)
例：A a = new A(); //此处的A是一个具体的类，而不是抽象
根据依赖倒置原则，我们应该尽可能的使用抽象设计，减少具体（可以降低耦合），但是抽象类是不可以实例化的（new），此时就需要一种方式来解决实例化问题。提供一个工厂接口，把创建对象的任务往后推给子类，使当前类与new隔离。该种设计模式就是工厂模式。
使用工厂模式的好处：工厂模式用于隔离类对象的使用者和具体类型之间的耦合关系。面对一个经常变化的具体类型,紧耦合关系(new)会导致软件的脆弱。一旦更改具体类型，就要更改使用者中的代码，耦合度太高,而工厂方法，降低了两者的耦合度，类型改变或增加时只需改变/增加工厂子类即可，而使用者的源码不必改变。
工厂模式的通用类图结构图：（附部分注释，希望可以帮助读者快速理解）
mvc，微服务
在用户抽奖界面以及抽奖发布者的界面，应充分考虑展示信息与用户的可交互性，在需求分析的基础上，合理展示抽奖系统为用户提供的各种信息，包括根据用户推荐的各类抽奖活动。由于前端确定采用VUE框架，因此可以基于VUE对信息进行简单排布形成基本的展示界面，再在此基础上进一步优化，尽可能降低界面和操作的学习成本。
前端方面，可以提供前端数据接口用于接收抽奖系统服务端发送的用于显示的信息，提高前端界面的可扩展性，也易于更换或者直接扩展前端界面。服务器端则提供基本的数据库的连接接口，方便数据库的迁移、升级和更换；另外还可以提供抽奖执行模块、发奖模块的接口，实现模块化，模块之间进行解耦以提高维护性和可扩展性。
https://www.bilibili.com/video/BV1kW411P7KS?p=5
https://blog.csdn.net/sinat_34166518/article/details/89206059
原文：https://www.cnblogs.com/junc0125/p/14204302.html