6 min read Arquitetura de Software

Como construir uma linguagem única ?— DDD Parte 1

Como construir uma linguagem única ?— DDD Parte 1

Se eu te disser que existe uma metodologia de design de software que mantém o conhecimento de domínio e o código de seu sistema em sincronia, evitando assim problemas de entendimento por entre os integrantes, você acreditaria?

Neste artigo, iremos passar por um dos principais pontos do DDD, utilizando de seus elementos e mindset. O exemplo utilizado será enriquecido e levado para outros artigos desta série. Vamos começar?

O que é DDD?

Domain-Driven Design é uma “metodologia” para o design de software baseado no domínio. Embora eu tenha literalmente traduzido o significado da sigla, não existe explicação mais direta: desenhar meu software a partir do contexto do domínio e negócio no qual estarei inserido. Sua primeira aparição na literatura foi com o famoso “Livro Azul” de Eric Evans, com sua primeira edição publicada em 2003.

O próprio Evans, em uma entrevista com a InfoQ em 2016, nos diz o que é o DDD:

“Em sua essência, o domain-driven design é uma maneira de usar modelos para criar software, especialmente a parte do software que trata regras de negócio complexas em forma de comportamento.”

Evans usou como base sua experiência, e chegou a fazer alguns ensaios sobre o assunto anos antes da publicação deste livro. A abordagem endossa a utilização de alguns conceitos e padrões no momento do desenho do sistema, e sugere que este desenho seja feito com esforço conjunto entre a equipe técnica e especialistas de domínio.

Como a metodologia acaba utilizando de alguns design patterns já conhecidos no mercado, muitos desenvolvedores são incentivados erroneamente a pularem etapas do aprendizado para simplesmente entender como os padrões são aplicados na prática.

Tá. Mas o que é um Domínio?

O Domínio é o conceito mais vital para o DDD. É o escopo do problema em que estamos desenvolvendo o sistema. É nele que descrevemos todas as entidades, comportamentos e regras de negócio que iremos aplicar em nosso sistema.

Cada projeto, empresa e sistema tem seu próprio Domínio e Subdomínios.

Um Domínio pode representar:

  • A esfera de conhecimento de um problema/empresa
  • A totalidade do domínio de uma empresa
  • O principal negócio de uma companhia
  • Uma área, setor ou processo dentro de uma companhia

Qual o objetivo do DDD?

Softwares são produtos complexos e demandam muito trabalho para serem concebidos, desenvolvidos e mantidos. Existem algumas características que nos permitem agrupar essas complexidades em alguns tipos, como:

  • Complexidade Técnica: Aquela que se refere à implementação técnica da solução. Aqui é onde entra o ferramental (Cloud, Linguagem, etc).
  • Complexidade do Legado: Provém da manutenção da aplicação enquanto se está em produção.
  • Complexidade do Domínio: Referente ao quanto o “problema” de negócio a ser solucionado é complexo.
DDD tem como objetivo “atacar” a Complexidade do Domínio.

É válido ressaltar que o uso da metodologia tem maior destaque e resultado quando aplicado a domínios que tem complexidade moderada ou maior. Em projetos e aplicações onde o domínio é mais simples, uma abordagem utilizando outra metodologia pode ser uma melhor alternativa.

Nosso Cenário

Iremos definir como base um domínio no qual possamos aplicar o DDD. O contexto do nosso exemplo será:

Uma aplicação móvel de turismo, em que o usuário terá um perfil de viajante e poderá submeter pontos de interesse em um mapa. Esses pontos poderão receber avaliações de outros viajantes.

Inicialmente temos essa visão macro do objetivo da nossa aplicação. Iremos aos poucos aplicando os pilares do DDD para que, ao fim deste artigo, tenhamos um dos artefatos necessários para podermos iniciar o desenvolvimento.

Aplicando DDD

Uma vez escutei de uma pessoa desenvolvedora uma máxima sobre DDD:

“DDD é fácil de entender, mas difícil de aplicar”

Eu concordo parcialmente com ela, pois assim como boa parte das coisas em TI, depende do contexto e do escopo.

O que posso afirmar é que é difícil aplicar DDD quando se faz o que eu, e acredito que muitos outros desenvolvedores, devem ter feito enquanto estudavam DDD: negligenciar os pilares da metodologia.

Ou seja: pula para os padrões de projeto que DDD utiliza e os aplica sem entender as razões pelas quais estes padrões são citados pela metodologia.

Criando nossa Linguagem Ubíqua

A linguagem ubíqua (na tradução do livro, linguagem onipresente) é a transcrição do contexto de negócio (domínio) e contexto técnico (linguagem/ferramenta de criação de software) em uma única linguagem.

Este vocabulário é a base para a comunicação eficiente entre os desenvolvedores do projeto.

