Foco ao negócio com DDD - Revista Engenharia de Software Magazine 45

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.

ATENÇÃO! A exibição deste artigo foi interrompida.

  Este é um post disponível para assinantes MVP

Este post também está disponível para assinantes da Engenharia de Software Magazine ou para quem possui Créditos DevMedia.  Clique aqui para saber mais!

####

Este post está disponível somente para quem é assinante da Engenharia de Software Magazine.