"Domain-Driven Design (DDD) é uma coleção de princípios e padrões que ajudam os desenvolvedores a criar sistemas de objetos elegantes. Aplicado corretamente, pode levar a abstrações de software chamadas de modelos de domínio. Esses modelos encapsulam uma lógica de negócios complexa, fechando a lacuna entre a realidade de negócios e o código."

Fonte: Domain Driven Design Concept

 

Picture1

Vou dar uma pequena contribuição sobre o que penso e pratico quanto ao DDD, exemplo prático de um projeto sobre uma aplicação para seguros de vida, sobre a qual me dediquei por alguns anos.

Não irei entrar profundamente sobre as regras de negócio, mas dar um panorama bastante amplo de cenários que podem ser aplicados em qualquer projeto. Talvez isso ajude você a aplicar no seu dia a dia.

SOBRE DOMAIN-DRIVEN DESIGN

  • Criado em 2003 por Eric Evans;
  • Indicado para aplicações complexas;
  • Fácil de entender e difícil de aplicar;
  • Não é um design pattern;
  • É agnóstico a linguagem de programação.

Eric Evans basicamente é um líder sobre o pensamento de design de software e modelagem de domínios. Autor de Domain-Driven Design, conhecido também como Big Blue, tornou-se rapidamente um mantra para comunidade. Tem uma longa carreira na área de tecnologia, tendo trabalhado em projetos Java nas áreas de finanças, transporte, seguros, entre outros.

Muito dos seus esforços são no sentido de obter mais valor no desenvolvimento de software e principalmente o conceito de ligação entre a parte técnica com a de negócios.

Na minha opinião vale a pena também ler e conhecer outras obras de autores importantes além de Eric Evans. Algumas sugestões:

Martin Fowler => Link dos Livros

Robert C. Martin (Uncle Bob) => Link dos Livros

Seguindo!

Vou colar aqui alguns slides que vão detalhar o processo em todas as suas fases. São slides que preparei para uma apresentação para meu time há quase um ano.

PROCESSO DE CRIAÇÃO

Picture3_

"Antes de começar a codificar ou até mesmo definir arquiteturas, existe um processo que define os principais pilares do DDD".

  • Entender o Negócio;
  • Extrair a Linguagem Ubíqua;
  • Modelagem Estratégica;
  • Mapa de Contexto;
  • Definir Arquitetura;
  • Modelagem Tática.

LINGUAGEM UBÍQUA OU LINGUAGEM ONIPRESENTE

Picture4_

 

"Para criar um design flexível e rico em conhecimento é necessário ter uma linguagem versátil compartilhada pela equipe, e uma experiência ativa com a linguagem raramente acontecem em projetos de software"

Fonte: Livro Domain-Design Driven, Eric Evans

 

  • Terminologias
  • Verbos
  • Adjetivos
  • Expressões Idiomáticas

Exemplo de terminologias em seguradoras:

  • Sinistro
  • Prêmio
  • Capital Segurado

MODELAGEM ESTRATÉGICA

 

O resultado do mapeamento da linguagem ubíqua vai colaborar nas definições dos contextos da aplicação:

 

  • Cada contexto delimitado pode possuir a sua linguagem própria;
  • Neste caso, as terminologias podem ter significados diferentes.

Picture5_

 

A terminologia "Prêmio" dentro do seguro:

  • Para o Sinistro: Prêmio é o valor que o segurado paga mensalmente;
  • Para o Financeiro: Prêmio significa "Parcela Mensal" ou "valor".

MODELO DE NEGÓCIO X MODELO DE DOMÍNIO

Picture7

MAPA DE CONTEXTO

Picture8

ARQUITETURA

Picture9

Picture10

MODELAGEM TÁTICA

Vai fornecer os meios de implementar todo o trabalho feito anteriormente no mapeamento das terminologias, dos domínios, etc...

 

Possuem os seguintes padrões:

 

  • Aggregate Objects: Raiz agregadora de um processo do domínio que envolve mais de uma entidade;
  • Value Objects: Agrega valor a entidades, não possui identidade, é mutável, possui coleção de atributos, entradas de valores se dá pelo construtor, tipagem forte ao invés de tipos primitivos;
  • Domain Model: Entidade de domínio, possui getters, setters, AdHocs, etc;
  • Repository: Realiza persistência das entidades se comunicando diretamente com o acesso aos dados;
  • Domain Services: Realiza a persistência através do repositório, atende partes do negócio que não se encaixam nas entidades específicas, trabalha com diversas entidades;
  • Application Services: Orquestra ações disparadas na camada de apresentação e fornece DTOs para se comunicar com as demais camadas e consumo da camada de apresentação.

Picture12

 

CONCLUSÃO

O Domain-Driven Design então significa:

  • Um guia cheio de boas práticas que faz com que o time pensa na aplicação com base no negócio, entenda a linguagem, faça a modelagem estratégica. analise os contextos e defina a arquitetura e a modelagem tática a ser adotada de acordo com a estratégia de desenvolvimento da aplicação;
  • Atender a entrega de aplicações complexas;
  • Conseguir fazer uma arquitetura limpa;
  • Possibilitar a evolução exponencial da aplicação.

 

Essas são as minhas impressões sobre DDD. Procuro, sempre que possível, aplicar esse design nos projetos em que trabalho. Muitas vezes não na sua plenitude, mas, na minha opinião, nem tudo que está escrito nos livros é uma regra que nunca possa ser quebrada. Na verdade, muito pelo contrário, podemos sim usar muito das técnicas de DDD e modelar de acordo com o propósito da aplicação e das regras do negócio.

 

Esse artigo também está disponível:

Partilha este artigo