Um exemplo é o substantivo Cliente. Dependendo do domínio, esta palavra pode tanto descrever os usuários de um serviço de streaming, quanto um possível comprador que visita um e-commerce. Ou até pode ser uma entidade que representa o cliente de um jogo online, atrelado a sessão de um jogador.

Este vocabulário único tem como objetivo saciar as necessidades técnicas de nomenclatura dos artefatos de código e trazer um entendimento lógico em alto nível do domínio.

Se olharmos para o nosso exemplo, conseguimos identificar algumas entidades:

Uma aplicação móvel de turismo, em que o USUÁRIO terá um perfil de viajante e poderá submeter PONTOS DE INTERESSE em um mapa. Esses pontos poderão receber AVALIAÇÕES de outros viajantes.

Em um contexto real, nesse momento estaríamos debatendo sobre o domínio referente a aplicação. Digamos que para o nosso exemplo, em uma conversa entre os envolvidos na criação da nossa aplicação, conseguimos entender alguns outros pontos:

  • Um usuário não pode avaliar o próprio ponto de interesse
  • O usuário precisará fazer um cadastro e criar um perfil na aplicação para poder submeter e avaliar pontos de interesse
  • Esse cadastro poderá ser feito usando suas Redes Sociais (Facebook e Instagram)
  • A avaliação será feita utilizando ranking de estrelas, podendo avaliar de 0 a 5 estrelas, poderá também conter uma ou mais fotos.
  • Outros usuários podem curtir uma avaliação, indicando as mais relevantes. Um usuário não pode curtir uma avaliação feita por ele mesmo.
  • Outros usuários podem denunciar uma avaliação ou ponto de interesse que não tenham sido criados por eles
  • Um usuário não pode avaliar mais de uma vez um ponto de interesse
  • Os pontos de interesse podem ser estabelecimentos, como restaurantes e shoppings, e locais abertos, como parques, trilhas e paisagens naturais.
  • Na submissão de um ponto de interesse, um usuário pode submeter uma ou mais fotos.

Nossa Linguagem

Com tantos novos detalhes, conseguimos esboçar nossa primeira versão de linguagem ubíqua:

  • Usuário: cadastro de uma pessoa que irá utilizar a aplicação
  • Ponto de Interesse: uma entrada no sistema referente a uma localização, seja aberta ou fechada, pública ou privada
  • Avaliação: um usuário pode avaliar qualquer ponto de interesse que não tenha sido ele mesmo que criou
  • Foto: imagem submetida por um usuário, em uma avaliação ou submissão de ponto de interesse
  • Curtida: uma interação de um usuário em uma avaliação.
  • Denúncia: um usuário pode denunciar um ponto de interesse ou uma avaliação de outro usuário

Com estes termos criados, assim como suas definições, temos nossa linguagem.

Contextos Delimitados

No mundo real, para se entender o verdadeiro significado de uma palavra em uma linguagem, é preciso existir o contexto. Na maioria dos casos, esse contexto é inferido enquanto conversamos com alguém. Quando o contexto não existe, ou falhamos em inferi-lo, acabamos não entendendo por completo a mensagem passada pelo locutor.

No caso do DDD, existem os “Bounded Contexts” (na tradução do livro, Contextos Delimitados). São literalmente o que seu nome diz: contextos.

Lembra do exemplo que discutimos sobre o substantivo Cliente, e como seu significado varia de acordo com o contexto?

Cada caixa pontilhada representa um Contexto Delimitado em um domínio fictício, e em cada um deles, a entidade Cliente representa algo diferente.

Existe algo importante sobre os contextos que todos nós devemos entender a fundo: eles não expressam a arquitetura de um sistema. Quando estamos em nossos projetos, temos a tendência de criar e diagramar um modelo que expresse a arquitetura do software, como o exemplo dos antigos diagramas de classe.

No caso do DDD, os contextos são utilizados para expressar de maneira visual os variados pontos do nosso domínio, e como em cada um deles as entidades têm tarefas e propósitos similares, mas não exatamente iguais.

Contextos Delimitados e Times

Em algumas literaturas, como no livro “Domain-Driven Design Distilled” de Vaughn Vernon, é dito que:

  • Um time deve ser designado para trabalhar em um Contexto Delimitado
  • Cada Contexto Delimitado deverá ter um repositório de código separado
  • É possível que um time trabalhe em vários Contextos Delimitados, mas vários times não deveriam trabalhar em um único Contexto Delimitado

Conclusão

Chegamos ao fim do artigo passando por uma das etapas mais fundamentais da metodologia DDD! No próximo artigo, iremos discutir um pouco mais a fundo sobre como utilizaremos esta linguagem para montar nosso Mapa Contextual. Abordaremos:

  • O que é um Mapa Contextual?
  • Quais tipos de relacionamento conseguimos expressar no Mapa Contextual?

No mais, espero que tenham gostado do conteúdo!

Contatos

Colaboradores e Revisores

Fontes

João Lucas

João Lucas