Domain-Driven Design - Linguagem Ubíqua

Veranildo Veras
Nov 25, 2017 · 9 min read

Estabelecendo uma comunicação mais real

Resumo

Este é o primeiro artigo que eu escrevo, escolhi este assunto, pois entendo que é de vital importância para aplicarmos os conceitos do Domain-Driven Design, se eu conseguir transmitir para você a ideia da técnica na qual irei discorrer nas próximas linhas, ficarei muito feliz.

"Não existe uma definição clara para o Domain-Driven Design ou simplesmente DDD. Prefiro dizer que o DDD: É um conjunto de técnicas para modelagem de software".

1. Introdução

Acerca destes últimos dez anos, pude ver que, a indústria de software continua produzindo sistemas sem nenhuma qualidade, normalmente se distanciando da real necessidade do domínio no cliente “O domínio ao qual me refiro, está relacionado diretamente a uma parte do processo de negócio”. Geralmente isso ocorre pela falta de uma linguagem ubíqua, na qual todas as pessoas envolvidas pronunciam e referenciam o mesmo conceito.

2. Desenvolvimento

Quando não usamos uma linguagem comum, as identificações dos conceitos bem como os seus limites não ficam claros e explícitos, isso nos leva a alguns dos seguintes problemas:

1. O famoso caso do telefone sem fio: Eu chamo as pessoas a quem atendo na minha área de trabalho de cliente, já outros colaboradores chamam de titular, fornecedor, ClsCliente ou qualquer outra coisa, menos o que já foi dito.

2. A documentação do sistema, não reflete o negócio: Geralmente o foco é direcionado para a base acadêmica, por exemplo: Temos que construir uma classe ClsContaCorrente conforme o diagrama de classes, que irá representa uma entidade no banco de dados chamada de TbContaCorrente com os seguintes atributos e cardinalidades, também deve ser criado a classe de acesso a dados chamada de ContaCorrenteDAO com os seguintes métodos ObterPorNumero, ObterPorDescricao e etc.

3. A famosa frase, entrega com valor: Muita atenção para este item, ele impacta profundamente em quem usar metodologia ágil. Quando a documentação do sistema e o código não refletem o processo de negócio e quando não se tem os testes de unidades, a perda de tempo para entender o que foi implementado é grande, e isso ocorre principalmente quando inserimos novos colaboradores no projeto. Será que o cliente irá esperar o tempo que for necessário para que um novo colaborador adquira conhecimento suficiente para dar manutenção ou implementar uma nova solicitação? Se alguém alterar uma classe, será que isso vai dar problema em algum outro lugar no sistema? E o pior, será que o cliente tem conhecimento do que foi escrito na documentação ou código do sistema não condiz em nada com o que acontece no seu processo de negócio. E a entrega com valor, o que seria o desejo do cliente?

a) A funcionalidade entregue sem erros?

b) A funcionalidade entregue testada e sem erros, conforme o seu processo de negócio onde, qualquer desenvolvedor que olhe para o processo veja o mesmo refletido no código?

A linguagem ubíqua ou também conhecida como linguagem onipresente, é uma técnica que faz parte do bloco estratégico do Domain-Driven Design, ela nos ajuda na comunicação, contextualização, identificação, refinamento ou concepção e delimitação dos conceitos de um processo de negócio, ela nos direciona na construção do desenho de modelo do domínio do negócio. No geral, ela fortalece os laços entre o(s) especialista(s) do negócio e o time de desenvolvimento.

“Modelo do domínio bem como contexto delimitado, também fazem parte do DDD e serão abordados em um outro artigo.”

“Geralmente, o especialista do negócio é o próprio cliente (dono do negócio) ou algum colaborador (stakeholder) eleito pela empresa, que tem grande conhecimento do processo de negócio em um determinado contexto.”

“Será que alguém no mundo já construiu ou projetou algo no qual não tinha conhecimento sobre o mesmo?”

“Não existe uma formula mágica, bala de prata ou modelo de domínio perfeito para a construção de um software, o que nós desenvolvedores podemos fazer é abstrair o mínimo necessário para atender a necessidade de um contexto de negócio.”

3. Metodologia

O caso do bolo de fubá.

