Domain-Driven Design (DDD): quais seus princípios e como implementar

A técnica DDD de desenvolvimento de software ágil pode ser aplicada em qualquer linguagem, sendo um método de imprescindível aprendizado

Se você deseja entregar projetos de software com qualidade e que reflitam a lógica real do produto desenvolvido, saiba que para isso existe o Domain-Driven Design (DDD). Em português, DDD é conhecido como Design Guiado pelo Domínio. 

De acordo com Eric Evans, criador da técnica DDD, em uma entrevista para a revista digital The InfoQ eMag, o DDD é “uma maneira de usar modelos para criar software, especialmente a parte do software que trata regras de negócio complexas em forma de comportamento”.

Apesar do termo “design”, o DDD não se refere à parte estética e tampouco ao layout do software. Na verdade, o design nesse caso diz respeito à concepção de um produto e a modelagem desse projeto que precisa ser entregue.

Nesse artigo você vai conhecer mais detalhes da técnica Domain-Driven Design: o que é, quais os seus princípios, para que serve, quais as vantagens da modelagem e muito mais.

O que caracteriza o Domain-Driven Design (DDD)?

Diferentemente de algumas metodologias ágeis, como Scrum ou XP, que prezam pelo trabalho em equipe e pela testagem a fim de evitar os erros e bugs dos softwares, o DDD é uma modelagem de software.

O Domain-Driven Design se refere ao projeto e oferece ferramentas de modelagem estratégica e tática com o objetivo de acelerar o desenvolvimento de aplicações que lidam com processos de negócios complexos. 

Segundo seu criador, Eric Evans, “se os programadores não estão interessados no domínio, eles aprendem apenas o que a aplicação deve fazer, não os princípios por trás dela”.

Portanto, para sanar esse problema, o DDD foi construído em torno de práticas que estimulam os desenvolvedores a serem capazes de analisar, descrever e resolver qualquer situação no domínio, seguindo uma linearidade sustentável.

O que é domínio?

O domínio é a palavra-chave para entender o DDD. Sem o domínio, o sistema não tem razão para existir, já que ele é quem justifica a necessidade do software. Assim, um domínio é o conjunto das atividades e das regras relacionadas a qualquer programa.

Por conta disso, alguns domínios podem ser longos e durante o processo podem ser subdivididos em pequenos conjuntos de atividades.

Como surgiu o Domain-Driven Design?

O DDD já vinha sendo discutido por Eric Evans há alguns anos, mas só veio a ser consolidado após o lançamento do livro Domain-Driven Design: Atacando as complexidades no coração do software, no ano de 2003.

Este exemplar é como um grande guia para os leitores. Ele traz uma abordagem sistémica do DDD e apresenta um conjunto de práticas de design, baseadas estas na experiência do usuário e em princípios que facilitam o desenvolvimento de projetos de softwares.

Além disso, Eric traz exemplos reais de projetos de sucesso que aplicaram o DDD no desenvolvimento de softwares.

Atualmente, Eric está à frente da Domain Language, uma empresa de consultoria e treinamentos para equipes de desenvolvedores que aplicam o DDD. O propósito da Domain Language é facilitar o desenvolvimento dos projetos de softwares, a fim de que eles sejam mais produtivos para a empresa.

Os 3 princípios do DDD

Linguagem Ubíqua

A comunicação é fundamental para o projeto e, por isso, a linguagem ubíqua é o princípio central do DDD. 

Podemos definir a linguagem ubíqua como “a linguagem falada no dia-a-dia”. Ou seja, os termos utilizados no software precisam ser entendidos tanto pelos usuários do sistema, quanto pelos desenvolvedores do software.

A escolha das palavras que serão utilizadas na aplicação é feita em uma parceria entre os experts do negócio e os desenvolvedores, de acordo com as expressões utilizadas principalmente pela equipe solicitante.

linguagem ubíqua no ddd

Por exemplo: imagine que você está trabalhando para um time de advogados. Muitos dos termos que eles usam são desconhecidos para a equipe de desenvolvedores e vice-versa. Como fazer, então, essa comunicação acontecer de maneira efetiva?

Definindo uma linguagem comum a todos. Criar um glossário que deve ser usado por toda equipe durante o projeto e que pode sofrer modificações ao longo do projeto é uma solução.

Bounded Context

Os sistemas de softwares são projetos grandes e complexos, então é praticamente impossível concentrar todo o sistema em um único domínio. Assim, para que a equipe consiga dar conta de tudo, o DDD se utiliza do bounded context (contextos limitados em português).

Bounded context é a divisão natural que as instituições fazem para atender todos os usuários. Na prática, um domínio é transformado em domínios menores e equipes são responsabilizadas por esses pequenos domínios.

Resumidamente, cada pequeno contexto tem responsabilidades e uma linguagem ubíqua que é atribuída a ele.

Para entender melhor como isso funciona, vamos ao exemplo:

