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

Apresentação em tema: "O que é Domain Driven Design Especificação Design Refactor Testes Quanto tempo isso leva?"— Transcrição da apresentação:

1

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

3 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.

4 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.

5 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.

6 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.

7 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...

8 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).

9 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.

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