Este artigo apresenta o Domain-Driven Design (DDD), abordagem de desenvolvimento de software que mostra uma série de práticas e padrões para se construir um software dando foco principal ao domínio.
Em que situação o tema útil:
As práticas do DDD auxiliam no desenvolvimento de um software mais coerente com a área de negócio à qual é voltado e, portanto, um software de mais valor para o cliente, fácil de ser mantido e estendido. As técnicas de Design Estratégico facilitam no relacionamento entre diversos times de desenvolvedores, trabalhando em módulos diferentes de um sistema complexo (que podem inclusive terem sido desenvolvidos em diferentes tecnologias).
Resumo DevMan:
Este artigo introduz o Domain-Driven Design e suas premissas (domínio e modelo), dando bastante enfoque à comunicação com os especialistas de negócio e à modelagem do domínio. São explicados conceitos-chave como a Linguagem Ubíqua e o Model-Driven Design, com seus principais padrões para expressar o modelo no código. Por fim, são mostrados os padrões do Design Estratégico, como formas de comunicação entre times/sistemas diferentes.
No processo waterfall tradicional, toda a fase de desenvolvimento do software é guiada pela parte tecnológica, com pouco ou nenhum foco no negócio. Isto porque toda a análise é feita previamente por um analista de sistemas e passada, em forma de muita documentação, para o time de desenvolvedores, cabendo a eles simplesmente implementar com base nos requisitos recebidos.
Já nas metodologias ágeis, embasadas no Manifesto Ágil e seus princípios, a presença constante dos especialistas de negócio junto dos desenvolvedores é algo essencial. O software é entregue aos poucos, sendo assim, análise, implementação e testes são realizados iterativamente, de forma a entregar “pedaços” de software o mais cedo possível.
Neste contexto de agilidade, Eric Evans, especialista em modelagem de domínios complexos, escreveu o livro “Domain-Driven Design – Tackling Complexity in the Heart of Software” (lançado em 2003), com uma série de conceitos e práticas dando foco ao domínio do software.
Evans percebeu, ao longo de anos de experiência trabalhando em projetos complexos, que os projetos bem-sucedidos tinham em comum um modelo rico do domínio, que evoluía incrementalmente iteração após iteração. Seguindo este pensamento, seu livro deu ênfase justamente na modelagem do domínio – enquanto a maioria dos livros dava ênfase na resolução de problemas tecnológicos, como redes e bancos de dados – tornando-se assim um clássico do gênero.
Neste contexto, neste artigo abordaremos alguns dos principais conceitos e práticas do Domain-Driven Design, como a linguagem ubíqua e a comunicação constante com os especialistas de negócio, a modelagem e a implementação como uma única atividade, e as práticas do Design Estratégico.
DDD e suas premissas
O Domain-Driven Design (DDD) é uma abordagem de desenvolvimento de software fundamentada em duas premissas:
· O foco principal deve ser o domínio;
· Domínios complexos devem estar baseados em um modelo.
O domínio de um software é “a área de ação, conhecimento e influência do software”. Sendo assim, focar no domínio é dar mais atenção à área de negócio que o software pretende cobrir do que a detalhes sobre tecnologias a serem empregadas em seu desenvolvimento.
Quando estamos trabalhando em domínios complexos – e normalmente estamos – é bastante útil trabalharmos em cima de um modelo.
Ao falarmos de modelo, geralmente associamos o termo a algum tipo de diagrama, como um diagrama de classes UML. No entanto, um modelo é mais do que um diagrama, ele é uma tradução do conhecimento dos especialistas de negócio para algo mais padronizado, uma espécie de “molde” do domínio. Para a construção deste modelo, são aplicados padrões do MDD (Model-Driven Design) que serão vistos na seção correspondente ao mesmo.
Um diagrama, seja ele UML ou seguindo qualquer notação que você achar útil, pode ser uma ótima ferramenta para comunicar e registrar alguns aspectos do modelo, enquanto outros aspectos são transmitidos de forma mais clara diretamente pelo código.
Modelagem efetiva
Projetar um software orientado ao domínio é uma tarefa muito mais difícil do que simplesmente “ir fazendo”, uma vez que trazer o conhecimento da cabeça de um especialista de negócio para um software, de forma organizada, é algo complexo.
...
