Duas dicas em questão de código:

  • Tente manter a conformidade entre a nomenclatura das classes/métodos.
    • Há a mistura do português com o inglês, como é o caso de createClienteAddress.
    • Em determinado momento, o cliente passa a ser chamado de User, defina qual será a nomenclatura padrão.
  • Algumas classes podem ser substituidas por record o que lhe torna possível tirar o @AllArgsConstructor e consequentemente a dependência do Lombok.

Sobre a resolução do caso em si: Parece que a falha está no DDL do Banco de Dados. Só faz sentido existir um endereço se ele está vinculado a um cliente, logo: 1. client_id deverá ser NOT NULL e/ou 2. a Primary Key deve ser uma chave composta com o próprio address_id e o client_id (isso significa que não pode existir um endereço sem um cliente).Tendo resolvido isso, nem será possível adicionar novos registros se não estiverem em conformidade com essas regras e estourará Exception se tentar.

Se este registro tiver sido feito anteriormente e só quer correção, sugiro remover o registro e adicionar novamente OU fazer a inserção manual da edição direto no SQL.

Última dica: Parece que desenhou pouco como vai ser a solução, do que precisa ou não. Não parece nem ter um desenho claro do Banco de Dados, recomendo parar de colocar a mão no código um pouco e desenhar o DER e pelo menos um modelo de UML de como será o fluxo do processo.

guardareaishá 6 meses

Isso foi apenas um teste mesmo, pois está totalmente inglês o código-fonte. Apenas estou fazendo um projeto demo para demonstrar o meu objetivo, por isso que inclui lombok para uma produtividade melhor (pois não gosto de bibiliotecas de terceiros no código).

Arquitetura:https://prnt.sc/6oSSS-hKEv_x Diagrama: https://prnt.sc/mUT8cxgHmvdq

Agora pourco fiz outro teste e sinto que está errado:

@RestController
@RequestMapping("/users")
@AllArgsConstructor
public class UserController {
    private final UserService service;

    @PostMapping("/")
    public ResponseEntity<User> createUser(@RequestBody User entity) {
        return ResponseEntity
                .status(HttpStatus.CREATED)
                .body(service.createUser(entity));
    }

    @PostMapping("/{userId}/address")
    public ResponseEntity<Address> createAddress(@PathVariable UUID userId,
                                                 @RequestBody Address entity) {
        return ResponseEntity
                .status(HttpStatus.CREATED)
                .body(service.createAddress(userId, entity));
    }

    @GetMapping("/{userId}")
    public ResponseEntity<User> getUserById(@PathVariable UUID userId) {
        return ResponseEntity
                .status(HttpStatus.OK)
                .body(service.getUserById(userId));
    }

    @GetMapping("/{userId}/{addressId}")
    public ResponseEntity<Optional<Address>> getAddressById(@PathVariable UUID userId,
                                                            @PathVariable UUID addressId) {
        return ResponseEntity
                .status(HttpStatus.OK)
                .body(service.getAddressById(userId, addressId));
    }
}
Kaindallhá 6 meses
Bom, aparentemente a abordagem parece estar correta. Só falta um refinamento no DER, como por exemplo as regras aplicadas na camada física, PKs e FKs. Além de uma coisa que não ficou claro, o User (administrator) vai criar o perfil dos clientes (customers), entretanto, como os próprios customers irão se logar? Não parece ser previsto nesse modelo que você desenhou.
guardareaishá 6 meses
Bem, agora melhorei os controllers separando pelas responsabilidades: ``` package com.example.demo.core.presentation.resources; import com.example.demo.core.domain.Address; import com.example.demo.infrastructure.gateway.services.UserAddressService; import lombok.AllArgsConstructor; import org.springframework.http.HttpStatus; import org.springframework.http.ResponseEntity; import org.springframework.web.bind.annotation.*; import java.util.UUID; @RestController @RequestMapping("/users") @AllArgsConstructor public class UserAddressController { private final UserAddressService service; @PostMapping("/{userId}/") public ResponseEntity
createAddressInUser(@PathVariable UUID userId, @RequestBody Address entity) { var createdAddress = service.createAddressInUser(userId, entity); return ResponseEntity .status(HttpStatus.CREATED) .body(createdAddress); } @GetMapping("/{userId}/{addressId}") public ResponseEntity
getAddressInUserById(@PathVariable UUID userId, @PathVariable UUID addressId) { return ResponseEntity .status(HttpStatus.OK) .body(service.getAddressInUserById(userId, addressId)); } } ``` Então está correta abordagem? Procurei em diversos artigos, stackoverflow até tutoriais de youtube e não tem nenhum conteúdo como ensina a vinculação assim entre front-end e o back atraves de endpoints após usuário já criado no banco de dados. Sim, pelo visto vou ter recriar, pois entendi que os customer na verdade são os users, a diferença é que eles vão ter roles diferentes.
Kaindallhá 6 meses
Eu já vi conteúdo que explica isso, só não lembro aonde. O Telegram tem muito "conhecimento sem certificado". Mas não entendi a sua dúvida, pois a conexão do frontend com o backend através de endpoints é isso o que está fazendo, sendo isto que estamos discutindo, especificamente, o backend. Depois de criado com POST, é só consultar com GET, editar com PUT ou remover com DELETE, não tem muito segredo, aí o front consome estes métodos do backend dependendo das suas restrições de negócio.
guardareaishá 6 meses
Entendi, então outra dúvida: Fazendo esse tipo de implementação, o controller do address solo é algo que não precisa criar? pois seria algo inutil. Apenas estava com bastante duvida, pois perguntei em diversos forums, principalmente no reedit: learn java e falaram que estava incorreta essa lógica.