[DDD Brasil] Então você quer ser um praticante de DDD

Aprenda do que o DDD se trata e de onde parte seus conceitos fundamentais: a modelagem estratégica.

Transcript

1. Então você quer ser um praticante de DDD @talyssonoc
2. Talysson Oliveira Software architect & Chief Learning Officer na Codeminer42 @talyssonoc beacons.ai/talyssonoc
3. codeminer42.com @codeminer42
4. Existem muitos equívocos em torno de Domain-Driven Design
5. - DDD só adiciona complexidade desnecessária no código - DDD é um tipo de arquitetura de software - DDD é uma forma de organizar pastas e arquivos - Aplicações que aplicam DDD tem arquivos demais - Para usar DDD tem que usar um monte de design patterns - DDD torna o código difícil de entender - Nunca precisei usar DDD pro meu software funcionar - …
6. Resumos, vídeos e "exemplos" que pulam as partes importantes 😱
7. Esqueça tudo que você já ouviu falar sobre DDD
8. Pare de achar que DDD é uma arquitetura de software
9. Inclusive pare de associar DDD a código por um instante
10. Para praticar DDD, você precisa saber do que ele se trata
11. "O coração de um software é sua habilidade de resolver problemas relacionados ao domínio para seus usuários" Domain-Driven Design - Eric Evans
12. Domínio - Finanças - Saúde - Educação - Comércio - Aviação - Mineração - Transporte - … Problema Sistema de abstrações que descrevem aspectos específicos do domínio, usado para resolver problemas relacionados ao domínio Modelo
13. Automóveis (Domínio) Automodelo
14. Como é cultivado o modelo?
15. Especialistas de domínio Especialistas de desenvolvimento
16. Especialistas de domínio Especialistas de desenvolvimento Modelo
17. Especialistas de domínio Especialistas de desenvolvimento Modelo Linguagem ubíqua
18. DDD é uma abordagem de desenvolvimento onde: - Focamos no domínio - Exploramos modelos colaborativamente entre especialistas de domínio e de desenvolvimento - Falamos uma linguagem ubíqua
19. O modelo e a linguagem ubíqua são universais? Não (pelo menos na maior parte dos casos)
20. Carro
21. Produto
22. Um modelo e sua linguagem ubíqua são limitados à um contexto
23. Projetos tendem a ter múltiplos modelos em atividade ao mesmo tempo
24. Projetos tendem a ter múltiplos contextos em atividade ao mesmo tempo
25. Contexto limitado (bounded context) Uma divisão onde um modelo e uma linguagem ubíqua se aplicam
26. Mantendo a integridade do modelo
27. Integração contínua (continuous integration) - Mesmo em contextos bem definidos, trabalhar em time incorre na tendência de fragmentação do modelo - Não temos ferramentas que nos permitam testar e garantir a corretude puramente do modelo - O processo de Integração Contínua é baseado na integração de conceitos no modelo, que eventualmente se torna concreta através do código - O código, como expressão e implementação do modelo, pode ser testado!
28. Utilize o processo de Integração Contínua como indicador de fragmentação e quebra de integridade do modelo
31. Mapeamento de contextos (context mapping) - Definição dos pontos de contato entre modelos, delimitando mecanismos de compartilhamento, isolamento e influência entre eles - Descoberta das relações entre os contextos que impõe restrições na natureza do modelo ou no ritmo viável para mudanças - Muitas vezes a natureza dessa relação pode ser inclusive não-técnica - Ex.: serviço terceirizado de processamento de pagamentos
32. Supplier Customer Depende Reconhece e coopera Upstream Downstream Published language Anticorruption layer
33. Upstream e downstream - Relação entre dois contextos onde: - As ações de contexto em upstream afetam o sucesso do contexto em downstream - Mas o contexto em downstream não afeta significativamente aquele em upstream - Exemplo: - Duas cidades na descida de um rio - A poluição da cidade mais acima (upstream) afeta a cidade mais abaixo (downstream) - A poluição da cidade mais abaixo tem pouco ou nenhum efeito na cidade acima
34. Linguagem publicada (published language) - A forma com que um contexto define como a comunicação com ele é feita - Uma linguagem compartilhada entre o modelo e seu(s) cliente(s) - Frequentemente expressada através de padrões de troca de dados: - JSON + REST (+ Swagger) - JSON + GraphQL - Protobuf + gRPC - AMQP + eventos documentados - XML + SOAP
35. Camada anticorrupção (anticorruption layer) - Interface através da qual será feita a tradução entre os modelos de dois contextos que se comunicam - Protege o contexto em downstream de não ser corrompido pelo upstream - Esta camada conhece a Linguagem Publicada do contexto em upstream - A tradução é feita tanto para entrada quanto saída de dados - Exemplos: - Classes de mapeamento/adapters - Wrappers em volta de SDKs, clients de APIs e consumers de eventos
36. Supplier Customer Depende Reconhece e coopera Upstream Downstream Published language Anticorruption layer
37. Upstream Conformist Não coopera Published language Se conforma Downstream Depende
38. Open Host Service Customer Customer Depende Depende Upstream Downstream Downstream Published language Anticorruption layer Anticorruption layer
39. Partner Partner Coopera e depende Coopera e depende Upstream & Downstream Upstream & Downstream Published language Published language Anticorruption layer Anticorruption layer
40. Shared kernel
41. Separate ways
42. Porém, nem tudo são flores…
43. Big ball of mud
45. Design estratégico
46. Fonte: <https://twitter.com/ScottWlaschin/status/1225761214699098113>
47. Obrigado! @talyssonoc beacons.ai/talyssonoc