DDD: Como ser um solucionador de problemas (Parte I)

Essa edição da newsletter fez uso de Inteligência Artificial na parte final, para exemplificar uma modelagem de domínio.

Já temos mais de 160 inscrições. Obrigado a você que se inscreveu na minha newsletter!

Estrutura da Newsletter

1. Apresentação
2. Comunicados
3. O que estou estudando no momento
4. O que estou criando no momento
5. DDD: Como ser um solucionador de problemas (Parte I)

Apresentação

Olá,

Seja bem-vindo(a) a minha Newsletter JS Dev. Meu nome é João Silva, trabalho com programação há mais de 3 anos e atualmente sou desenvolvedor Front End. O objetivo dessa Newsletter é compartilhar meus conhecimentos e, assim, poder ajudar a comunidade de desenvolvedores. Boa leitura!

Vamos nos conectar? Mande seu convite de conexão para o meu LinkedIn, clicando aqui.

Comunicados

• ⚠️ A live que estava prevista para acontecer na segunda, 24/06/24, foi adiada. Tive uma semana bem cheia devido a produção de um trabalho para a faculdade. Com isso, ainda não consegui concluir a trilha de Node da Rocketseat. Além disso, vou aproveitar esse tempo pra fazer alguns preparativos para que a live possa ter uma qualidade melhor (comparada a que fiz no início do ano). Assim que estiver tudo pronto, irei avisar vocês. Aproveite para se inscrever no meu canal do YouTube e da Twitch!
• Estou querendo criar um sistema que me ajude a gerar e administrar currículos otimizados para ATS (Application Tracking System). Isso inclui: criação, gestão, armazenamento e tradução automática para outra língua. O objetivo desse sistema é ajudar candidatos a administrarem melhor seus currículos para vagas e também ajudá-los a passarem pela triagem inicial do ATS. Se você usaria um software como esse, me ajude a entender como ele pode te ajudar, clicando aqui.
• Você é recrutador(a) e acha que eu poderia somar na sua empresa? Me chame no LinkedIn para batermos um papo!

O que estou estudando no momento

Continuo estudando há mais de 20 dias sobre DDD (Domain Driven Design) e Nest.JS, através da trilha Node.JS da Rocketseat. Não consegui estudar muito nessa semana por conta de um trabalho que precisei fazer para a faculdade. Na semana que vem voltarei a estudar normalmente.

Tenho o objetivo de aprofundar meus conhecimentos em Back End para transforma minhas ideias em side projects comercializáveis.

O que estou criando no momento

Assim como na edição passada, a Contenttize está engavetada indefinitivamente. Resolvi dar uma pausa nela pra poder entender melhor o momento do mercado e se realmente essa minha ideia irá ser útil. Se quiser saber mais sobre o projeto, clique aqui. Voltarei a falar dela nas próximas edições caso houver alguma novidade.

Sendo assim, não estou desenvolvendo nada no momento, focando meu tempo em estudos sobre Nest.JS.

DDD: Como ser um solucionador de problemas (Parte I)

Ano passado quando estava desenvolvendo um software para o meu TCC, me deparei com uma situação em que não tinha visto antes. Antes daquele momento, nunca tinha desenvolvido um software completo, de ponta a ponta. Eu me contentava em desenvolver apenas os desafios dos cursos de programação que fazia, basicamente um Ctrl C + Ctrl V do código do professor.

Isso era cômodo pra mim, me deixava confortável e eu achava que isso era suficiente pra minha carreira dev. Foquei meus estudos em Front End, principalmente em React.js e Next.js. Até que conseguia aplicar bastante do que aprendi no meu trabalho. Porém, estava faltando algo. Me sentia estagnado nos meus estudos.

Quando precisei fazer meu TCC, quis me desafiar. Saí da minha zona de conforto e comecei a estudar Back End. Na época, eu mal sabia fazer uma API Rest. Dediquei uns 2 meses de estudo para começar então a fazer um Back End decente, utilizando uma espécie de Arquitetura em Camadas, algo parecido com a Clean Architecture. Para isso, precisei entender e definir regras de negócio do sistema que estava propondo. No DDD, isso é denominado como o Domínio do negócio.

Design orientado a Domínio

O DDD (Domain Driven Design) nos ajuda a entender que o mais importante em um software não é o seu código, sua arquitetura ou a tecnologia usada para o desenvolvimento. Mas sim, o problema que o mesmo se propõe a resolver. Em outras palavras, o DDD nos ajuda a entender as regras de negócio para a solução de um problema.

