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

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

• 我的视图dto和业务逻辑服务类之间还需要域/实体层吗？
• 如果是，添加域层有什么好处？

• 我应该使用Mapstruct来处理复杂的映射逻辑来替换转换逻辑的一部分吗？

---

如果应用程序具有视图层、业务层和后端层，那么它的设计很好。我们不必将实体用作POJO，相反，我们必须有单独的实用程序类，用于将实体数据转换为模型，将模型转换为实体。这将使您的业务层与数据层分离。如果您在实体中进行的任何更改都不会影响您的业务层，反之亦然

---

希望这能澄清我的理解。

我的视图dto和业务逻辑服务类之间还需要域/实体层吗

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

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

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

我应该使用Mapstruct来处理复杂的映射逻辑来替换转换逻辑的一部分吗

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

---

无论哪种方式，域模型总是使抽象变得简单和干净，逻辑你能详细介绍一下干净的抽象吗？

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