ps: 前段时间需要对老的功能开放openApi。类似于下图的需求：不看不知道，一看吓一跳：居然直接把所有业务全放在web的controller里面。service里面就单纯的调了下dao。原本直接编写openApi的接口，直接调原有的接口即可，现在直接需要把业务重写一遍。interesting！！！
1、MVC分层
在传统应用程序中，我们通常采用经典的MVC（Model-View-Controller）架构进行开发，它将整体的系统分成了 Model（模型），View（视图）和 Controller（控制器）三个层次，也就是将用户视图和业务处理隔离开，并且通过控制器连接起来，很好地实现了表现和逻辑的解耦，是一种标准的软件分层架构。
在遵循此分层架构的开发过程中，我们通常会建立三个Maven Module：Controller、Service 和 Dao，它们分别对应表现层、逻辑层和数据访问层，如下图所示：
2、Vo | Dto | Entity
简单粗暴的用法--见上图
VO（View Object）：视图对象，主要对应界面显示的数据对象。它的作用是把某个指定页面（或组件）的所有数据封装起来。如果是一个DTO对应一个VO，则DTO等价于VO;但是如果一个DTO对应多个VO，则展示层需要把VO转换为服务层对应方法所要求的DTO，传送给服务层，从而达到服务层与展示层解耦的效果。对于一个WEB页面，或者SWT、SWING的一个界面，用一个VO对象对应整个界面的值。
DTO（Data Transfer Object）：数据传输对象，主要用于远程调用等需要大量传输对象的地方。比如我们一张表有100个字段，那么对应的PO就有100个属性。但是我们界面上只要显示10个字段，客户端用WEB service来获取数据，没有必要把整个PO对象传递到客户端，这时我们就可以用只有这10个属性的DTO来传递结果到客户端，这样也不会暴露服务端表结构.到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为VO。在这里，我泛指用于展示层与服务层之间的数据传输对象。
Entity(Po) : 持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。最形象的理解就是一个PO就是数据库中的一条记录，好处是可以把一条记录作为一个对象处理，可以方便的转为其它对象。
3、MVC的缺点
在业务逻辑较为简单的应用中，MVC三层架构是一种简洁高效的开发模式。然而，随着业务逻辑的复杂性增加和代码量的增加，MVC架构可能会显得捉襟见肘。其主要的不足可以总结如下：
- Service层职责过重：在MVC架构中，Service层常常被赋予处理复杂业务逻辑的任务。随着业务逻辑的增长，Service层可能变得臃肿和复杂。业务逻辑有可能分散在各个Service类中，使得业务逻辑的组织和维护成为一项挑战。
- 过于关注数据库而忽视领域建模：虽然MVC的设计初衷是对数据、用户界面和控制逻辑进行分离，但它在面对复杂业务场景时并未给予领域建模足够的重视。这可能导致代码难以理解和扩展，因为代码更像是围绕数据库而不是业务需求进行设计。
- 边界划分不明确：在MVC架构中，顶层设计上的边界划分并没有明确的规则，往往依赖于技术负责人的经验。在大规模的团队协作中，这可能导致职责不清晰、分工不明确等问题。
- 单元测试困难：在MVC架构中，Service层通常以事务脚本的方式进行开发，并且往往耦合了各种中间件操作，如数据库、缓存、消息队列等。这种耦合使得单元测试变得困难，因为要在没有这些中间件的情况下运行测试可能需要大量的模拟或存根代码。
如何解决：DDD（Domain-Driven Design，领域驱动设计）
转载一下大佬的知乎链接：DDD-领域驱动设计