Alguns anos atrás, quando eu ainda era estudante do ensino fundamental, fazíamos festas na escola e cada um tinha que levar alguma iguaria, lembro-me que certa vez fui sorteado, e no meu caso a guloseima era um bolo de fubá. Queria eu saber fazer um bolo de fubá, então tive que recorrer aos universitários, e perguntei a dona Terezinha como eu faria o tal bolo. Não sabia eu que, essa senhora também não tinha grandes habilidades em fazer bolo, e assim ela me passou as seguintes informações:

Ingredientes da receita e preparo do bolo de fubá

  1. 3 ovos.

2. 1 xícara de óleo.

3. 2 xícaras de farinha.

4. 1 xícara de leite.

5. 2 xícaras de açúcar.

6. 1 xícara de fubá.

7. 1 colher de sopa de fermento em pó.

8. Obs.: se quiser, acrescente erva doce.

9. Misture tudo em uma fôrma, deixe no fogo baixo por quarenta minutos para que fique pronto.

Vamos então a fabricação do bolo, horas depois… para a minha decepção e dura realidade, não irei comentar agora como ficou o tal bolo, entenda simplesmente que não deu certo.

Então o que faltou? Por que não deu certo?

1. A farinha: Faltou mais conhecimento do negócio/processo ou aplicação da técnica de elicitação, esse insumo deveria ser do tipo trigo. Opa insumo? Mas, em que momento no requisito se usou essa palavra? Me desculpe, esqueci do uso da linguagem onipresente, eu deveria ter dito ingrediente.

2. O óleo: Nós poderíamos ter fundamentado também este item na comunicação, o óleo para o preparo da massa do bolo não pode ser de qualquer tipo, esse ingrediente deveria ser do tipo soja.

3. A mistura: A técnica de etnografia, premissas e restrições da elicitação também cairiam bem neste item, já que a mistura dos ingredientes não pode ser feita na mesma fôrma que irá ao forno.

  • Os ingredientes deveriam ter sido misturados fora da fôrma até ficar em estado de massa homogênea. A massa estando pronta, colocar em uma fôrma de tamanho adequando.
  • A fôrma estando com a massa, levar ao forno e deixa ao fogo baixo por quarenta minutos. Após quarenta minutos, o bolo está pronto.

Deu para entender?

Normalmente o que veríamos seria os seguintes conceitos, por exemplo:

4. Modelagem

Quando na realidade o processo nos expõe mais abstrações, por exemplo:

Todas essas classes se comunicam através de mensagens, e fazem o processo da forma que foi exposto. O ponto que é realmente importante, não é o projeto das classes e sim as abstrações dos conceitos do negócio.

E por falar nisso, no meu caso, a falta de comunicação e conhecimento me prejudicou no processo, e me levou a fazer um bolo de farinha, queimado, duro mais parecido com um pneu velho.

5. Exemplo de codificação

Observemos outros exemplos:

1º) Código sem a linguagem:

package br.com.empresa.erp.dominio.entidade

public class Cliente {} – Considere a classe de clientes
public class Pedido {} – Considere a classe de pedidos com associação para a classe de cliente

package br.com.empresa.erp.infraestrutura.dto

public class ClienteDto {} – Considere a classe de transferências dos dados
public class PedidoDto {} – Considere a classe de transferências dos dados

package br.com.empresa.erp.infraestrutura.servicos

public interface Transferencia {
List<PedidoDto> getPedidos(Calendar dataInicio, Calendar dataTerminio);
List<ClienteDto> getClientes(Calendar dataInicio, Calendar dataTerminio);
}

public class TranferenciaImp implements Transferencia {
public List<PedidoDto> getPedidos(Calendar dataInicio, Calendar dataTerminio) {}
public List<ClienteDto> getClientes(Calendar dataInicio, Calendar dataTerminio) {}
}

2º) Código aplicado a linguagem:

packager erp.centralDeAtendimento.dominio.entidade

public class Cliente {} – Considere a classe de cliente
public class Faturamento {} – Considere a classe de faturamento com associação para a classe de cliente

packager erp.centralDeAtendimento.dominio.objetoDeValor

public class Periodo {} – Considere a classe de período

packager erp.centralDeAtendimento.infraestrutura.dto

