120 likes | 380 Vues
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 )
E N D
O que é DomainDriven Design • Especificação • Design • Refactor • Testes • Quanto tempo isso leva?
O que é DomainDriven 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.
Codedesigin. • 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. • Ubiquitouslanguage. • ncsolucoes.wordpress.com