Forem: Patrick Augusto

DDD, Dependency Injection e Facade com NestJS!

Patrick Augusto — Mon, 26 Feb 2024 18:29:11 +0000

Bom dia, boa tarde, boa noite!

Hoje vou falar um pouco sobre a aplicação desses conceitos em NestJS!

O problema

Recentemente no trabalho vivi um processo interessante de desenvolvimento de uma POC (Proof of concept).

Uma POC é uma prova de conceito de algo, onde precisamos entender como vai ser o produto final, encontrando problemas que vamos ter, desafios, entre outros pontos.

Uma POC não precisa ser algo complexo ou idêntico ao produto final. Mas, um dos principais requisitos eram testes!

A questão é que se o código está ruim, os testes irão ficar horríveis e principalmente ruim de manutenção. O projeto de uma POC não é necessariamente um produto jogado fora, provavelmente será reutilizado para o produto final. Então, querendo ou não precisamos pensar no futuro.

Decisões

Eu não usei TDD, pois o problema a ser resolvido ainda estava muito nebuloso para nós, então usar TDD só poderia nos atrasar (talvez no produto final faça mais sentido).

Então eu fui codando e descobrindo as regras de negócio enquanto sujava a mão.

Chegou um momento em que o código estava uma bagunça.

Apliquei um primeiro refactor, e conforme o código foi crescendo aquilo ficou uma bagunça também.

Até que chegou um momento em que vi a necessidade de parar, refletir, e refatorar de uma forma que o código ficasse mais manutenível.

DDD

Não sou detentor de conhecimentos profundos de DDD, porém tentei aplicar ao menos o que entendo dele.

Refatorei o código utilizando alguns conceitos de DDD, principalmente o uso de Application, Domain e Infrastructure.

Cada camada ficou com responsabilidades diferentes:

Application

Aqui ficaram algumas controllers, services e validadores. Como alguns algoritmos e DTO's.

Domain

Na camada de domínio ficaram entidades do banco de dados e interfaces

Infrastructure

Nessa camada ficaram as comunicações com banco de dados e módulos de mensageria, como RabbitMq e Redis.

Dividindo o projeto dessa maneira, ficou muito mais fácil de entender onde estava cada responsabilidade, e consequentemente dividir os testes mais detalhadamente.

Depencency Injection e Facade

Injeção de dependência é um padrão de desenvolvimento de programas de computadores utilizado quando é necessário manter baixo o nível de acoplamento entre diferentes módulos de um sistema.

O Facade é um padrão de projeto estrutural que fornece uma interface simplificada para uma biblioteca, um framework, ou qualquer conjunto complexo de classes.

O uso de DI é quase obrigatório no NestJS, pois a essência dele é basicamente essa.

Agora, como foi a aplicação do pattern Facade e DI? Quase simples:

Há um injectable chamado UserEventBus que está na camada de domínio:

Obs: Um dos princípios do DDD é a separação de responsabilidades, e uma camada não precisa saber o que a outra camada está fazendo. Cada uma dessas camadas tem suas responsabilidades bem definidas e não precisa saber os detalhes de implementação das outras camadas.

Sabendo disso, veja que o UserEventBus, utiliza uma abstração do serviço de mensageria, que é basicamente uma interface:

E a forma que o Nest entende qual classe realmente vai implementar, é na configuração do provider:

Aqui eu informo pro Nest que quem usar a interface IMessageService, por baixo dos panos estará usando a classe RabbitMqService =)

Acima, implementamos o uso do pattern Facade no NestJS.

O que foi feito?

