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:
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.
Nenhum comentário:
Postar um comentário