我需要一些关于一些社会媒体功能的应用程序的架构的建议。
在前面，我已经搜索了互联网，但是没有找到任何有用的东西。也许在软件架构的文献中有一些很好的例子，如果有的话，我会很高兴听到他们。
我们的目标是让应用程序拥有一个单一的实体，供用户使用，并拥有一个关联的存储库。但是，从存储库请求用户的情况有两种根本不同的情况：
1.在验证过程中，应用程序的安全组件必须将用户提取为验证数据对象。在这种情况下，只需要电子邮件（和/或用户名）、口令和角色。
1.应用程序组件请求用户作为数据对象，以获取更多的用户信息，如最喜欢的书籍、爱好或蛋糕食谱。例如，在这种情况下，不需要传递密码和其他敏感数据。
因此，我的想法是实现两个不同的DTO，一个AuthUserDto用于身份验证过程，一个标准UserDto用于其他所有过程。这在逻辑上也意味着实现两个服务，一个AuthUserService和一个普通UserService。为了遵循我所知道的软件架构规则，我们将实现两个相应的服务接口。
最后但并非最不重要的是，应用程序还应该获得一个UserContextService。为了保持我迄今为止使用的命名约定，这个上下文服务应该称为AuthUserContextService，因为它负责像getCurrentUser（）或setCurrentUser（）这样的身份验证问题。
因此，最终的应用程序结构将如下所示：

Application.java
│
├───dto
│   │
│   ├───mapper
│   │       RoleMapper.java
│   │       UserMapper.java
│   │
│   └───model
│           AuthUserDto.java
│           RoleDto.java
│           UserDto.java
│  
├───entity
│       Role.java
│       User.java
│  
├───repository
│       RoleRepository.java
│       UserRepository.java
│
├───service
│   │   DefaultAuthUserContextService.java
│   │   DefaultAuthUserService.java
│   │   DefaultUserService.java
│   │
│   └───interfaces
│           AuthUserContextService.java
│           AuthUserService.java
│           UserService.java

• 当安全组件从DefaultAuthUserService请求用户时，将传递AuthUserDto。
• 当安全组件希望在DefaultAuthUserContextService的帮助下获取或设置用户时，我们将处理AuthUserDto。
• 当社交媒体组件从DefaultUserService请求用户时，将传递UserDto。

我现在要问的是：

这种方法可行吗？是否有最佳实践指南，或者是否有完全不同的更好的方法来以特定于用例的方式处理用户实体？
非常感谢任何帮助，链接和提示，以完成一个体面的基础架构。