DDD domain-driven design: o que é, vantagens e desvantagens

Há muitos anos, um talentoso designer de software adicionou um recurso de edição (que ele batizou de “Dividir e Conquistar”) a um programa muito usado de layout de jornal. Esse recurso tinha um ótimo design, mas ninguém o usou. Saiba por quê:

1. O nome “dividir e conquistar” não tinha relação com o layout do jornal.
2. Ninguém sabia explicar o que o recurso fazia ou a utilidade dele.
3. Ninguém solicitou o recurso e ninguém o queria.

Essencialmente, preocupou-se mais com o que poderia ser feito com o programa, em vez de considerar por que ele deveria existir. 

É onde entra o domain-driven design (DDD): uma abordagem no desenvolvimento de softwares que procura entender completamente o domínio em que o software será aplicado. Ao entender o domínio, você reduz o risco de adicionar recursos que os clientes não precisam ou não querem.

O que é DDD domain-driven design?

O software serve para facilitar nossa vida. Ele pode agilizar e automatizar os processos no mundo real; ou lidar com áreas de interesse de usuários específicos. Essas áreas nas quais os softwares se destinam a trabalhar se chamam "domínios". O domínio do software Digital Audio Workstation (DAW), por exemplo, é o setor de gravação de áudio.  

Um desenvolvedor de software chamado Eric Evans reconheceu a necessidade de entender o domínio dos softwares. Para apresentar a abordagem DDD, ele escreveu um livro chamado "Domain-Driven Design: Atacando as complexidades no coração do software". No livro, Evans define: “O coração do software é a capacidade dele de resolver problemas relacionados ao domínio para o usuário. Todos os outros recursos, por mais vitais que sejam, auxiliam esse propósito básico.”

Portanto, no exemplo do layout de jornal acima, você não precisa ser editor profissional para criar um software útil de layout. Porém, para criar um software que reflita os processos e procedimentos no mundo real, você precisa entender como os editores de layout trabalham. Qualquer outro recurso além do que eles precisam agrega pouco ou nenhum valor.

Princípios orientadores do domain-driven design

Basicamente, DDD é o desenvolvimento de softwares que modela sistemas e processos do mundo real. A abordagem DDD se baseia nos seguintes princípios:

• Foque o domínio principal: antes de começar a programar, fale com quem trabalha nesse domínio. Eles podem ajudar você a definir todos os processos, procedimentos e terminologia do domínio em questão. Por exemplo: se você for projetar um software para gerenciar o estoque no varejo, converse com quem gerencia o estoque da loja em vez dos funcionários do RH ou de finanças.
• Baseie os designs em modelos do domínio para reduzir a complexidade: após entender o domínio da empresa, crie um modelo que reflita o domínio no mundo real. O software de gestão de estoque, por exemplo, deve incluir recursos importantes para os gerentes de estoque, como análise das tendências do estoque, reabastecimento automático, leitura de código de barras e assim por diante. O modelo é um diagrama, gráfico ou parágrafo que representa a organização e a abstração do conhecimento do especialista em domínio.
• Use uma linguagem comum: no livro, Evans fala da importância da linguagem onipresente. Todos os envolvidos no projeto devem usar a mesma linguagem ao falar sobre o domínio. Ouça as palavras e termos que os especialistas no domínio usam. Adote a mesma terminologia no documento de requisitos, no modelo e no próprio código.

Principais termos no domain-driven design

Frequentes e cruciais, os seguintes termos são úteis ao aprender sobre o DDD:

• Lógica do domínio: também chamada de lógica de negócios, é o propósito do design do modelo e do software. O design é baseado na lógica das regras de negócios do mundo real, que são traduzidas em código de programação.
• Padrões do design: se houver um código existente que resolva um problema semelhante ao que você está trabalhando, adapte-o para o seu uso. Não tente reinventar a roda.   
• Contexto: a configuração ou o ambiente que determina o significado de uma palavra, ação ou recurso no domínio do software. Por exemplo: num determinado contexto, faz mais sentido usar o botão “Aplicar” em vez do botão “Salvar”.
• Contexto limitado: projetos grandes geralmente têm muitos modelos que precisam ser integrados. O limite do contexto define a estrutura lógica na qual o modelo pode evoluir. Assim, as outras equipes sabem o que fazer para que os modelos delas sejam válidos quando adicionados a outros.
• Mapeamento do contexto: documento, gráfico ou diagrama que descreve as relações entre vários contextos delimitados. O mapa mostra a linguagem de cada contexto, a implementação independente e a interface usada para se comunicar com outros contextos delimitados.
• Entidades: é um objeto de domínio definido por um identificador exclusivo em vez de atributos. Por exemplo: uma pessoa compra um ingresso para assistir a um filme. Essa pessoa é uma entidade, pois o identificador exclusivo define quem é essa pessoa, não importa as alterações na cor do cabelo, no peso ou na altura. 
• Objetos de valor: objeto imutável com atributos, mas nenhuma identidade distinta. Por exemplo: você compra um ingresso que não especifica o assento. Todos os assentos no cinema são iguais. Os assentos são aparafusados e não podem ser movidos, mas você pode escolher qualquer assento disponível. Nesse contexto, o assento é um objeto de valor.

