Ubiquitous Language

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

Be Sociable, Share!

9 Comentários so far »

  1. João Paulo said

    am fevereiro 3 2009 @ 3:36 pm

    Muito elucidativo, parabéns professor e estou no aguardo do retorno da turma de java. Um abraço!

  2. Rafael Ponte said

    am fevereiro 3 2009 @ 5:26 pm

    Nada melhor que a própria definição do autor: “A language structured around the domain model and used by all team members to connect all the activities of the team with the software.”

    O que seus alunos precisam realmente entender é que Ubiquitous Language não é uma linguagem utilizada apenas no código, porém em qualquer atividade (documentação, especificação, testes, código, conversas entre a equipe e especialistas etc) durante o desenvolvimento do software.

    Vale lembrar também que UL e domain-model são a cerne de Domain-Driven Design.

    Post bacana, parabéns!

  3. Handerson Frota said

    am fevereiro 3 2009 @ 5:36 pm

    @João Paulo
    Obrigado cara que bom que consegui passar direitinho.

    @Rafael Ponte
    Exatamente, como falei um pouco na metade do post. Não é somente para o código, ele reflete no código, pois ela é aplicada antes do código, utilizada nas conversas entre o cliente e a equipe, e no final acaba refletindo no código.

    Não adianta aplicar UL no código se não está aplicando isso na equipe quando ela vai se comunicar com o cliente[documentos, casos de uso e tudo que você falou].

    Obrigado.

  4. Paulo Junior said

    am fevereiro 3 2009 @ 6:12 pm

    De fato, sabe que por sinal eu e o Antônio Junior estavamos dando uma olhada nesse negócio XD.

  5. Handerson Frota said

    am fevereiro 4 2009 @ 6:48 am

    @Paulo Junior
    Massa cara, se quiser colocar algo para incrementar meu post fique a vontade..o que você achou ? etc.

    Abraços

  6. Marcio Duran said

    am agosto 28 2009 @ 7:30 pm

    Parabéns !!!

    Ótima explicação…

  7. Como você define qualidade de software? said

    am fevereiro 11 2010 @ 5:05 am

  8. BDD – Behavior Driven Development « QualidadeBR said

    am junho 13 2010 @ 12:38 pm

    [...] apenas na mesma página, mas também estão usando as mesmas palavras. BDD pode ser considerada uma Ubiquitous Language (“Linguagem [...]

  9. Norberto Oliveira Junior said

    am agosto 19 2010 @ 8:14 pm

    Parabéns. Muito bom. Muito bem explicado.

Comment RSS · TrackBack URI

Deixe um comentário

Name: (Required)

eMail: (Required)

Website:

Comment: