三层架构（View Service Dao）
-
三层架构是指：视图层 view（表现层） ，服务层 service（业务逻辑层） ，持久层 Dao（数据访问层）
-
表现层：直接跟前端打交互（一是接收前端 ajax 请求，二是返回 json 数据给前端）
-
业务逻辑层：一是处理表现层转发过来的前端请求（也就是具体业务），二是将从持久层获取的数据返回到表现层。
-
数据访问层 ：负责数据库的访问 （可以访问数据库、二进制文件、文本文件等），是对数据库，而不是对数据的操作。
直接操作数据库完成 CRUD，并将获得的数据返回到上一层（也就是业务逻辑层）。
-
-
三层架构的出现是为了降低耦合度。
使用面向抽象编程，也就是上层对下层的调用，直接通过接口来完成，而下层对上层的真正服务提供者，是下层实现的接口实现类。实现类是可以更换的，这就实现了层间的解耦合。
-
实际项目中的包命名结构，其实就是三层架构的体现：
MVC（Model View Controller）
-
MVC 是软件工程中的一种软件架构模式，它是一种分离业务逻辑与显示界面的设计方法，它把软件系统分为三个基本部分：**模型（model）、视图（view）、控制器（controller）**
-
MVC 架构提供了一种结构化的方法来开发软件 ，特别是 Web 应用程序，通过将业务逻辑 、用户界面 和用户输入 分离开来，以提高代码的可重用性、可维护性和可扩展性。
-
MVC 框架的核心组件：
-
模型（Model）：负责管理数据和业务逻辑，通常包括数据的存取和业务规则的处理。模型与视图和控制器分离，确保数据的完整性和一致性。
model 一般分为以下两类：
- 数据承载 bean：是指专门承载业务数据的实体类，比如 Student，User 等。
- 业务承载 bean：是指进行业务处理的 Service 或者 Dao 对象，专门处理用户的请求。
-
视图（View）：负责展示数据给用户，通常是通过用户界面呈现。视图从模型中获取数据，但不处理数据。
-
控制器（Controller）：负责处理用户的输入，控制程序的流程。控制器接收用户的请求，调用模型获取数据，然后选择合适的视图来展示数据。
-
-
MVC 框架的优势：
- 高内聚低耦合：MVC 框架通过将应用程序分为三个独立的部分，减少了各部分之间的依赖，提高了代码的模块化和重用性。
- 易于维护：由于各个部分职责明确，当需要修改功能时，只需关注相关的部分，不会影响到其他部分。
- 可扩展性：当需要添加新的功能时，可以很容易地在现有架构上添加新的模型、视图或控制器，而不需要重写整个应用程序。
SSM（Spring SpringMVC MyBatis）
-
SSM：即 Spring 、SpringMVC、与 MyBatis 三个框架。
-
它们在三层架构中所处的位置是不同的，即它们在三层架构中的功能各不相同，各司其职。
-
Spring：以整个应用大管家的身份出现。整个应用中所有 Bean 的生命周期行为，均由 Spring 来管理。
即整个应用中所有对象的创建、初始化、销毁，及对象间关联关系的维护，均由 Spring 进行管理。
-
SpringMVC：作为 Controller 层的实现者，完成用户的请求接收功能。
SpringMVC 的 Controller 作为整个应用的控制器，完成用户请求的转发及对用户的响应。Spring MVC 是主流的 Web 框架。
-
MyBatis：作为 Dao 层的实现者，完成对数据库的增、删、改、查功能
-
EDD（Event Driven Design）
-
事件驱动设计（Event Driven Design，简写 EDD）是一种软件设计范式，其中程序的执行流由外部事件（如用户输入、系统信号、网络数据等）来决定。这种设计方法广泛应用于图形用户界面（GUI）、网络服务器、实时系统等领域，旨在提高系统的响应能力和灵活性。
事件驱动设计是一种强大且灵活的设计模式，特别适用于需要处理大量异步操作和实时数据流的系统。通过解耦组件、提高灵活性和响应性，事件驱动设计可以帮助构建高效、可扩展的应用程序。然而，它也带来了复杂性和调试困难等挑战，需要在设计和实现时仔细权衡。
-
事件驱动设计的核心要素
- 事件源（Event Source）：产生事件的对象或系统组件。例如，用户点击按钮、传感器数据更新等。
- 事件（Event）：表示系统中发生的一个有意义的变化或动作。例如，鼠标点击事件、键盘输入事件等。
- 事件队列（Event Queue）：用于存储未处理的事件，确保事件按照发生的顺序被处理。
- 事件监听器（Event Listener）：对特定事件感兴趣的对象，负责处理事件。例如，按钮点击事件的处理函数。
- 事件调度器（Event Scheduler）：负责从事件队列中取出事件并分派给相应的事件监听器。
- 回调函数（Callback Function）：事件发生时，系统会调用预先注册的回调函数来处理事件。
-
事件驱动设计的优点
- 提高响应能力：事件驱动设计使得系统能够快速响应外部事件，提高了用户体验。
- 解耦组件：事件驱动设计通过事件和监听器的机制，解耦了事件发送者和接收者之间的联系，使得系统组件更加独立和可重用。
- 简化并发处理：事件驱动设计通常采用单线程的事件循环来处理事件，避免了多线程编程中的复杂性和潜在的死锁问题。
- 易于扩展：由于组件之间的低耦合性，新的组件可以很容易地添加到系统中，只要它们能够产生或处理相应的事件。这使得系统能够方便地适应不断变化的业务需求。
-
事件驱动设计的应用场景
- 图形用户界面（GUI）：几乎所有现代GUI框架（如Qt、Java Swing、WPF等）都采用了事件驱动设计。
- 网络服务器：许多高性能网络服务器（如Node.js 、Nginx等）采用事件驱动设计来处理大量的并发连接。
- 游戏开发：游戏中的许多交互和动画效果都依赖于事件驱动设计。
- 嵌入式系统：许多嵌入式系统（如智能家居设备、工业控制系统等）采用事件驱动设计来处理实时事件。
DDD（Domain Driven Design）
-
DDD 是通过领域划分 和领域建模等一些列手段来控制软件复杂度的方法论，主要是用来指导如何解耦业务系统，划分业务模块，定义业务领域模型及其交互。
-
领域驱动
开发过程不再以数据模型为起点，而是以领域模型为出发点，领域模型对应业务实体。
程序中主要表现为类、聚合根和值对象，更加关注业务语义的显性化表达，而不是数据的存储和数据之间的关系。
- 领域驱动的研发过程为：需求分析 ----> 领域分析 ----> 领域建模 ----> 核心业务逻辑 ----> 技术细节（DB、Cache、Message...）
- 数据驱动的研发过程为：需求分析 ----> 数据建模（ER图） ----> 建库建表，写 DAO 层 ----> 编写业务逻辑
DDD 和 MVC 对比
-
DDD 是领域驱动设计，侧重领域拆分，MVC 是软件架构设计，侧重代码拆分。
这两个是不同角度描述不同问题的，完全可以协同工作，没有谁替代谁一说。
这两者都是通用的跨语言的软件架构思想。
-
现在的微服务都是按照业务拆分的，它们可以拆出来复用，甚至做中台，广义来说也可以算是领域拆分，是一种 DDD 的思想。
-
MVC 是技术层面基于分层的软件架构，是一种范式代码分层
实体类：VO、DTO、PO、DO、Form
-
VO（View Object）：视图对象，主要对应界面显示的数据对象。
对于一个 WEB 页面，或者 SWT、SWING 的一个界面，用一个 VO 对象对应整个界面的值。
-
DTO（Data Transfer Object）：数据传输对象，主要用于远程调用等需要大量传输对象的地方。
比如一张表有 100 个字段，那么对应的 PO 就有 100 个属性。但是界面上只要显示 10 个字段，客户端用 WEB service 来获取数据，没有必要把整个 PO 对象传递到客户端，这时就可以用只有这 10 个属性的 DTO 来传递结果到客户端，这样也不会暴露服务端表结构。到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为 VO。在这里，泛指用于展示层与服务层之间的数据传输对象。
-
DO（Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。
-
PO（Persistent Object）：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应 PO 的一个（或若干个）属性。
最形象的理解就是一个 PO 就是数据库中的一条记录，好处是可以把一条记录作为一个对象处理，可以方便的转为其它对象。
-
Form ：表单对象，一般用于在 Controller 层接收前端参数。