Injeção de Dependência: Para a services RabbitMqService, não está sendo usado diretamente as classes, mas sim fornecendo uma string como token ('IMessageService') e especificando a classe que deve ser usada para criar a instância quando essa dependência é solicitada. Isso é uma forma de injeção de dependência, onde o contêiner de injeção de dependência é responsável por criar as instâncias das classes baseadas nos tokens fornecidos.
Uso de Interfaces como Tokens: Ao usar strings como tokens para injeção de dependência, estamos efetivamente usando uma forma de Injeção de Dependência por Contrato. Isso significa que, em vez de depender diretamente de uma classe específica, você depende de uma interface (ou, neste caso, uma string que representa uma interface). Isso permite que você altere a implementação subjacente sem alterar o código que depende dessa interface, aumentando a flexibilidade e a manutenibilidade do seu código.
Exportação de Dependências: Por fim, foi exportado o token 'IMessageService', o que significa que essa dependência pode ser injetada em outros módulos que importam MessagingModule. Isso é uma prática comum para compartilhar serviços e repositórios entre diferentes partes da aplicação.

Aprendizados

Ao aplicar o DDD, ficou (um pouco) mais claro o uso dele e a importância. Obviamente há um mundo enorme sobre isso, mas nada que uma boa prática não ajude.

Em um projeto, é importante ter em mente que o código irá mudar. Eu mudei toda a estrutura umas 3 vezes até ficar o ideal no momento, e provavelmente pode mudar ainda mais. Não fique triste por isso, aprenda no processo.

Escrever testes te dá segurança! Tenho garantia que posso alterar qualquer camada da minha aplicação sem ter problemas, apenas deixo o teste rodando em modo watch e se eu quebrar outra camada da aplicação, saberei imediatamente!

Fim =)

Para o próximo, tentarei falar mais sobre os testes feitos.

Obrigado se você leu até aqui, se conseguiu aprender algo, deixa um emoji aí =)

Chegando a dois anos como dev, o que aprendi?

Patrick Augusto — Fri, 06 Jan 2023 17:32:25 +0000

Bom dia, boa tarde, boa noite!

Esse é o meu primeiro post no dev.to, até então eu sempre escrevia no medium. Mas, decidi trazer esse post de lá pra cá. Quem sabe eu migre completamente.

Me deu uma ideia de falar sobre algumas experiências na visão alguém que está a pouco tempo na área.

Talvez será uma leitura um pouco longa, mas espero que faça sentido pra você, leitor.

O início de tudo

Primeiro vou contar minha experiência pessoal.

Meu início como desenvolvedor foi, de certa forma, talvez atípico. Vejo muita gente na bolha que demora pra conseguir o primeiro emprego, porém eu vi a oportunidade de me tornar desenvolvedor em um local onde eu já trabalhava, então já estava imerso numa empresa de tecnologia e foi mais fácil migrar pra desenvolvedor.

Não digo isso, me referenciando a ter sido fácil. Vou explicar como foi o processo.

Meu começo na carreira profissional foi como atendente de SAC, atendendo telefone e ouvindo muito palavrão o dia todo. E, por incrível que pareça foi um ótimo aprendizado onde desenvolvi várias soft skills (falaremos disso depois).

Fiquei 9 meses nessa função, depois houve um processo interno pra uma oportunidade de trabalhar em uma área que é praticamente o “carro chefe” da empresa, onde a tecnologia acontece. Agarrei a oportunidade e fui, mas não entrei como desenvolvedor. Minha função era basicamente, um no code, mas usava muito lógica de programação mesmo sem saber.

Mas, trabalhando em conjunto com a minha área, tinha os benditos DEV’s. Os caras que fazem mágica com os dedos e fazem as coisas funcionarem.

No começo, não imaginava que eu poderia vir a ser desenvolvedor. Mas, comecei a analisar que houveram algumas pessoas que tiveram oportunidades de, sair da mesma equipe que eu estava, e virar desenvolvedor.

Sabendo disso, chamei meu chefe e falei que queria virar desenvolvedor.

Eu não sabia de nada.

Achava que HTML era uma linguagem de programação.

Mas, por incrível que pareça, ele acatou a minha epifania e se dispôs a ajudar. E comecei a estudar uma grade que eles me passaram (assim eu já estudava exatamente o que precisava pra trabalhar ali).

