五大设计原则分别为：单一职责原则、开闭原则、里式替换原则、接口隔离原则、依赖反转原则

一、单一职责原则

最初或者说字面解释：每个模块都应该只做一件事。

符合设计层面的描述：任何一个软件模块都应该有且仅有一个被修改的原因。

“被修改的原因”可以用用户或者所有者来指代：任何一个软件模块都应该只对一个用户(User)或系统利益相关者(Stakeholder)负责。

最终描述：任何一个软件模块都应该只对某一类行为者负责。

放在常规的项目中就是Service层提供的服务需要针对一类行为，例如针对审核任务，一个Service负责审核的动作，一个Service负责增删改查数据库操作，当然如果查询也有很多的话，再将查询能力分出一个Service

二、开闭原则

设计良好的计算机软件应该易于扩展，同时抗拒修改。

虽然原则的说明很简单，但实现起来所考量的点就很多了，合理的模块和依赖关系显得尤为重要，这一原则再次论述就是：如果A组件不想被B组件上发生的修改所影响，那么就应该让B组件依赖于A组件。

实现方式：实现方式是通过将系统划分为一系列组件，并且将这些组件间的依赖关系按层次结构进行组织，使得高阶组件不会因低阶组件被修改而受到影响。

核心要点： 依赖方向的控制、 对调用者进行信息隐藏

三、里式替换原则

这里需要的是一种可替换性：如果对于每个类型是S的对象o1都存在一个类型为T的对象o2，能使操作T类型的程序P在用o2替换o1时行为保持不变，我们就可以将S称为T的子类型。

最开始该原则是指导如何使用继承关系的一种方法，然而随着时间的推移，LSP逐渐演变成了一种更广泛的、指导接口与其实现方式的设计原则。

其本质就是面向接口编程

四、接口隔离原则

在一般情况下，任何层次的软件设计如果依赖于不需要的东西，都会是有害的。

从源代码层次来说，这样的依赖关系会导致不必要的重新编译和重新部署，对更高层次的软件架构设计来说，问题也是类似的。

五、依赖反转原则

如果想要设计一个灵活的系统，在源代码层次的依赖关系中就应该多引用抽象类型，而非具体实现。

稳定的抽象层：我们每次修改抽象接口的时候，一定也会去修改对应的具体实现。但反过来，当我们修改具体实现时，却很少需要去修改相应的抽象接口。所以我们可以认为接口比实现更稳定。

归结为以下几条具体的编码守则：

1. 应在代码中多使用抽象接口，尽量避免使用那些多变的具体实现类。同时，对象的创建过程也应该受到严格限制，对此，我们通常会选择用抽象工厂(abstract factory)这个设计模式。
2. 不要在具体实现类上创建衍生类
3. 不要覆盖(override)包含具体实现的函数。在这里，控制依赖关系的唯一办法，就是创建一个抽象函数，然后再为该函数提供多种具体实现。
4. 应避免在代码中写入与任何具体实现相关的名字，或者是其他容易变动的事物的名字。