Home › Design Patterns › Ubiquitous Language

Ubiquitous Language

Posted on Publicado em Design Patterns, JAVA 3.607 Comments Tagged with ,

Já faz algum tempo que alguns alunos me perguntaram o que era Ubiquitous Language, com isso me motivou a fazer este post. Espero realmente que seja útil.

Ubiquitous Language é um conceito muito comum em DDD(Domain-driven Design).

Basicamente é um dos conceitos que o DDD utiliza, que tem como finalidade: “falar” a língua do usuário/cliente . Manter uma única linguagem de domínio que seja entendível tanto para os desenvolvedores quanto para o cliente.

Vamos falar de outra forma.
No DDD você tem o Domain/Domínio que é o primeiro D, que é a parte mais “importante” desta abordagem. Pois esse domínio é exatamente o problema que queremos resolver, o problema do cliente.

Problemas
Normalmente não conhecemos a área do cliente, por isso se faz necessário o entendimento por completo ou parcial do domínio(problema do cliente).

O cliente usando a sua linguagem pede algo que pode ser entendido[isso acontece sempre] de outra forma pelo desenvolvedor ou analista.

Outro problema também seria a falta de cuidado para definição de nomes de classes, métodos, variáveis etc, causando problemas de entendimento na equipe e favorecendo ao aumento na dificuldade de manutenção dessas classes e entendimento no código.

Possível solução
Para esses “problemas” anteriores se os desenvolvedores tivessem o conceito de Ubiquitous Language bem definidos na equipe, esses problemas poderiam ser evitados. Quando se tem por exemplo uma classe chamada StrUtil.java onde muitos de nós adotamos como classes utilitárias[inclusive eu confesso, mas não da forma como passada aqui claro 😉 ] é no mínimo perigoso, pois o nome dessas classes não refletem bem a sua real função.

Mas então você defende: “- Ah mas é uma classe utilitária de strings, onde você pode fazer certas manipulações com Strings”.

Ok ! Mas muitas vezes por não tem um bom senso o desenvolvedor acaba criando uma classe UtilUtil, ou seja, essa sua classe StrUtil não está manipulando somente String ela pode está fazendo determinadas funções que são completamente diferentes, métodos que não tem nada em comum, como manipulação de datas etc, e esse é o problema.

O que o DDD com o Ubiquitous Language fala é bem simples:

Todo comportamento do seu sistema deveria estar implementado em classes cujos nomes devem fazer parte do domínio do problema, do domínio do cliente.

Isso é válido não somente para nomes de classes,mas para métodos, variáveis e tudo dentro do domínio, assim como também para o problema em si.
Esses nomes devem ter o mesmo[se não bem próximo] significado tanto para a equipe quanto para o cliente, facilitando assim a comunicação entre os mesmo, sem falar que irá melhorar muito a manutenção e entendimento do código.

Essa “linguagem” é um meio termo entre a linguagem técnica e a linguagem do cliente. O seu cliente não irá entender seu dialeto técnico e você provavelmente não irá entender[pelo menos no início] a linguagem do cliente. Assim utilizando esse conceito você irá facilitar a comunicação entre todos[desenvolvedores, analistas e cliente].

O cliente[conhecedor do domínio/problema em detalhes] deve conversar com os desenvolvedores[que possuem o conhecimento para a solução] que conhecem a programação em detalhes, para juntos, chegarem a uma língua comum, onde que todos consigam se entender e que será usada não somente nas conversas mas também no desenvolvimento do software.

Com essas conversas constantes e com a utilização desse conceito de linguagem comum, todos juntos chegarão a um consenso sobre o domínio, definindo assim o modelo do domínio[Domain Model].

Domain Model em resumo é a abstração do problema real, criada em parceria com os especialistas no domínio[normalmente o cliente e/ou analista] com os desenvolvedores.

É utilizando esse modelo que os desenvolvedores vão implementar em código[seu código irá refletir a solução para o problema do cliente], exatamente como foi acordado e as chances de cair naquele velho problema de telefone sem fio[cliente diz X, analista entende –X+2, desenvolvedor implementa Y] serão mais escassas.

Conclusão
Podemos observar que o conceito de Ubiquitous Language é bem simples, e parece que não tem muita importância, pois no resumo é apenas a padronização de nomes de métodos, classes etc, claro que tudo dentro do domínio.

Mas vimos também que não é somente isso, a idéia de Ubiquitous Language no DDD é criar um canal de comunicação entre o cliente e a principal peça: o desenvolvedor.
Pois é ele que irá criar o produto que o cliente deseja.

E através da Ubiquitous Language podemos juntamente com o cliente definir um modelo para o sistema, fazendo com o que as chances de problemas de má interpretação sejam anuladas[ou parcialmente anuladas], assim deixando o sistema mais limpo, fácil manutenção, simples alteração e de quebra, sendo entregue no prazo.

Bem espero ter conseguido explicar um pouco sobre Ubiquitous Language.

Abraços

3.607 Comments on “Ubiquitous Language”

  3. It is appropriate time to make a few plans for the future and it is time to be happy.

    I’ve read this publish and if I may I want to recommend you some
    attention-grabbing issues or suggestions. Maybe you can write next articles referring to this article.
    I want to learn even more things approximately it!

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

*

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.