本文中描述的应用程序分层和领域模型是我基于业务实践流程的一些想法，并与当前主流业务规格和行业的技术框架相结合，是一个实用的法规（说明文件）。规则不是规则。标准。它主要用于指导我未来的项目研发。欢迎大家参考讨论。
这是阿里巴巴Java开发手册（Songshan Edition）[工程结构]中推荐的分层结构，如下所示：
有关分层的解释，请参考原始手册文本，该文本仅在这里说明我自己的理解。
管理层主要用于将通用业务逻辑封装在服务层中以实现业务逻辑的重复使用。注意业务逻辑也是可以重复使用的组件之一。
什么是一般业务逻辑？采用一些常用的场景：
简化分层结构图：
左侧的箭头指示数据流入的方向：client-> Controller layer-> service（manager）layer-> dao layer;
右侧的箭头指示数据流的方向：dao layer-> service（manager）layer-> Controller layer-> client;
每一层（流和流）之间的数据流，其逻辑业务含义和物理数据结构并不完全相同。为了清楚地定义数据何时位于特定层时，有域模型的概念。
域模型的本质是POJO（普通的旧Java对象）。
什么是Pojo？
普通：简单；
老：老了，我曾经很好奇它为什么要老？后来我知道扩展是最原始的，最初的。
Java对象：Java对象；
POJO是最简单，最原始的普通Java对象。
什么是不寻常的Java对象？
现在，大多数技术框架将要求Java对象继承特定的类或实现特定的接口，或者需要放置各种注释。这些Java对象可以被认为是不寻常的。
字段模块由三个部分组成：
阿里巴巴Java开发手册（Songshan Edition）还提供了域模型的参考：
Internet上的内容以及每个O的每个O解释。没有对与错，每个O都有自己的原因。本文从应用程序层中数据流的角度来看，我自己的理解是我自己的理解。
查询对象用于接收控制器层方法的客户端请求参数。
例如，在查询对象序列中：
在控制器层方法中，创建查询对象有两种形式：
创建查询对象后，服务器层方法的参数可以用作服务：
在此过程中，数据由客户端流入控制器层。
注意：如果请求参数的数量很少，例如：1或2，则可以使用请求参数而无需创建查询对象。
业务对象，服务器层方法的内部逻辑处理以及向上输出业务对象（控制器层）。
以Crud中的创建为例，如果我们需要创建业务对象（BO），则可以将服务层方法分为三个步骤：
1.1查询对象映射到业务对象；
客户以创建业务对象所需的多个字段的形式流入控制器层；控制器层使用查询对象QO接收请求参数，并且QO查询对象QO流入服务层。查询对象和业务对象字段中的字段名称和字段不一定相同（取决于业务方案），因此需要映射（mapper.map）。
注意：许多开源技术框架没有讨论映射工具。
1.2业务对象的映射到数据对象（do）；
数据对象（DO）对应于数据库的数据表，请参见详细信息。综合对象和数据对象不一定是一个 - 一个，通常是一个业务对象对应于多个数据对象。
以简历对象为例，通常该简历将包括：
这些体验的数据将存储在不同的数据表中，每个数据表都对应于一个数据对象。换句话说，简历对象对应于3个或更多数据对象，因此映射（mapper.map和mapper.maper.map2表示，表示该对象。业务对象映射到不同的数据对象）。
1.3调用DAO层方法以保存数据对象；
DAO层方法将数据对象保存到相应的数据表中，然后将保存结果返回到上层。
以crud的读数为例，如果我们需要读取业务对象（BO），则可以将服务层方法分为三个步骤：
2.1调用DAO层方法以获取数据对象；
DAO层方法使用查询对象（或根据需要，将查询对象映射为适合DAO层方法的查询对象）作为参数，并读取与业务对象相对应的几个数据对象。
2.1数据对象映射到业务对象；
将数据对象映射到业务对象中，然后返回此业务对象到上层。
在此过程中，数据从控制器层流入服务层，然后通过服务层流入DAO层。然后，数据流出。
数据对象，每个数据对象对应于数据库中的数据表，用于将数据对象保存在DAO层方法中，并将数据对象输出到上层（服务层）。
DAO层数据对象的保存和读取通常由技术框架完成。不同的技术框架有不同的细节。本文不讨论相关内容。
显示对象，控制器层的请求结果返回客户端。显示对象来自服务层的数据层的数据。有三种情况：
服务层输出业务对象通常在读取方案中找到。目前，业务对象需要映射为显示对象：
客户端不需要业务对象的所有字段，或者需要组合/转换业务对象的字段以满足客户端的需求，因此需要映射；映射完成后，可以将其返回给客户端。
操作结果可以是ID，成功或失败，0或1等。通过查看创建/更新/删除场景，目前无需映射。可以根据协议（客户端和服务器协议）将具体结果返回客户端。
服务层方法的返回类型是无效的。这种情况实际上是返回的结果，例如：或不异常，根据协议返回客户，返回客户端。
注意：当DAO层方法从服务层流出时，我不会详细介绍类似的情况。
在此过程中，数据从服务层流向控制器层。然后数据流向客户端。
我知道数据传输对象是典型的DTO，用于客户和服务器之间的数据交互。有关本文的引用，我不会详细介绍。
还有另一种解释。数据传输对象不仅可以用于末端和末端之间的数据交互，还可以用于层之间的数据交互。我也同意这一点。将业务对象作为一个例子，如果我们只想查询或更新业务对象的某些字段，那么我们是否需要为仅包含该字段的一部分的这些业务对象创建一个特殊的模型对象，例如：dto.my的观点不需要，并且尽可能多地需要业务对象（请注意，不需要）。因此，如何使用业务对象来表达某些字段的业务对象？
业务对象的字段需要所有类型的对象，并且不使用基本类型。以int为例，在定义字段时使用整数：
由于业务对象字段的类型都使用对象类型，因此我们可以通过检测字段值是否为null来执行条件，并且条件基于测试结果作为条件：
建议将此要求用于所有现场模型对象。
这样做的核心目标是保持系统设计的简化。它不会引入特定的对象来解决特定的问题。尽管它会带来一定程度的复杂性，但我认为这是值得的。
[时期]流行的说法是规则的协议。它是每个人（组织/团队）并遵守规则的规则的集合；从一般意义上讲，这不是标准规则。请特别注意这一点。
此外，分层结构和现场模型的设计还提供了业务。设计的设计最终必须取决于业务效果，合适的东西是好的。