Podemos definir o Domínio como o coração e propósito do negócio. Ele por si só já traz algumas complexidades. Por isso, precisamos nos esforçar para entender o problema à ser resolvido com o nosso software. Sem o Domínio bem definido, todo o sistema e processos auxiliares não servirão para nada. Se uma empresa existe, é porque ela tem um core business (negócio principal) e, normalmente, esse core business é composto pelo Domínio principal. Para conseguir definir o Domínio, precisamos entender de forma aprofundada o core business da empresa, conversando e compreendendo as dores das pessoas que estão envolvidas, denominadas de Domain Experts.

Domain Experts, os Especialistas do Domínio

Como dito anteriormente, para conseguir modelar o domínio corretamente, é necessário entender o core business da empresa. Para isso, precisamos nos reunir com os principais envolvidos do negócio. Nessa reunião, contamos com a presença de Domain Experts (os Especialistas do Domínio). Essas pessoas podem ser analistas do negócio, gestores, stakeholders e todos os demais usuários que possam contribuir no entendimento do negócio.

Através dessas reuniões, podemos entender também qual o linguajar técnico utilizado para se referir a algo específico do domínio. É o que chamamos de Linguagem Ubíqua.

Linguagem Ubíqua, para lidar com ambiguidades

James Shore, no Livro "The Art of Agile Development", diz:

“É um enigma. As pessoas que são especialistas no domínio – os especialistas de domínio – raramente estão qualificadas para escrever software. As pessoas que estão qualificadas para escrever software – os programadores – nem sempre entendem o domínio-problema.”

A comunicação entre os desenvolvedores e Domain Experts deve ser constante. Para que todos estejam na mesma página, é necessário reduzir ambiguidades na comunicação, através do uso de uma mesma linguagem para se referir a algo específico do Domínio. Por exemplo, se estamos desenvolvendo um software na área Financeira, provavelmente iremos utilizar termos como “Despesa, Receita, Investimento”. Isso é o que chamamos de Linguagem Ubíqua.

A Linguagem Ubíqua entra em cena construindo uma linguagem comum, compartilhada entre toda a equipe, dos desenvolvedores até os Domain Experts, indiferente de cada papel representado no Domínio.

Exemplo: Desenvolvimento de um Sistema de Gestão Hospitalar

Uma equipe de desenvolvimento de software foi contratada para criar um sistema de gestão hospitalar. Este sistema deve gerenciar várias operações, como o agendamento de consultas, alocação de leitos e administração de medicamentos. A equipe de desenvolvimento inclui desenvolvedores de software, analistas de sistemas e Domain Experts (compostos por médicos, enfermeiros e administradores hospitalares).

Os Domain Experts se reúnem com a equipe de desenvolvimento para explicar como o hospital funciona. Eles descrevem os processos de agendamento de consultas, os critérios para a alocação de leitos e os procedimentos para a administração de medicamentos.

Exemplo de Conversa:

• Domain Expert (Médico): "Quando um paciente é admitido no hospital, precisamos determinar rapidamente em qual unidade ele deve ser colocado com base na sua condição. Se for uma emergência cardíaca, ele deve ser levado diretamente para a UTI cardíaca."
• Desenvolvedor: "Então, precisamos de uma regra no sistema que priorize a UTI cardíaca para emergências cardíacas. Existem outros critérios que devemos considerar?"
• Domain Expert (Enfermeiro): "Sim, também precisamos considerar a disponibilidade de leitos e a gravidade da condição do paciente."

Com base nas discussões, a equipe de desenvolvimento começa a modelar o Domínio. Eles criam entidades como Paciente, UnidadeHospitalar e Consulta. Também definem as regras e comportamentos associados a essas entidades.

Durante as reuniões e interações, a equipe define termos específicos que serão usados consistentemente por todos (Linguagem Ubíqua).

• Paciente: Qualquer pessoa que recebe ou solicita serviços médicos no hospital.
• Admissão: O processo de entrada do paciente no hospital, envolvendo a avaliação inicial e a alocação de um leito.
• UnidadeHospitalar: Uma área específica do hospital, como UTI cardíaca, UTI pediátrica, Enfermaria, etc.
• Consulta: Um agendamento formal para avaliação ou tratamento médico.

Obrigado por ler até aqui :)

Na próxima edição, abordaremos alguns outros assuntos referentes ao DDD.

Essa edição da newsletter foi útil pra você? Clique no botão gostei e me dê um feedback nos comentários.

Até semana que vem!