public class FaturamentoDto {} – Considere a classe de transferências dos dados

packager erp.centralDeAtendimento.infraestrutura.servico.contrato

public interface TransferenciaFaturamento {
List<FaturamentoDto> Faturamento(Periodo periodo);
}

packager erp.centralDeAtendimento.infraestrutura.servico

public class TransferenciaParaExpedicao implements TransferenciaFaturamento {
public List<FaturamentoDto> Faturamento(Periodo periodo) {}
}

Eis a especificação técnica dos códigos acima e o desejo do meu cliente:

História de usuário

A central de atendimento através do seu ERP quer fornecer um serviço de transferência dos dados dos faturamentos e clientes, em um determinado período para a área da expedição.

Independente da linguagem de programação que usamos para escrever os códigos dos exemplos, qual deles ficou mais alinhado ao negócio?

Atentemos a mais um exemplo, agora conforme uma imagem de um processo de negócio em um contexto:

Uma possível abstração em código do processo acima:

Você talvez esteja pensado, mais isso vai me dar um trabalho enorme! E eu vos digo, em um mundo não muito distante, um CRUD “Create, read, update e delete” vai lhe dar muito mais dor de cabeça e trabalho.

Outra coisa que eu posso lhe assegura é que: Qualquer desenvolvedor que olhe para um processo de negócio e depois veja o mesmo feito em código, levará menos tempo para analisar e se posicionar quanto ao contexto, isso é um reflexo até mesmo para a documentação do sistema “Favor ver manifesto ágil: Software em funcionamento mais que documentação abrangente”.

Torne-se um especialista do negócio, entenda, aprenda, fomente o que não tem consenso, o que não está claro/fundamentado ou o que geralmente tem ambiguidade e provoca confusões, use as técnicas da POO, SOLID, Designer Patterns, Código Limpo etc., para implementar no seu código todos os verbos, substantivos, adjetivos, termos linguísticos e jargões utilizados pelo o seu cliente. Caso exista um conflito ou não exista um consenso, fundamente um vocábulo e deixe claro para todas as pessoas envolvidas.

“Procure implementar no seu código o dialeto linguístico (Inglês, Espanhol, Francês, Português e etc.) que o seu cliente usa.”

Há muito tempo atrás, eu conheci um programador com o seguinte hábito: Depois que ele estava com o seu código pronto, fazia um backup do arquivo e logo em seguida passava um ofuscador de código no arquivo original, deixava o arquivo ofuscado para quem irai dar manutenção. Em seguida, esse mesmo programador saiu da sala dizendo: Vou saber quem é um bom programador, quem conseguir entender o algoritmo que acabo de escrever.

“Qualquer tolo consegue escrever código que um computador entenda. Bons programadores escrevem código que humanos possam entender.” (Martin Fowler)

Conclusão

A linguagem ubíqua deve ser utilizada sem moderação, a comunicação é fundamental para o conhecimento do negócio, devemos focar os nossos esforços naquilo que tem maior valor “O negócio” e utilizar a abstração para expressar no código tudo que acontece no processo de negócio.

Espero que este artigo possa lhe ajudar para o seu entendimento sobre a linguagem ubíqua exposta no domain-driven design, até o próximo artigo.

Sugestões:

Para aplicarmos bem os conceitos e técnicas do Domain-Driven Design, devemos ter bons conhecimentos em:

  • Programação orientada a objetos.
  • Princípios SOLID.
  • Padrões de projeto (Gang of Four — Design Patterns).
  • Desenvolvimento guiado por teste (Kent Beck — Test-Driven Development)

Para enriquecer ainda mais o seu conhecimento sobre este assunto, sugiro a leitura dos livros:

  • Fowler, Martin (2002) — Patterns of Enterprise Application Architecture. Addison-Wesley Professional ISBN: 978–0321127426
  • Evans, Eric (2003) — Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional ISBN: 978–0321125217
  • Vernon, Vaughn (2013) - Implementando o Projeto Dominado pelo Domínio. Addison-Wesley Professional ISBN: 978-0321834577

    Veranildo Veras

    Written by

    Desenvolvedor de sistemas, focado em boas práticas da engenharia de software.

    Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
    Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
    Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade