共享两个不同的DTO以使用客户端模块(库)以不同的微服务以不同的方式表示相同对象是正确的吗?

发布于 2025-02-12 14:33:09 字数 1197 浏览 1 评论 0原文

目前,我正在尝试对系统中的用户进行身份验证,该用户位于用户服务中,并且还有其他两个微服务,即身份验证服务(基本上是我的网关用于身份验证)和交货服务(仅用于创建一个用于创建交付用户)。这两种服务都期望接收一个用户实体不同的用户。

用于身份验证服务的UserDTO:

public class UserDTO {
    private String email;
    private String password;

    // constructor, getters, setters
}

用于交付服务的USERDTO:

public class UserDTO {
    private String firstName;
    private String lastName;
    private String homeAddress;
    private String contactNumber;

    // constructor, getters, setters
}

根据 htttps:htttps:htttps:// wwww。 baeldung.com/java-microservices-share-dto 我发现使用客户模块来分享这些,因此我为用户服务创建了以下模块:

user-service
|__ user-client
|__ user-server
user-service
└──user-client
     UserClient.java
     UserClientImpl.java
     UserAuthenticationResponseDTO.java --- This contains the email and password fields requiered by authentication-service
     UserOrderResponseDTO.java --- This contains the fields required by the order-service

我的问题是,您认为这是我问题的好解决方案吗?我认为,当我也开始提出请求时,这也将解决问题请求我的身份验证服务

Currently I am trying to authenticate an User in my system that resides in the user-service and I have two other microservices, authentication-service (is basically my gateway used for authentication) and delivery-service (used to just create a delivery for an user). Both of these services expect to receive an UserDTO which is represents an User entity differently.

UserDTO for authentication-service:

public class UserDTO {
    private String email;
    private String password;

    // constructor, getters, setters
}

UserDTO for delivery-service:

public class UserDTO {
    private String firstName;
    private String lastName;
    private String homeAddress;
    private String contactNumber;

    // constructor, getters, setters
}

According to https://www.baeldung.com/java-microservices-share-dto I find it a good idea to use Client Modules to share these so I created the following modules for my user-service:

user-service
|__ user-client
|__ user-server
user-service
└──user-client
     UserClient.java
     UserClientImpl.java
     UserAuthenticationResponseDTO.java --- This contains the email and password fields requiered by authentication-service
     UserOrderResponseDTO.java --- This contains the fields required by the order-service

My question is, do you think this is a good solution to my issue ? I think this will also solve the issue when I will start making requests as well because for example to make a request to the delivery-service the homeAddress field should be required but I don't want to have a required homeAddress field when I make a request to my authentication-service

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

2025-02-19 14:33:09

这比任何事物都更像是个人意见,但是业务部门中的每个元素都应代表与其他元素不同的东西,并实现一个单一的目的。因此,如果身份验证和交付业务元素有不同的目的(例如,即使是指同一数据库对象),我对您的方法没有任何问题。

对于您的最后一句话,有过滤器和拦截器可以在任何交互之前,甚至在服务本身或DTO对象中验证对象。因此,除非您使用某种不可修复的字段过滤器和验证器对象,否则除非明确对其进行编码,否则您不应遇到所需的字段问题。

This is more of a personal opinion than anything, but each element in the business unit should represent something different than other elements, and serve a single purpose. So, if the Authentication and Delivery business elements serve different purposes (even if they refer to the same database object, for instance) I don't see any problem with your approach.

For your last sentence, there are filters and interceptors to validate objects in requests previous to any interaction, or even in the service itself, or the DTO object. So unless you are using some sort of unmodifiable field filter and validator object, you shouldn't run into required field issues unless you explicitly code it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文