Depois de alguns meses, veio a oportunidade de realmente ser desenvolvedor! Não estava 100% pronto, e alguns tentaram dizer isso. Mas mesmo assim, eu botei a cara a tapa e fui. E só assim pra realmente aprender =)

E estou a quase dois anos como desenvolvedor, e por mais que seja pouco, aprendi muitas coisas. E sabendo disso, começo com o primeiro aprendizado:

Sênior pode aprender, júnior pode ensinar

Quando eu estava com alguns meses como desenvolvedor, entrou um cara super sênior na minha equipe, com mais de 30 anos como desenvolvedor e com uma enorme bagagem.

Em um primeiro momento, eu tinha certeza que quem ia ensinar algo era ele. Que no primeiro dia, ele ia me dar aulas de como fazer maconha com maisena e JavaScript.

Mas no fim, foi totalmente o contrário.

Ele não sabia nada do projeto, não sabia dos processos que nossa equipe seguia, não sabia nada. Eu ensinei ele tudo, no fim fui o professor dele durante todo o processo de aprendizado.

Mesmo ele sendo o sênior da história, abriu os ouvidos pra um júnior ensiná-lo.

Por isso, você júnior não deve ter medo de contestar, ensinar ou propor outra forma de resolver um problema. Por incrível que pareça, sua solução muitas vezes pode ser mais simples e menos custosa do que a solução que o sênior deu. Acredite em mim.

E sênior, seja humilde e ouça.

Não tenha pressa

Acredito que todos sofrem ou sofreram com isso no início de carreira.

A área de tecnologia pode ser um pouco ingrata, o que você estuda hoje pode não valer mais daqui 1 ou 2 anos, por vários motivos, seja que o hype passou, ou veio uma tecnologia melhor, ou então já ficou depreciado.

Com isso, temos muitas incertezas, de por onde começar, que caminho seguir, qual tecnologia estudar, e no fim acaba por desenvolver uma baita ansiedade e querer abraçar o mundo.

Calma!

Pega uma tecnologia e foca nela! Não importa se é PHP, JavaScript, C, C++, ou sei lá, JAVA.

Uma linguagem que é bem consolidada, não some do nada. Vai ter mercado e muito trabalho. E não caia no conto do vigário que é preciso estudar uma tecnologia X por que a Y não tem vaga.

Vai ter trabalho. Não importa se a tecnologia Y tem 5000 vagas e a X tem 10000. Você só precisa preencher 1 vaga.

É melhor que você seja bom em uma coisa do que conhecer várias coisas e não saber direito como aquilo funciona.

Seja bom em uma coisa, e depois que tiver consolidado, sai do ninho e conheça outras tecnologias.

Compartilhe conhecimento

Não guarde conhecimento pra você mesmo. Aprendeu algo novo? compartilhe com sua equipe ou até com outras equipes. Ou então compartilhe nas suas redes sociais.

E não estou falando só de assuntos técnicos. Vou dar um exemplo, temos várias automações no Trello que usamos no dia a dia (se você não conhece, dê uma pesquisada. Vai economizar muito tempo da sua equipe), e só nossa equipe utilizava. Mas vi que outras equipes também faziam tarefas repetitivas e resolvi compartilhar com todos e ensinei como fazia, até fiz alguns pra eles.

Foi algo que eu vi a necessidade que tinham, e ajudei o processo diário de outra equipe. Não precisava sair do conforto de ter aquilo só pra mim, mas isso é trabalhar em equipe.

Claro que, não é ideal chegar ‘cagando’ regras na equipe dos outros. Seja sutil e útil.

Soft skills, Marketing pessoal e network

Vou comentar brevemente sobre cada um, mas dê uma pesquisada sobre cada ponto.

Venho falando durante o texto e acho que já percebeu que nem tudo é técnico!

Não adianta você se dedicar tecnicamente e não dar atenção à soft skills, marketing pessoal e network.

Vamos falar um pouco sobre cada uma, mas todos estão bem interligados.

