Fala Galera, bão?
Continuando a nossa série sobre DDD - Domain Driven Design, irei escrever hoje sobre um dos pilares que é Ubiquitous Language, ou seja, a Linguagem Onipresente.
O conceito de UL é uma prática que incentiva a utilização do mesmo vocabulário entre os desenvolvedores e o especialista do domínio. Isso melhora muito a comunicação e ajuda eliminar qualquer incerteza ou ambiguidade que possa existir. Além disso, ajuda a aproximar cada vez mais os experts do domínio no ciclo de desenvolvimento, facilitando qualquer debate ou dúvida que venha a ter na construção do software.
Quer um exemplo? Digamos que você é o expert do domínio e está ajudando os programadores a desenvolver um software de Reservas de vôos. Olhe o UML abaixo:
Provavelmente qualquer profissinal que lide com reservas de vôos consegue entender o que estamos tentando descrever nessa imagem, pois é uma linguagem que faz parte do dia a dia dele. Cada classe descrita nessa UML ajuda esse profissional a associar com o domínio que ele exerce. Essa fidelidade com o mundo real é exatamente o que nós desenvolvedores temos que trazer para a modelagem das nossas classes, afinal podemos utilizar nosso código como uma maneira de documentar o software, correto?
Eric Evans explica no seu livro como utilizar essa linguagem:
"Use o modelo como a espinha dorsal da linguagem. Comprometa a equipe a exercitar essa linguagem de forma implacável em todas as comunicações feitas dentro da equipe e no código. Use a mesma linguagem em diagramas, na escrita e principalmente na fala."
Sabe aquela citação do Buiú developer que falei no meu último post? Acredito que tenha surgido daqui a interpretação de que DDD é apenas colocar regra de negócio no domínio. Mas não trata-se apenas disso, vai muito além. A ideia é utilizarmos uma linguagem única no modelo para deixa-los ricos e expressem muito bem toda a complexidade do seu domínio.
Eric ainda diz:
"Reconheça que uma mudança ocorrida na LINGUAGEM ONIPRESENTE é uma mudança no modelo. Os especialistas do domínio devem fazer objeção a termos ou estruturas que sejam estranhos ou inadequados para transmitir a compreensão do domínio."
Deu perceber o quão é importante essa linguagem? A ideia é que os especialistas do domínio participem a ponto de ler o UML de suas classes e apontem as divergencias dela com o mundo real. Vamos lá, sabemos que isso na selva no mercado de trabalho é difícil para não dizer impossível. Então nós desenvolvedores assumimos esse papel de entender muito bem o domínio e expressá-lo para a modelagem de classes com fidelidade.
Faça um exercício, você como desenvolvedor consegue explicar para um analista de negócio sobre o domínio com todos os detalhes de modo que ele entenda perfeitamente? Ótimo, esse é o primeiro passo para aplicarmos o DDD em nossos projetos, agore modele suas classes com o máximo de fidelidade possível.
Deu pra entender? ficaram com dúvidas? tem sugestões? comente aí embaixo, será um prazer ouvir vocês. :)