DDD Domain Driven Design O que Domain Driven

DDD Domain Driven Design

O que é Domain Driven Design �Especificação �Design �Refactor �Testes �Quanto tempo isso leva?

O que é Domain Driven Design �Não podemos sentar e sair digitando código. �Devemos conhecer o objetivo do software. �Devemos conhecer o domínio de negócio (Domain) �Quem conhece o domínio? �Sempre devemos começar o desenvolvimento aprendendo sobre o domínio. �O software é criado para atender o domínio.

Começamos com o domínio, e depois? �Domínio é algo do mundo real. �Não pode ser diretamente transformado em código. �Não é um simples diagrama. �Nem todo o domínio deve ser modelado. �Deve ser dividido em pequenas partes. �Lembrem-se, nós não estamos sozinhos. . . precisamos compartilhar esse conhecimento.

Code desigin. �Code design é diferente de software design. �Metodos de desenvolvimento de software. �Waterfall �Metodologias ágeis. �Vantagens do DDD. �Aumentar a habilidade do processo de desenvolvimento. �Implementar problemas complexos de uma forma que seja possível dar manutenção. �DDD combina o design com o desenvolvimento. �Um bom design acelera o desenvolvimento. �O feedback do desenvolvimento vai melhorar o design.

Exemplo pratico. Projeto Siscoserv. �Necessidade do usuário. �Gerar um arquivo com as aquisições de serviços internacionais. �Para isso preciso vincular um serviço ( NBS ) com minha aplicação e referência. �Visão do Analista de negócio. �Criar uma parametrização de NBS na tela de referência das aplicações. �Visão do desenvolvedor. �Colocar uma combo de NBS na tela 0306.

Exemplo pratico. Projeto Siscoserv. �Vimos que o produto final partia de uma parametrização na tela 0306. �A primeira alteração foi feita na tela. �Posteriormente foi feito todo o desenvolvimento de geração de arquivos XML referente ao dados que foram parametrizados na primeira tela. �Isso envolveu criação de novas tabelas, desenvolvimento de algumas telas para geração dos registros e arquivos XML. �Mas o que o usuário precisava. . .

Exemplo pratico. Projeto Siscoserv. �Necessidade real do usuário na homologação do projeto. �A mesma aplicação pode ter mais de um NBS. �Na verdade eu preciso além da aplicação e referência o segmento também tem que ser levado em conta. �Desenvolvedor (Eu). �Agora ferrou, vou ter que refazer a primeira tela e ajustar tudo que eu fiz porque houve um erro de design de software na primeira tela que foi alterada. �. . . Se tivessem homologado a primeira tela logo quando ela estava pronta o usuário já teria percebido isso antes de eu concluir todas telas do projeto (feedback rápido).

Construindo o conhecimento do domínio. �Fazendo as perguntas corretas e processando as respostas corretamente você começará a formar o esqueleto do modelo de domínio. �Esse esqueleto pode não ser completo e nem correto mas precisa começar de algum lugar. �O usuário conhece a sua área e organiza esse conhecimento de um modo específico, nem sempre é a melhor forma para ser implementada no software. �A analise dos desenvolvedores deve ser capaz de colocar essas ideias de forma organizada para que o software seja desenvolvido de forma simples e de fácil manutenção.

Próxima apresentação. . . �A necessidade de uma linguagem comum. � Ubiquitous language. �ncsolucoes. wordpress. com