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