Suponha que você trabalha em uma escola. Neste ambiente, existem atribuições específicas e uma linguagem própria para as pessoas da área. Entretanto, você é o do setor administrativo e não tem relação direta com a parte pedagógica. Então, seu setor possui uma linguagem própria e exerce atividades específicas.

Nesse exemplo de domínio administrativo, um usuário pode ser chamado de “cliente” ou até mesmo de “responsável”.  

Context Maps

Feito os bounded context, é hora de partir para o context maps – um modelo que possibilita uma visão geral do software.

O terceiro princípio do Domain-Driven Design existe para entender como cada bounded context se comunica com os demais contextos limitados e, consequentemente, como eles estão funcionando de maneira interdependente.

Essa relação entre os bounded context pode ter classificações como:

  • Shared Kernel: vários bounded context possuem o mesmo domínio;
  • Customer-Supplier Development: quando a equipe upstream (fornecedor) pode ter sucesso independente da equipe downstream (cliente);
  • Conformist: o cliente entende que o modelo desenvolvido não atende suas necessidades e então a upstream realiza mudanças de acordo com as necessidades do cliente;
  • Partner: as duas equipes trabalham juntas e são dependentes uma da outra;
  • Anticorruption Layer: os clientes tentam proteger o que foi criado até o momento das alterações da equipe upstream.

Os mapas que estabelecem essas relações costumam ser feitos de maneira bem informal como, por exemplo, um desenho feito à mão em quadro branco ou um rascunho em folha de papel. Isso porque eles são atualizados o tempo todo, de acordo com o andamento do desenvolvimento do software. 

Com os três princípios bem definidos, percebe-se que o foco do DDD é que os desenvolvedores tenham total domínio do sistema através principalmente da linguagem ubíqua, mas dentro de um contexto delimitado. Só assim é possível criar a modelagem do sistema que está sendo trabalhado.

Para que serve o modelo?

No Domain-Driven Design um modelo de domínio é a base da comunicação do projeto de software. Isso porque a modelagem absorve alguns aspectos do desenvolvimento para trabalhar na resolução de problemas. 

Um modelo é caracterizado pela comunicação eficiente entre as pessoas da mesma equipe, conceitos relacionados à aplicação dos domínios bem definidos e a simplificação desses. 

Assim como os context maps, a modelagem é totalmente adaptável e sofre alterações o tempo todo, de acordo com o andamento do projeto. Ou seja, a cada nova interação entre desenvolvedores e clientes, os experts no negócio podem modificar o que está em desenvolvimento. 

Implementando o DDD 

Para utilizar o DDD na sua rotina, é preciso conhecer bem os domínios e as regras do negócio. Na prática, ele se baseia na arquitetura da informação, que é dividida em 4 camadas, nem sempre são tão bem separadas na execução do software.

Arquitetura da Informação

  • Camada de interface: é onde o usuário tem acesso. Ou seja, é nela que estão as informações e os comandos necessários para que o cliente utilize a ferramenta a seu favor; 
  • Camada de aplicação: as atividades do sistema são coordenadas aqui. Ela é, portanto, a camada responsável por fazer as validações do que é feito no domínio; 
  • Camada de domínio: representa os conceitos e as regras do negócio, que são transmitidas para todo o sistema;
  • Camada de infraestrutura: é a última camada da arquitetura e serve como depósito de materiais para as outras. Nela, estão as informações que são utilizadas para conexão de dados, gravação e envio de mensagens, entre outras funções. 
exemplo de arquitetura da informação no DDD

Repositórios

Um repositório possui acesso direto aos dados do software, com objetivo de facilitar o acesso à informação para os desenvolvedores.

Dessa forma, os repositórios permitem que os desenvolvedores sigam focados no desenvolvimento do domínio, enquanto armazenam as informações na memória principal e facilitam a manipulação dos objetos do domínio.

Além do armazenamento das informações do projeto, os repositórios também possuem livre acesso a serviços externos de consulta de dados. 

Benefícios práticos e desafios da sistematização de processos

Benefícios

  • Pode ser utilizado independente da linguagem. Não importa se é C#, Python, Java, entre outras;
  • Desenvolvimento é facilitado após a estruturação do sistema;
  • Os modelos criados são objetivos e focados na entrega de resultado, em curto espaço de tempo;

Desafios

Apesar do Domain-Driven Design facilitar a vida do time de desenvolvedores, a criação dos domínios é um processo muito complexo e nem todos conseguem montar ou executar bem os domínios. 

Por isso, se você deseja aprofundar os conhecimentos em DDD e outras técnicas para desenvolvimento de software ágil e se tornar um profissional especializado da área, matricule-se no MBA de Engenharia de Software Ágil do IGTI!

Em apenas 7 meses, o curso de pós-graduação online prepara você para liderar equipes, desenvolver projetos combinando conceitos, técnicas e ferramentas de desenvolvimento ágil de software!

spot_img

Continue Aprendendo

spot_img