Modelando sua aplicação Ruby com Domain Driven Design

Entender e codificar requisitos do "mundo real" para um software muitas vezes é tempestuosa. Nesta apresentação irei falar sobre o Domain Driven Design e os seus elementos utilizados para projetar e estruturar o seu código a partir de uma linguagem úbiqua de seu projeto de forma a que ele reflita como o domínio ("mundo real') se comporta, mostrando exemplos e códigos de como aplicar em seu código.

Transcript

1. Modelando sua aplicação Ruby com Domain Driven Design
2. Desenvolvendo software no dia-a-dia
3. Mundo Real Software
4. Nas primeiras tentativas de mapear essa realidade...
5. Funciona !!!
6. #sqn
7. O problema / expectativa
8. Alinhamento de informações
9. O que esperamos
10. O que acontece
11. O que realmente acontece
12. Domain Driven Design
13. Domain Driven Design área de interesse onde o software será desenvolvido
14. Domain Driven Design área de interesse onde o software será desenvolvido o "como" estruturamos as partes internas do software para refletir o domínio
15. Como pensar o software? Código Arquitetura Design
16. Onde iremos nos focar Código Design
17. Em que estrutura?
18. O que esperamos
19. Começando a modelar
20. Linguagem úbiqua • Linguagem (termos, ações, papéis) que "permeia" todo o software e o seu processo de construção • Deve ser refletida e evoluir com o código!
21. Modelo Projeto Negócio Desenvolvedor Linguagem úbiqua Domínio
22. Ao problema !!!
23. Mas primeiro...
24. Não existe bala de prata !!!!!!!!!!!
25. A primeira especificação
26. "O coiso deve ser ligado junto com o treco para conseguir a outra coisa" Primeira descrição de domínio
28. "O coiso deve ser ligado junto com o treco para conseguir a outra coisa" Papéis
29. "O coiso deve ser ligado junto com o treco para conseguir a outra coisa" Ações
30. ligado com para conseguir
32. "O coiso deve ser usado no GPS para conseguir calcular a rota" Round 2
34. "O endereço deve ser usado no GPS para conseguir calcular a rota" Round 3, a.k.a. o que é o coiso?
36. Ok… mas e a estrutura do código?
37. DDD Tático: Building blocks
38. Building blocks Entidades Objetos de Valor Serviços Agregados Factories Repositórios
39. Building blocks "mais comuns" Entidades Objetos de Valor Serviços Repositórios
40. • Entidades: objeto com uma série de atributos definidos por uma identidade e linha de continuidade • Objeto de valor: objeto com uma série de atributos, sem identidade e imutável Building blocks
41. "Um endereço é único no sistema e deve ter um logradouro, número, CEP, cidade e tipo (residência ou trabalho)" "Uma rota é um conjunto de instruções ordenadas, que descrevem a direção a seguir para o destino" Entidades X Objetos de Valor
42. Entidades
43. Objetos de valor
44. • Serviços: comportamentos do domínio que não se enquadram em entidades e em objetos de valor, não possuem estado • Repositórios: serviço responsável por gerenciar o ciclo de vida das entidades na aplicação, persistir os dados de uma entidade em um mecanismo de armazenamento (banco de dados, arquivo, etc) Building blocks
45. Serviços
46. Repositórios
47. Let's code!
48. Aplicação de exemplo (estrutura)
49. • Livros: ◦ Domain Driven Design: Tackling Complexity in the Heart of Software ◦ Implementing Domain-Driven Design ◦ Domain-Driven Design Distilled ◦ Clean Architecture: A Craftsman's Guide to Software Structure and Design • Talks: ◦ GOTO 2017 • DDD Today - Modeling Uncertainty • Vaughn Vernon ◦ Eric Evans - Keynote: DDD Isn't Done: A Skeptical, Optimistic , Pragmatic Look Para saber mais...
50. That's all!
51. Engenheiro de Software na Resultados Digitais Mestre em Ciência da Computação (foco em IA) pela USP Quem sou?
52. Engenheiro de Software na Resultados Digitais Mestre em Ciência da Computação (foco em IA) pela USP Pai coruja / zumbi Quem sou?
53. Obrigado! https://github.com/danielbdias https://speakerdeck.com/danielbdias https://twitter.com/danielbdias