Se a camada de dentro não pode usar a de fora, como eu usaria o Lombok e o bean validatio então?
Se a camada de dentro não pode usar a de fora, como eu usaria o Lombok e o bean validatio então?
hoje, com a Alura e o Google Gemini
Oi Victor,
Esse é um dos problemas do clean architecture, pois se a gente quiser seguir "a risca", vai acabar passando por situações como essa, na qual utilizar alguma biblioteca nas camadas internas estaria ferindo as regras.
Eu consideraria o Lombok como parte do "java" e não vejo problema de adicionar as anotações dele nas classes de domínio. Afinal, ele apenas gera códigos java nas classes.
No caso do Bean Validation eu não gosto de utilizar nas classes de domínio e sim nos DTOS, que estariam na camada externa, então não teria problemas.
Bons estudos!
Olá! Na minha experiência com clean arch, eu crio as classes representativas de tabelas banco de dados (que não são as mesmas do dominio) e a mesma coisa para as classes de API REST (classes que representam o json). Nessas classes representativas, é onde coloco anotações de validation, jackson, JPA, etc. Assim as classes de domain ficam "limpas" dessas tecnologias. Ai é necessário ter classes mappers que transformam as classes representativas em DTO e/ou domains: Tanto de JSON -> mapper -> DOMAIN e DOMAIN -> mapper -> JSON. Sendo que DOMAIN nunca deve conhecer as representativas (JSON, mapper, etc).
Quanto o uso do lombok, eu uso em tudo. Inclusive nas classes de domain... mais por facilidade. E anotações de framework como Spring, eu anoto os usecase como @Service.. mesmo não sendo recomendado, mas ja facilita essa configuração e uso do framework (ninguém merece configurar via XML...). Enfim, são riscos assumidos que ganho em tempo de implementação! Mas se for necessário mudar (de spring pra outra) não fica tão dificil remover tais anotações! :)