Vantagens do domain-driven design

A vantagem mais óbvia do DDD é fazer todos usarem a mesma linguagem. Quando as equipes de desenvolvimento usam a mesma linguagem dos especialistas no domínio, o resultado é um design de software que faz sentido para o usuário final. Como a terminologia da aplicação corresponde às atividades do mundo real, há menos confusão, e os usuários aprendem mais rapidamente a usar o produto.

Outras vantagens são:

• Os negócios e o desenvolvimento estão alinhados: por usarem a mesma linguagem, os desenvolvedores se comunicam melhor ao conversarem com a equipe de negócios. Esse alinhamento reduz o risco de confusão e de mal-entendidos entre a equipe de desenvolvimento e os especialistas no domínio.
• Protege o conhecimento do domínio: o conhecimento valioso não é perdido quando as equipes passam para outros projetos e quando novas pessoas são recrutadas para manter os projetos existentes.
• Mais flexibilidade: as definições e os limites do contexto facilitam lidar com as mudanças nos requisitos, pois todos têm o mesmo entendimento do domínio.
• Fácil de monitorar: a comunicação melhor e o conjunto comum de terminologias facilitam o monitoramento da implementação dos requisitos.
• Melhor equilíbrio nas aplicações: às vezes, há muita ênfase no UX/UI do software. Eles são importantes, mas podem causar problemas se alguns requisitos de domínio forem negligenciados. Por mais lindo que seja o seu programa, ele precisa fazer o que os usuários querem. Você deve suprir o que o domínio precisa e o que os especialistas recomendam para que o software resultante atenda às necessidades e às expectativas do cliente.
• Melhor código: seguir uma abordagem DDD, em última análise, fornece um código mais simples e confiável. Ela também pode estabelecer práticas recomendadas e padrões de design reproduzíveis para que projetos futuros sejam executados de forma mais tranquila e eficiente.

Desvantagens do domain-driven design

O domain-driven design oferece muitas vantagens, mas não funciona necessariamente para todos em todas as situações. Algumas desvantagens são:

• Exige um amplo conhecimento do domínio: sua equipe precisa ter pelo menos um especialista no domínio. Ele deve entender tudo sobre o domínio em que o software deve ser aplicado. Sem esse conhecimento, você pode acabar com recursos que não combinam com o contexto do domínio.
• Só funciona se o domínio for complexo: se o domínio for relativamente simples, o DDD pode ser uma extravagância demorada. Por exemplo: o desenvolvimento de software em um domínio de candidatura de emprego pode exigir apenas uns formulários simples para inserir informações pessoais, empregos anteriores, referências, contatos de emergência, etc. Se você não precisar de um especialista no domínio, provavelmente não precisa do DDD.
• Pode não funcionar bem em projetos altamente técnicos: o foco em domínios de negócios complexos e na lógica de negócios funciona porque você pode desenvolver uma linguagem comum entre os desenvolvedores e os especialistas no domínio. No entanto, em projetos tecnicamente complexos, fica difícil estabelecer uma linguagem comum que seja entendida pelo pessoal de negócios.
• Pode ser demorado: a menos que já sejam especialistas no domínio, os desenvolvedores terão que passar muito tempo com a equipe de negócios para entender completamente o domínio. Porém, isso pode virar vantagem uma vez que todo o conhecimento do domínio seja capturado. 

Se a sua organização deseja criar um software que combine com o domínio pretendido, você pode considerar a implementação do DDD. Mesmo que o DDD não seja adequado para você, ainda vale a pena aprender, pois isso pode melhorar a comunicação entre as equipes de desenvolvimento e os especialistas no domínio. Isso leva a uma melhor solução dos problemas e a um software mais útil.