Soft skills

Obs: não vou detalhar sobre hard skills, mas basicamente é o conhecimento técnico.

As soft skills são um conjunto de habilidades e competências relacionadas ao comportamento humano.

Podemos listar alguns como: inteligência emocional, boa comunicação, empatia, ética, liderança, resolução de conflitos, flexibilidade, gestão de equipes, entre outros.

Então, não ignore a importância desse tópico. É preciso estar atento às próprias características, dedicado ao autoconhecimento, à melhoria contínua e à reflexão sobre as suas próprias atitudes. E fique atento, muitas empresas dão a oportunidade de desenvolver essas habilidades com treinamentos internos. Então se houver a oportunidade, abrace.

Marketing pessoal

É uma estratégia composta por ações cujo objetivo é qualificar a imagem de um profissional e seus serviços no mercado de trabalho.

Esse ponto está diretamente ligado com network.

Pouco adianta ser um ótimo profissional, com habilidades super valorizadas no mercado, se ninguém vê.

Isso vale tanto mostrar dentro da empresa o que você faz quanto mostrar o que aprendeu em estudos e projetos pessoais.

Compartilhe essas conquistas em redes como Linkedin, Twitter, ou até o Medium. E quando tiver oportunidade, compartilhe em alguma reunião oportuna com sua equipe. Se venda, tenha um objetivo, seja um bom ouvinte, seja comunicativo, honre seus compromissos, conheça novas pessoas, converse, faça 1:1, compartilhe experiências, etc.

Sei que pra vários desenvolvedores, se comunicar com outras pessoas e sair da toca pode ser muito desafiador. Mas é importante!

E falando em se comunicar com outras pessoas, entramos no próximo tópico:

Network

Sendo direto, é ter uma rede de contatos.

Vários pontos que falei acima, se encaixariam aqui. Como, conhecer novas pessoas, compartilhar experiências, entre outras.

Seja onde estiver, na faculdade, no trabalho ou em um evento sobre algo. Faça network.

Converse com pessoas e compartilhe experiências com elas. Viu algo interessante no Linkedin, interaja! E mantenha essa rede de contatos ativa, sem ser chato, claro!

Lembre-se de que as vantagens do network devem funcionar como uma via de mão dupla: além de esperar ajuda, dê suporte ao próximo!

Em algum momento oportuno você será lembrado ou lembrará de alguém.

Quero dar um exemplo pessoal do último tema que conversamos.

Recentemente um amigo (grande profissional que admiro muito inclusive), lembrou de mim para uma vaga super interessante que ele mesmo estava atrás do profissional.

Mas, isso se deu não apenas por eu ser amigo e manter o contato com ele. E sim por que um tempo antes compartilhei uma experiência pessoal que estava passando no trabalho. Onde ele me ajudou muito a decidir que caminho eu poderia seguir, e esse processo que eu estava passando se encaixava exatamente na proposta que ele tinha me oferecido.

Por motivos pessoais eu não aceitei a proposta, porém eu fui lembrado. Simplesmente pois mantive contatos.

E agora, escrevendo essa parte, lembrei de um ponto super importante que também aprendi em todo o processo:

Tenha mentores

Não estou falando pra você eleger alguém como um “mentor” fixo. Mas, tenha pessoas que você confie para pedir conselhos, seja técnico ou sobre qualquer coisa.

Você não precisa passar por todo o processo profissional sozinho, vai ter alguém que pode te ajudar independente do que estiver passando e isso vai ajudar você a evoluir e não cometer erros que poderiam ser evitados.

Conclusão

Eu tinha mais alguns tópicos a tratar, porém entrariam mais em assuntos técnicos.

Talvez eu traga em outro post, pois esse acabou (involuntariamente) indo pra um caminho mais genérico e comportamental. O que não foi ruim.

Caso tenha gostado, ou tenha alguma crítica, ou qualquer coisa. Comenta aí!

Até breve =)