Neste artigo, exploraremos um pouco mais deste fascinante universo da programação, no qual Clean Code, Domain-Driven Design (DDD), Clean Architecture e Screaming Architecture se unem para criar um caso de uso exemplar. Prepare-se para descobrir como práticas inteligentes de design e nomenclatura podem elevar seu código a outro nível! 

• Ao abrir o arquivo, o nome “grita” (screaming) o seu propósito antes mesmo de abri-lo. 
• Utilize a convenção de nomenclatura “kebab case”, que facilita a legibilidade na leitura dos nomes de arquivos. 
• Use o sufixo “usecase” para identificar e destacar o ícone do arquivo no editor de código. 
• Prefira a injeção de dependência do repositório “UsersRepository” para evitar o acoplamento com dependências externas e evitar casos em que o construtor é sobrecarregado de inversões de dependência (OBS.: a injeção de dependência não é o mesmo que inversão de dependência). 
• Escolha o método “Execute” da classe “UpdatePasswordUseCase” tem apenas um nível de abstração. Ao lê-lo, é como ler uma poesia. Ele também tem apenas uma responsabilidade, ou seja, apenas um motivo de mudança. 
• Lembre-se que não há quebras de linhas desnecessárias para separar conceitos lógicos. Ao invés de quebrar linhas, repense se não seria melhor extrair esses conceitos em novos métodos. 
• Importante: o método “userOfId” do “UsersRepository” é semântico e reflete a intenção do domínio: “Repositório! Me dê o usuário do id”. 
• Não lance exceções do seu domínio: “se uma falha é um comportamento esperado, você não deveria usar exceções” (Martin Fowler). 
• Ao invés de envolver as chamadas de métodos em blocos “try catch”, deixe essa responsabilidade para outra camada. Utilize uma técnica de “functional error handling”, como no caso “Either.left” para erros e “Either.right” para sucesso. 
• As regras de negócio pertencem a camada de domínio. Apenas o “Password” deve saber como validar e criar um novo password. Ele disponibiliza um “static factory method” chamado “create”, responsável por tentar criar um password com suas validações de negócio encapsuladas, sem deixar com que elas vazem para a cada de aplicação. 
• Importante salientar que na ótica do DDD, Password não é uma entidade, e sim um objeto de valor. Uma vez criado, sua natureza imutável impede que ele seja alterado. Além disso, utilizar “value objects” nos protege de uma má prática chamada “obsessão por primitivos”, que é o caso em que utilizamos tipos primitivos para tudo que poderia ser substituído por um objeto, como telefone, moeda, e-mail, endereço, coordenadas, CEP… 
• O método “updatePassword” do agregado “user” é semântico, reflete a intenção do domínio e encapsula a forma como um password é atualizado dentro do usuário. Já o método update do “UsersRepository” reflete a intenção de atualizar um agregado existente. 
• Por fim, o agregado “user” é convertido para um DTO (Data Transfer Object) para ser transferido para outra camada, deixando de ser um objeto de domínio e se transformando em um objeto de transporte por meio da chamada do “static factory method create”, da classe “UserDtoFactory”. 
• Não se esqueça: “Static Factory Method” é um design pattern que encapsula a construção de objetos. Não confunda “factory method”, “simple factory”, “abstract factory” e “static factory method”. 

A medida em que exploramos esse caso de uso, é possível absorver conceitos valiosos que transcendem a mera escrita de código. O nome do arquivo que “grita” seu propósito, a convenção de nomenclatura “kebab case,” a injeção de dependência cuidadosa e o método “execute” que se lê como poesia – esses são todos os sinais de um verdadeiro artesão na arte da programação. 

Lembre-se de que o código é a expressão da intenção, e esse caso de uso é uma obra-prima desse conceito. Práticas como encapsular regras de negócio no domínio, utilizar objetos de valor em vez de obsessão por primitivos e transformar agregados em DTOs para transitar dados entre camadas, demonstram um profundo entendimento do Clean Code e do DDD. 

Com essas dicas, os apaixonados por programação estão bem encaminhados para se tornarem verdadeiros especialistas. Continuem explorando, aprendendo e aplicando essas práticas em seus próprios trabalhos. Afinal, a programação não é apenas uma tarefa técnica: é uma forma de arte que é aprimorada com cada linha de código escrita. O mundo da programação está repleto de desafios emocionantes e descobertas. Sigam nas suas jornadas de aprendizado!  

*As opiniões aqui colocadas refletem minha opinião pessoal e não necessariamente a opinião da Compass UOL.