如果我的所有业务逻辑都在服务类中，我是否需要拥有域/实体类？答案

【问题标题】：Do I need to have domain/entity class if all of my business logic is in the service class?如果我的所有业务逻辑都在服务类中，我是否需要拥有域/实体类？
【发布时间】：2020-05-16 17:30:04
【问题描述】：

我正在开发一个没有持久层的 REST API 应用程序。我收到一个请求，做一些转换逻辑并返回响应。

在我的视图 dto 和业务逻辑服务类之间是否还需要一个域/实体层？
如果是这样，添加域层有什么好处？
是否应该使用 Mapstruct 处理复杂的映射逻辑来替换部分转换逻辑？

【问题讨论】：

无论哪种方式，拥有域模型总是让您轻松而干净abstraction, logic
你能详细说明一下干净的抽象吗？

标签： java spring-boot microservices

【解决方案1】：

在我的视图 dto 和业务逻辑服务类之间是否还需要一个域/实体层？

没有实体，用于持久化的实体有普通的域类，而DTO类实际上是用于数据传输的，即requets/resposne，域是用于某些业务层逻辑的，在DTO中我们只能放置请求/ response ，但如果有处理该请求的逻辑并且有一个域到对象模型来执行业务流程

如果是这样，添加领域层有什么好处？

领域对象（DO）（及其派生的类）实现业务逻辑，因此它们仅位于业务逻辑层/领域（即使术语不同，本质含义相同）。

是否应该使用 Mapstruct 来处理复杂的映射逻辑来替换部分转换逻辑？

我们可以使用 ModelMapper 将域对象转换为任何其他相同的对象，或者还有 Dozzer Mapper 我们也可以使用该库

Request DTO ->Controller Layer --> Service Layer --Uses business logic --> Domain Object --Convert to Response DTO --> Response DTO

【讨论】：

【解决方案2】：

如果应用程序有视图层、业务层和后端层，它的设计很好。我们不必将实体用作 POJO，而是必须有单独的实用程序类来将实体数据转换为模型和模型到实体。这会将您的业务层与数据层隔离开来。如果您对实体进行任何不会影响您的业务层的更改，反之亦然。

希望能澄清理解。

【讨论】：