DDD na minha aplicaçãozinha - Padrões táticos para todos

Em diversos cursos, livros e até palestras sobre DDD, é muito comum ouvirmos:
"Não precisa usar DDD naquele seu CRUD ou aplicaçãozinha simples."

E se eu te disser que dá sim pra usar vários conceitos do DDD (e talvez você já até use) em qualquer aplicação, independente do tamanho, sem adicionar complexidade desnecessária ao código (famoso overengineering)?

Nesta palestra vamos falar sobre alguns padrões táticos citados no estudo de DDD como Entity, Value Objects, (Domain|Application|Infrastructure) Service, Repositories, Aggregates, etc.

Transcript

1. DDD na minha aplicaçãozinha Padrões táticos para todos!
2. Quem é Vinicius Dias? • Zend Certified (PHP) Engineer; • iMasters Certified PHP Professional; • Um dos administradores do PHP Rio; • Desenvolvedor Full Stack na TemboSocial; • Instrutor na Alura Cursos Online; • LinkedIn: https://linkedin.com/in/vinícius-dias/ • GitHub: https://github.com/CViniciusSDias • Twitter: @cviniciussdias • Blog: https://dias.dev/ • YouTube: Dias de Dev
3. Dias de Dev https://youtube.com/c/DiasDeDev
4. Dê feedback Os palestrantes gostam de saber como melhorar suas apresentações Nenhuma apresentação é perfeita e nós que criamos conteúdo sabemos disso. Nossa intenção é passar conteúdo da melhor forma possível e sua opinião é muito importante para isso.
5. "Bem começado, metade feito" O que é DDD?
6. Definição formal "Design orientado a domínio é o conceito de que a estrutura e o idioma do código de software devem corresponder ao domínio comercial." Pedia, Wiki
7. Definição de quem entende "É uma filosofia que permite a construção de software que seja mais fiel ao domínio de negócio, que seja mais expressivo e que fornece ferramentas para alcançar este resultado (que são os building blocks)." Marcel G. dos Santos (@marcelgsantos)
8. Definição de quem entende "É uma filosofia que permite a construção de software que seja mais fiel ao domínio de negócio, que seja mais expressivo e que fornece ferramentas para alcançar este resultado (que são os building blocks)." Marcel G. dos Santos (@marcelgsantos)
9. Separação: Padrões táticos vs Padrões estratégicos
10. Padrões estratégicos • Domínios ◦ Sub-domínios ◦ Domínio principal (core domain) • Contextos delimitados ◦ Mapas de contexto • Linguagem onipresente (ou ubíqua)
11. O que é essa tal de Linguagem Onipresente?
12. Aproximar comunicação • Nomes que façam sentido para o negócio ◦ Classes e métodos em OO ◦ Funções em FP • Técnicas ágeis para manter devs próximos do negócio • BDD
13. O que interessa: Padrões táticos do DDD
14. Building blocks • Objetos de valor • Entidades • Agregados • Repositórios • Serviços ◦ De domínio ◦ De infraestrutura ◦ De aplicação • Fábricas • Eventos • Módulos
15. Objetos do Domínio ou Modelo (o que muitos chamam de Model)
16. Existem 2 grandes tipos de Objetos de Domínio • Onde 2 objetos são iguais se seus valores são iguais • Onde 2 objetos são iguais se possuem a mesma identificação
17. Existem 2 grandes tipos de Objetos de Domínio • Onde 2 objetos são iguais se seus valores são iguais • Onde 2 objetos são iguais se possuem a mesma identificação
18. Comportamento desejado é a comparação por valor
19. Coordenadas iguais == mesmo ponto
20. Objetos de valor "In computer science, a value object is a small object whose equality is not based on identity: i.e. two value objects are equal when they have the same value, not necessarily being the same object" Pedia, Wiki
21. Existem 2 grandes tipos de Domain Models • Onde 2 objetos são iguais se seus valores são iguais • Onde 2 objetos são iguais se possuem a mesma identificação
22. 2 pessoas podem nascer na mesma data com o mesmo nome
23. Tipos de identidade • Referência do objeto • Identidade definida pelo negócio*
24. Referência do objeto
25. Identidade definida pelo negócio
26. Identidade vinda de serviços de apoio
27. E quando a composição é complexa?
28. E quando um objeto controla o acesso a outros?
29. Ninguém chega à resposta senão por mim
30. Agregados "A DDD aggregate is a cluster of domain objects that can be treated as a single unit. An example may be an order and its line-items, these will be separate objects, but it's useful to treat the order (together with its line items) as a single aggregate." Martin Fowler
31. Raiz de agregação (aggregate root)
32. Persistência de agregados • Na raiz da agregação deve haver a preocupação com a persistência • Locks devem ser utilizados ◦ Transações ◦ Optimistic locks
33. Agregados vs Coleções "DDD Aggregates are sometimes confused with collection classes (lists, maps, etc). DDD aggregates are domain concepts (order, clinic visit, playlist), while collections are generic. An aggregate will often contain multiple collections, together with simple fields." Martin Fowler
34. Já que falamos de persistência...
35. Uma entidade deve se persistir?
36. Uma entidade deve se persistir?
37. Repositórios fazem a cola
38. Repository vs DAO (Data Access Object) "The significant difference is that Repositories represent collections, while DAOs are closer to the database and are often far more table-centric" DDD in PHP
39. Agora a parte que cada um entende como quer: Serviços
40. Onde ficam regras de negócio? • Entidades e Value Objects • Aggregate roots
41. Regras dos nossos exemplos • CPF ◦ Deve conter 11 caracteres • Pessoa ◦ Nome deve ter pelo menos 5 caracteres e 1 espaço • Pergunta ◦ Pode ter no máximo 5 respostas possíveis • Resposta ◦ Texto não pode ser string vazia
42. Transformar um Carrinho em Pedido • Criar um método Carrinho::criarPedido • Receber um Carrinho no construtor do Pedido?
43. Serviços de domínio
44. E quando uma regra depende de detalhes externos?
45. Regras que dependem de infra • Criptografar senha de usuário • Gerar um UUID
46. Serviços de infraestrutura implementam serviços de domínio
47. E quem define o fluxo de um caso de uso do sistema?
48. Cadastrar um usuário • Receber os dados • Fazer hash da senha • Criar um objeto Usuario • Armazenar no banco
49. Serviços de aplicação
50. Application service vs Use case vs Command Handler vs Controller
51. Use Case x Command Handler x App Service Embora hajam formas diferentes de escrever determinadas partes, esses 3 são basicamente sinônimos e servem para a mesma coisa: Ditar o fluxo de execução de determinada tarefa
52. Controller Embora teoricamente o Controller também sirva para controlar fluxo, está diretamente ligado à Web. Se a mesma rotina precisar ser executada fora da Web, ter o fluxo no Controller pode ser um problema.
53. Building blocks • Objetos de valor • Entidades • Agregados • Repositórios • Serviços ◦ De domínio ◦ De infraestrutura ◦ De aplicação • Fábricas • Eventos • Módulos
54. Como separar isso tudo na prática?
55. Separação em módulos de negócio
56. Isso aí não tem mais a ver com arquitetura do que design?
57. Arquitetura e DDD Todos os padrões conceitos e princípios mostrados aqui podem ser aplicados em praticamente qualquer modelo arquitetural, mas uns ajudam mais e outros atrapalham mais.
59. MVC e DDD? É possível isso?
60. MVC e DDD • Faça com que o M do MVC esteja em conformidade com as ideias de DDD • Tenha em mente que algumas template engines podem dificultar migração de framework
61. E se eu puder me dar o luxo de não usar um framework MVC?
62. Clean Architecture, Hexagonal, Onion
63. Referências • DDD in PHP • Implementing Domain-Driven Design - Livro Vermelho • Domain-Driven Design: Tackling Complexity in the Heart of Software - Livro Azul • Clean (Code(r?)|Architecture)
64. Dúvidas? Não? Obrigado!
65. Avalie e dê feedbacks sinceros https://bit.ly/dias-ddd