Domain Driven Design 1

Recentemente comecei a estudar mais a fundo UML e me foi apresentada a técnica de Domain Driven Design de Eric Evans, que vem a combinar a linguagem de domínio com a linguagem de programação, ajudando a criação da documentação UML e uma codificação mais voltada as expectativas do cliente.

Para tanto, fiz umas pesquisas e encontrei o Livro: Domain Driven Design Quickly na InfoQ:

http://www.infoq.com/minibooks/domain-driven-design-quickly

Com base no que li no livro fiz uma serie de resumos por capítulos, que visam explicar do que se tratam DDD e como podemos utilizar dessa técnica para entregar um software de qualidade e de fácil manutenção.

CAPITULO 1

Domain Driven Design combina práticas de projeto (analise) e desenvolvimento, e nos mostra como o design (documentação) e desenvolvimento podem trabalhar juntos para criar um melhor software. Um bom design vai acelerar o desenvolvimento, enquanto o feedback vindo do processo de desenvolvimento irá melhorar o design.

Nós não podemos apenas sentar e começar a codificar. Até podemos fazer isto, e até que funciona bem para casos triviais. Mas não podemos criar um software complexo com essa metodologia.

É possível criar um software bancário complexo sem um bom conhecimento de domínio (regra de negócio)? De jeito nenhum. Nunca.

Quem é que sabe como o software bancário deve funcionar? O arquiteto de software? Não, ele só usa o banco para manter seu dinheiro seguro e disponível. O analista de software? Não. Ele até que sabe analisar um determinado tema, quando lhe é dado a ele todos os ingredientes necessários. O desenvolvedor? Nem pensar. Quem, então? O sistema bancário é muito bem compreendido pelas pessoas que trabalham no banco, por seus especialistas. Eles sabem de todos os detalhes, todos os possíveis problemas, todas as regras de negocio. É por eles que devemos sempre começar. Eles são detentores do domínio.

Existem dois grandes tipos de diferentes abordagens para o desenvolvimento de software. Um deles é o método waterfall. Este método envolve uma série de etapas. Primeiramente os especialistas em negócios recolhem um conjunto de requisitos que são passados aos analistas de negócios. Os analistas criam um modelo com base nesses requisitos, e passam a documentação para os desenvolvedores, que começam a codificação com base no que eles receberam. É um fluxo contínuo de trabalho. Embora esta tenha sido uma abordagem tradicional em design de software, e tem sido usado com certo nível de sucesso ao longo dos anos, ele tem seus defeitos e limites. O principal problema é que não há feedback dos analistas para os especialistas em negócios ou dos desenvolvedores para os analistas.

Outra abordagem é a utilização de metodologias ágeis, como Scrum. Estas metodologias são um movimento coletivo contra a abordagem waterfall, decorrente das dificuldades de reunir todos os requisitos do software, considerando que normalmente ocorrem mudanças destes requisitos. A realidade é de que é difícil criar um modelo completo que abranja todos os aspectos de um domínio inicialmente. Normalmente um design possuiu diversas regras de negócios, e dificilmente irá prever alguns dos efeitos colaterais negativos ou erros que podem surgir durante o projeto.

Outro problema os métodos ágeis tentam solucionar é a chamada "analysis paralysis", que acontece quando membros da equipe ficam com tanto medo de tomar qualquer decisão de design que eles acabam não fazem nenhum progresso. Embora os defensores ágeis reconheçam a importância da definição de design, não ficam presos ao design inicial. Em vez disso, eles empregam uma grande flexibilidade nas implementações, e através do desenvolvimento iterativo com a participação contínua das partes interessadas do negócio e bastante refatoração de código, a equipe de desenvolvimento começa a aprender mais sobre a regra de negocio e poderá produzir um software que melhor atenda às necessidades dos clientes.

Os métodos ágeis também têm seus problemas e limitações, eles defendem a simplicidade, mas como todo mundo tem sua própria visão de simplicidade pode acabar numa documentação desatualizada. Em razão disto, uma a refatoração contínua feita pelos desenvolvedores sem um design sólido e atualizado irá produzir um código que é difícil de compreender e dar manutenção.

O modelo de Design será moldado durante as entrevistas iniciais de analise com base nas respostas coletadas. Assim acabarão surgindo conceitos essenciais do domínio do sistema a ser desenvolvido. Esses conceitos poderão aparecer de forma desorganizada, mas mesmo assim são essenciais para a compreensão da regra de negocio. Devemos aprender o máximo possível sobre o domínio com os especialistas nas entrevistas. Fazendo as perguntas certas para poder processar a informação da maneira correta para começar a criação modelo de domínio. Este modelo não será completo nem definitivo, mas já é o começo que precisamos.

Os especialistas conhecem bem sua área de atuação, e conseguem organizar e utilizar seus conhecimentos de uma maneira específica para realizar o seu trabalho, entretanto não sabem a melhor maneira a ser implementada em um software. A mente analítica do designer de software deverá desvendar alguns dos conceitos chave do domínio durante as entrevistas com especialistas de domínio, e assim construir uma estrutura que norteará futuras discussões.