Domain Driven Design 3

Este é o ultimo post sobre DDD, onde farei o resumo do capítulo 3 do livro Domain Driven Design Quickly, que pode ser baixado gratuitamente na InfoQ:

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

Para a criação de um modelo correto, que venha realmente a capturar as regras do domínio, os analistas de software e os peritos no domínio se reúnem por meses, para descobrir os elementos fundamentais do domínio, enfatizando os relacionamentos. Os desenvolvedores podem vir a se juntar ao time para verificar a possibilidade de expressar no código esses conceitos e relacionamentos desenhados no modelo. Assim começa a criação de um modelo, com inspiração no modelo original, adicionando algumas ideias da equipe técnica.

Uma técnica muito utilizada é a criação do modelo de análise, que é separado do código e feito por pessoas diferentes. Neste modelo temos ênfase na regra de negocio, e nenhuma ênfase na codificação a ser implementada no software. É gerado certo nível de conhecimento a respeito do software a ser desenvolvido. Com base nesse modelo, os desenvolvedores irão adapta-lo para um modelo que irá guiar a equipe de desenvolvimento.

Um dos principais problemas dessa técnica é que como os analistas não conseguem enxergar além das regras de negócios, o modelo pode se aprofundar em determinadas questões que não irão ser tão pertinentes para a regra de desenvolvimento. E podem esquecer outros pontos, que podem vir a ser importante para elucidação da equipe de desenvolvimento.

Em razão desta falta de documentação, os desenvolvedores terão que tomar algumas decisões por sua conta, que visarão resolver ou solucionar algum problema real que não foi considerado no modelo criado e acabam criando um modelo que foge um pouco do modelo original.

Normalmente os analistas têm reuniões fechadas, onde discutem a respeito do modelo a ser desenvolvido, e neste momento muita informação valiosa é compartilhada nessas reuniões. Eles criam um modelo que supostamente contem toda informação de uma maneira condensada, e os desenvolvedores deverão assimilar essa informação lendo a documentação que lhes foi dada. Uma sugestão é que seria muito mais produtivo que os desenvolvedores participassem dessas reuniões com os analistas para conseguir capturar um melhor conhecimento da regra negocio e poderem desenhar um modelo mais completo.

Uma melhor abordagem é relacionar o domínio de modelo com o design. O modelo deve ser desenhado com foco no desenvolvimento do software e nas considerações de design. Os desenvolvedores devem ser incluídos no processo de modelagem. A ideia principal é escrever um modelo que melhor expressa o software a ser desenvolvido, deixando ele fortemente relacionado com a codificação a ser escrita, e consequentemente tornando o modelo mais relevante.

Manter os desenvolvedores envolvidos neste processo ocasiona feedback por parte dos mesmos. Acaba gerando uma segurança de que o modelo poderá ser implementado no software. Se algo estiver errado, poderá ser identificado logo, e o problema será facilmente corrigido.

É importante que todo time técnico, responsável por desenvolver e manter o código tenha algum contato com o modelo. Todos tem ter algum nível de contato e discussão a respeito do modelo e com os especialistas na regra de negocio.  Esse envolvimento entre todas as partes interessados ajudaram a criar a Ubiquitous Language.

Programação Orientada a Objetos é a mais adequada e que mais combina com a implementação de modelo. Ambas se baseiam nos mesmos paradigmas. O desenvolvimento OO trabalha com classes de objetos, associações entre as classes e instancias de objetos. Linguagens OO torna possível a criação de mapeamentos diretos entre objetos do modelo com seus relacionamentos.