Você alguma vez já se perguntou sobre qual é o papel que os novos softwares exercem para o usuário final? O usuário que se deve adaptar ao software ou ao contrário? Então acredito que esse artigo te ajudará a entender um pouco mais sobre isso.
O que falarei aqui é resultado de vivências, aprendizados, tentativas, erros e acertos ao longo da minha trajetória como desenvolvedor, utilizando algumas técnicas, uma delas é conhecida como Domain Driven Design e vamos abordar aqui sobre seus pilares também.
Entendendo o cenário do usuário
A resposta para essas duas perguntas pode parecer óbvia para alguns, entretanto, não é o que acontece na prática e no dia a dia deles. Existem diversos cenários, em um deles, o usuário final se vê obrigado a aprender a utilizar o software, adaptando-o ao seu dia-a-dia, com boas práticas para conseguir usá-lo; em muitos casos isso acontece pela falta de compreensão do processo de ponta a ponta.
Um ponto muito importante nisso tudo é estabelecermos uma comunicação bilateral entre todos os desenvolvedores. Isso ajuda no entendimento do projeto que está no escopo, tornando mais fluido e assertivo, trazendo maior transparência nesse fluxo de cadência.
Para entregarmos uma solução final de valor para o usuário final, de forma mais incisiva podemos utilizar: DDD ( Domain- Driven Design)
O que é o Domain Driven Design
O DDD chegou para criar maior conexão e aproximar pessoas que desenvolvem soluções de software de maneira escalável. O perfil de desenvolvedor mudou; hoje é importante que ele seja cada vez mais multidisciplinar e não se limite a entender somente linguagem, mas que saiba também, utilizar técnicas de modelagem arquitetural para resolver gaps de operação.
O mercado vem passando por mudanças e acredito que o planejamento é a melhor saída para ter um resultado exponencial em curto, médio ou longo prazo. Acredito que se você implantar um software onde será necessário fazer manutenção diária vai ter muita dor de cabeça.
Aproximação
O DDD aproxima e cria um elo entre desenvolvedores e especialistas de domínio. Ou seja, une o programador as pessoas que realmente entendem do negócio dos quais trabalham. Nesse aspecto, a linguagem Ubíqua surge para viabilizar e melhorar os termos utilizados no dia a dia para o usuário final, onde a premissa básica é ajudá-lo na compreensão de tudo isso.
Se o cliente trata o termo: “funcionário” dentro do seu processo, devemos adotá-lo para o entendimento do código, visto que o conhecimento adquirido no levantamento deve ser o mais fidedigno possível.
Em muitos projetos onde atuei, percebi que alguns desenvolvedores traduzem termos do negócio para inglês; pode parecer uma observação pouco relevante, mas acredite: na maioria dos casos dificulta o entendimento do grupo, stakeholders e outros envolvidos no projeto, portanto a dica que eu dou é: simplifique sua comunicação
Um outro detalhe que devemos mencionar é o fato de que os novos colaboradores devem passar por uma curva de aprendizado sobre o contexto do software, seja quando ele está em processo de criação ou sustentação, isso traz vários benefícios no aprendizado sobre o negócio.
Ainda mais quando utilizamos a linguagem Ubíqua, responsável por alimentar o fluxo de vida de um negócio diante do qual o desenvolvedor está disposto a desenvolver. O que estou querendo dizer é que se em determinado contexto nasce uma “Ordem de serviço”, por exemplo, e depois de algumas etapas essa ordem vira um “Pedido” devemos seguir uma linha tênue de mesclar um mesmo ‘’objetivo’’ para o cliente.
Entendendo o Domínio
Antes de compreendermos os domínios, vale explicar o que é e como ele se comporta dentro do DDD. Ele é responsável por definir e limitar as fronteiras do negócio, encontrando especialistas de cada domínio. Através de levantamentos destas definições, é possível refinar regras de negócio de cada domínio.
Devemos ter cuidado ao analisar um domínio, afinal, não queremos que ele se torne anêmico, crescendo desproporcionalmente e sem controle.
Quando temos apenas um repositório de informações para o cliente, com dados armazenados, onde não tratamos as regras, podemos considerar que estamos partindo para o domínio anêmico.
Significado de domínio anêmico: Quando existe uma definição de um modelo, abstração desse modelo, onde é importante entender quais são os comportamentos dele, como ele se modifica.
Exemplo: CPF — eu sei dos meus dados, mas não sei para que serve, quando uso e o que isso traz de benefício, então para mim, essa informação é anêmica.
A partir do momento que utilizamos um modelo que só armazena os dados, sem indicadores, é um modelo anêmico, não tendo representatividade nenhuma.
Modelagem estratégica
Extrair a Linguagem Ubíqua vai contribuir no entendimento do negócio e no desmembramento do seu domínio em partes menores. As técnicas de criação e refinamento do modelo são importantes para entender como desenvolver um produto de valor.
Temos alguns padrões que nos ajudam a dividir nosso software em várias partes, que chamamos de contextos. Cada contexto delimitado deve estar bem claro para todos que estão envolvidos no processo de desenvolvimento.
A fronteira entre contextos deve ser clara para todos, ou seja, todos devem saber a qual
contexto um determinado pedaço de código pertence.
Mas como vamos aplicar DDD afinal?
Existem alguns padrões que nos ajudam na criação, são eles:
* Mapa de Contextos Delimitados: O mapa de contexto é uma representação, em uma imagem, para ilustrar como os domínios dos negócios se cruzam. Ele é apenas um diagrama simples, importante para se ter uma noção visual e bem definida.
* Núcleo Compartilhado: Neste item é definido um contexto compartilhado, onde os domínios irão poder conversar entre si. Na prática onde temos mais de um grupo de desenvolvimento, objetivado na entrega do negócio, onde parte da estrutura é compartilhada.
* Camada Anti-corrupção: Este tópico muito é importante, afinal muitas empresas já possuem sistemas interligados, sendo responsáveis por traduzir e adaptar as chamadas para o sistema interligado.
* Conformista: Algumas vezes pela alta demanda de desenvolvimento não podemos contar que outra equipe de desenvolvimento irá ter respostas de prioridade alta, para que possamos dar sequência ao trabalho para o consumidor, neste caso devemos assumir o papel de conformista, onde alteramos nossos sistemas para se adequar ao que já é oferecido pelo outro sistema.
Então quer dizer que devemos aplicar DDD sempre?
Essa questão é subjetiva, afinal o DDD é um modo de lidar com domínios complexos que apresenta algumas variáveis que determinam seu uso ou não, em sua base de dados. Se o domínio que deve ser atacado for simples, talvez vale considerar outras abordagens de modelagem de software ou verificar alguns detalhes para ver se ele vai funcionar corretamente.
Por via de regra, o DDD é mais bem utilizado em cenários complexos.
O DDD abrange muito mais detalhes, temos aqui um resumo, espero que seja útil! :)
Texto escrito por André Zarlenga— Desenvolvedor Platform Builders
