Solucionado (ver solução)
Solucionado
(ver solução)
4
respostas

Dúvida Dto

Na controller, onde foi feito new Usuario(dto.cpf(), dto.nome(), dto.nascimento(), dto.email()); eu poderia deixar isso no UsuarioDto ou estaria "errado" de acordo com a clean architecture?

    @PostMapping
    public UsuarioDto cadastrarUsuario(@RequestBody UsuarioDto dto) {
        Usuario salvo = criarUsuario.cadastrarUsuario(new Usuario(dto.cpf(), dto.nome(), dto.nascimento(),
                dto.email()));

        return new UsuarioDto(salvo.getCpf(), salvo.getNome(), salvo.getNascimento(), salvo.getEmail());

    }

Ficando assim:

public record UsuarioDto(
        String cpf,
        String nome,
        LocalDate nascimento,
        String email
) {
    public Usuario converterParaUsuario() {
        return new Usuario(cpf, nome, nascimento, email);
    }
}
4 respostas

Olá Gabriel! Tudo bem?

Sua dúvida é bastante pertinente no contexto da Clean Architecture.

A ideia de mover a lógica de conversão de um DTO para a entidade diretamente dentro do DTO, como você sugeriu com o método converterParaUsuario(), pode parecer conveniente, mas vamos analisar sob a perspectiva da Clean Architecture.

A Clean Architecture sugere uma separação clara entre as camadas da aplicação, mantendo especialmente a lógica de negócio e as regras da aplicação isoladas de frameworks e detalhes de infraestrutura, como a camada de apresentação onde os DTOs geralmente residem. O objetivo é garantir que o núcleo da aplicação (entidades e casos de uso) não seja influenciado por mudanças externas, como alterações em frameworks ou bancos de dados.

Ao colocar a lógica de conversão dentro do UsuarioDto, você estaria, de certa forma, misturando responsabilidades que pertencem à camada de domínio (a criação de entidades) com a camada de infraestrutura/adaptação (DTOs). Isso pode levar a uma violação dos princípios da Clean Architecture, onde cada camada deve ter responsabilidades bem definidas e isoladas.

Uma abordagem mais alinhada com a Clean Architecture seria manter a lógica de conversão fora dos DTOs, possivelmente em um componente dedicado que poderia ser um conversor ou mesmo dentro dos casos de uso, onde você recebe o DTO, converte para a entidade e então prossegue com as operações de negócio. Isso mantém a camada de domínio pura e desacoplada de detalhes específicos de como os dados são recebidos ou enviados pela aplicação.

Exemplo:

public class UsuarioConversor {
    public static Usuario converterDtoParaUsuario(UsuarioDto dto) {
        return new Usuario(dto.cpf(), dto.nome(), dto.nascimento(), dto.email());
    }
}

E no seu controller, você usaria esse conversor:

@PostMapping
public UsuarioDto cadastrarUsuario(@RequestBody UsuarioDto dto) {
    Usuario usuario = UsuarioConversor.converterDtoParaUsuario(dto);
    Usuario salvo = criarUsuario.cadastrarUsuario(usuario);
    return new UsuarioDto(salvo.getCpf(), salvo.getNome(), salvo.getNascimento(), salvo.getEmail());
}

Dessa forma, você mantém a separação clara de responsabilidades e adere aos princípios da Clean Architecture.

Espero ter ajudado e bons estudos!

Caso este post tenha lhe ajudado, por favor, marcar como solucionado ✓.

Olá Armano, tudo bem! E esse UsuarioConversor fica em qual package, infra -> gateways? E poderia ter tmb nessa classe um metodo que converte Usuario (classe de dominio) para UsuarioEntity (classe de persistencia) ou isso seria um outro conversor? Ex:

    public static UsuarioEntity converterDtoParaUsuarioEntity(Usuario dto) {
        return new UsuarioEntity(dto.getCpf(), dto.getNome(), dto.getNascimento(), dto.getEmail());
    }

Bom dia, Gabriel!

Quanto à organização do UsuarioConversor, o ideal é colocá-lo em um pacote que faça sentido dentro da sua estrutura de projeto. Na Clean Architecture, você pode considerar colocá-lo em um pacote dentro da camada de aplicação ou até mesmo na camada de domínio, dependendo de como você estruturou seu projeto.

Quanto à inclusão de um método para converter Usuario para UsuarioEntity, isso pode ser feito na mesma classe UsuarioConversor, desde que faça sentido para a sua aplicação. Essa classe pode ser responsável por todas as conversões relacionadas a Usuario, independentemente de serem para DTOs ou entidades de persistência.

A inclusão desse método na classe UsuarioConversor seria algo como:

public class UsuarioConversor {
    public static Usuario converterDtoParaUsuario(UsuarioDto dto) {
        return new Usuario(dto.getCpf(), dto.getNome(), dto.getNascimento(), dto.getEmail());
    }
    
    public static UsuarioEntity converterUsuarioParaUsuarioEntity(Usuario usuario) {
        return new UsuarioEntity(usuario.getCpf(), usuario.getNome(), usuario.getNascimento(), usuario.getEmail());
    }
}

Assim, você mantém todas as conversões relacionadas a Usuario em um único lugar, o que ajuda na organização e na manutenção do código.

Lembre-se de adaptar a estrutura e a organização do código conforme as necessidades específicas do seu projeto e com as diretrizes da Clean Architecture que você está seguindo.

Se precisar de mais alguma ajuda ou tiver outras dúvidas, estou à disposição!

solução!

Armano muito obrigado pelo suporte e por esclarecer minhas duvidas! Valeu!

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software