由DDD思想改良，基于的MVC五层架构

首先如果有的铁子想要了解一下DDD的可以乘坐飞机：
[机票](https://blog.csdn.net/wwd0501/article/details/95062535/)
严重声明，该文章只是我对目前MVC架构的一个改进方案，如果和哪个架构撞车了麻烦各位可以在评论区提出
下面开始正题

1. 介绍

   我们都之都MVC架构中在项目的创建中会分为，controller,entity,service,dao这四层基础层级，在这四层中来去处理整个项目中的业务流程和数据存取，在实际开发中，将所有的业务流程和具体的处理方案一股脑的全部写在service层中，往往会让service中的代码轻轻松松突破上千行，导致一个业务中的业务流程和业务逻辑全部都耦合在一起，不容易拆分，同时在传统的MVC架构中由没有严格的说明调用关系，导致了项目中由不少工程师在service中引用service，这样依一来就会造成众多业务无法实现解耦，所以想了很久结合DDD的思想理念和MVC有了如下的设计，基于MVC设计的五层架构理念，目的是将业务独立出来，让流程去牵动业务。

2. 架构根结构
   
   从整体的根目录可以看到项目分为了5层架构，分别为interfaces（接口层），application（应用层），model（模型层）infrastructure（基础设施层）permanent（持久层）。
   interfaces层中是将不同的接口进行接收，如常用的controller，socket等不同协议下的接口
   application层主要负责处理具体的业务流程以及要处理的业务，其中包含了如service，action等
   model层主要用于汇总所有业务所要使用的实体模型，其中包含了entity，dto，vo等不同的实体模型
   permanent层主要是对数据库进行交互，用于数据的持久话，在该层需要将不同的数据库持久区分开来，可以分为mysql，redis，mongo等不同的目录来区分
   infrastructure层主要用于将非业务相关的所有东西全部汇总起来，如config，eunms，pool等

3. 根目录隔离级别
   在该设计理念中目录间的调用级别，按照如图中的顺序进行调用，不允许出现逆向调用的情况，如下
   

4. Interfaces
   interface中可以包含多种不同协议的接口方式，一般会根据不同协议类型进行级别隔离，并且在该层级中不允许出现同层级的调用情况，也就是在interfaces这个目录内都不允许出现不同分类的调用，只可以调用application中的类，我的建议是在这里调用的是application中的service，来去完善业务的流程，具体结构如图：
   

5. application
   application中也是整个项目中业务逻辑最多的层级，项目中的几乎所有逻辑都会在这一层中处理完成，在这一层中有三个概念性的东西要熟悉一下，一个叫流程类，过渡类，一个叫业务类
   流程类就是只在这个类中的方法，只负责将业务中需要做什么介绍清楚，安排好顺序即可，不要去处理这个流程中的每一项应该如何处理，如service，task（定时任务）,httpclient等，用不同的层级来进行汇总
   业务类指的是在这个类中所有的方法，不去负责处理具体实现的流程，只需要完善各自负责的责任就可以，不用考虑流程如何进行如：action。
   过渡类就是指的在某项业务中的某个流程不能够直接调用业务类，而需要用其他的业务流程去完成业务类的调用，例如：thread
   在该级别的目录下调用顺序也同样是不允许逆向调用的，调用顺序如下图：
   
   项目中的目录结构如下图：
   

6. permanent
   permanent为持久层，这一层中对多数据源变的很友好，可以将多数据源进行分类，一般在该层中我会以数据库的名称作为目录的区分，方便快速找到想要的dao层，项目结构如下：
   

7. model
   模型层就不多少了，存放的就是不同的实体模型，直接上图：
   

8. infrastructure
   基础设施层，这一层主要是提供更多的技术支持以及全图的配置，直接上图：