Introdução ao DDD: Domain-driven design

Imagine um cenário em que todos os envolvidos em um projeto falem a mesma língua, com os mesmos termos, e que tanto o projeto, quanto a sua estrutura transmitam a mesma mensagem. Imaginou? Pois então, bem-vindo ao DDD (Domain-driven design – em tradução literal, Design Direcionado ao Domínio).

Mais uma vez falaremos aqui sobre fundamentos de desenvolvimento de software. Desta vez, de um design partner que se consolidou no mercado por reforçar uma comunicação clara com todo o time, permitindo um projeto bem-organizado, como um todo.

 

Introdução

Não é sempre que levamos em consideração a complexidade de um negócio. E quando estamos lidando com o desenvolvimento de software, o primeiro passo é tentar compreender de fato este negócio e suas peculiaridades, e assim, trazê-lo para nosso contexto e implementar a melhor tecnologia possível.
O DDD é um meio que possuímos para facilitar esse desenvolvimento. Esta metodologia de design está presente em várias aplicações desenvolvidas atualmente e, como o nome sugere, significa preparar uma aplicação que nos direcione ao domínio do negócio em questão.

 

O que é DDD

DDD não é um código de área, mas é muito comum no cenário de desenvolvimento. É uma metodologia de design de software que tem foco no que está acontecendo no domínio da aplicação. Basicamente todo o design é centrado na lógica de negócios (domínio) do software.

A partir do entendimento geral do problema para o qual o software foi composto, é necessário crescer a estrutura de desenvolvimento. A implementação é focada em uma coleção de padrões e princípios que buscam auxiliar todos os envolvidos no processo de construção das aplicações, para que reflitam o entendimento do negócio. Nesse ponto, o desenvolvimento do software passa a crescer segundo a modelagem do domínio real, como classes de domínio que possuem (ou não) relação entre elas.
A ideia de se trabalhar como domínio encaixa-se perfeitamente no contexto de bancos de dados relacionais e, mais recentemente, de ORM’s (Mapeadores Objeto-Relacionais).

 

Separando a aplicação em camadas

A separação em camadas já é uma realidade no desenvolvimento de softwares há algum tempo, mas, infelizmente, apenas recentemente foi, de fato, implementada. O grande responsável pela difusão do conceito de separação em camadas, foi a complexidade das aplicações. O DDD, por trazer como premissa uma modelagem baseada no domínio real, ajuda bastante na separação dos problemas, o que é extremamente necessário em todo o contexto de desenvolvimento de software. Conforme ilustra a imagem abaixo:

Podemos perceber que, a partir da interação com o usuário, todos os problemas estão separados em seus domínios, o que é completamente pertinente à aplicação. É importante lembrar que o DDD não é a forma como definimos o software, e sim, como preparamos o desenvolvimento como um todo.

Essas camadas comuns a aplicação, trazem elementos essenciais ao desenvolvimento, como:

  • Interface de Usuário: camada de apresentação da aplicação, que pode ser web, desktop, mobile ou todas de uma vez só (obviamente tratadas de forma independente).
  • Serviços da aplicação: conjunto de serviços expostos relacionados a entidade para consumo da aplicação.
  • Serviços de domínio: conjunto de serviços referentes ao domínio e não à entidade.
  • Modelo de domínio: camada base de todo DDD – é onde devemos definir corretamente o modelo de negócio, seus termos, classes e contratos.
  • Repositórios: camada responsável pelo acesso aos dados
  • Infraestrutura: camada responsável por fornecer a estrutura necessária para o funcionamento do domínio.

 

Conclusão

Domain-Driven Design é uma coleção de padrões e princípios que permitem que o desenvolvedor faça o design de uma aplicação de lógica de negócios mais completa e com mais facilidades. A ideia básica está centrada no conhecimento do problema para o qual o software é proposto.

Por trazer a compatibilidade de termos dentre todas as pessoas envolvidas no processo, toda a comunicação do projeto fica mais fluida, visto que todos conhecem os termos utilizados.
O DDD vai muito além de apenas código, não é uma arquitetura em camadas e sim um reflexo do seu negócio!

 

Confira outros artigos do Blog GFT Brasil

 

Referências

Domain-Driven Design (English Edition) – Evans, Eric

Comment Area

  1. Eduardo Nunes10/02/2022

    Belo artigo Henrique. Obrigado por compartilhar esse conhecimento necessário!

  2. Eduardo Nunes11/02/2022

    Que baita artigo Henrique. Obrigado pelo conhecimento!

  3. Ian Malm25/05/2022

    Muito interessante o artigo, cada vez mais vemos a abordagem voltada para a necessidade do usuário (seja ele quem for) e na minha opinião faz sentido pois facilita a abstração da parte técnica do problema (seja uma nova feature, uma melhoria ou uma manutenção), deixando a documentação e o futuro desenvolvimento mais organizados, entre outros benefícios.