Domain-Driven Design

Uma breve apresentação sobre o que é DDD, seus principais conceitos e pilares.
Desenvolvi este material para uma apresentação para disciplina de Engenharia de Software II, cursada durante o semestre 2024.2, na UFBA.

Transcript

1. DOMAIN-DRIVEN DESIGN por Matheus Victor
2. Técnico em Informática (IFBA) Bacharel Interdisciplinar em Ciência e Tecnologia (UFBA) Graduando em Sistemas de Informação (UFBA) Nerd aventureiro nas horas vagas MATHEUS VICTOR ENCONTRE-ME matheusvictor.github.io
3. ANTES DE QUALQUER COISA DDD é um assunto extremamente amplo e vai muito além de implementações técnicas; Não é objetivo dessa apresentação exaurir todos esses pontos, mas abordar seus principais conceitos e alguns de seus pilares.
4. O QUE NÃO É DDD
5. O QUE NÃO É DDD Não é uma metodologia; Não é uma arquitetura em camadas (embora uma arquiteturas desse tipo seja extremamente útil para isolamento do domínio); Não dita especificamente como seu código ou estrutura de pastas devem estar organizados; Não está restrito a uma linguagem específica; Design, nesse caso, não se refere se quer à elementos visuais dispostos numa tela ou layout da aplicação.
6. O QUE É DDD
7. O QUE É DDD Conceito desenvolvido por Eric Evans e publicado no livro "Domain-Driven Design: Atacando as Complexidades no Coração do Software" (2003); Uma abordagem para modelagem de desenvolvimento de software que centraliza o desenvolvimento na criação um modelo de domínio; Fornece ferramentas para modelagens estratégicas e táticas para atuar no coração do software, o domínio.
8. O QUE É DDD “O Domain-Driven Design é uma abordagem para o desenvolvimento de softwares complexos onde buscamos: 1. Nos concentrar no domínio principal; 2. Explorar modelos em uma colaboração criativa entre os profissionais de domínio e osprofissionais de software; 3. Falar numa Linguagem Onipresente dentro de um contexto limitado explicitamente.” (EVANS, 2015)
9. PILARES DO DDD alguns dos
10. DESIGN ESTRATÉGICO “É como fazer o rascunho antes de entrar nos detalhe da implementação [...] destaca o que é estrategicamente importante para o negócio; dividir o trabalho por importância; e como fazer fazer integração da melhor maneira" (Vaughn Vemon, citado por Código Fonte TV)
11. DESIGN ESTRATÉGICO Busca entender a “razão” do negócio, o propósito principal de uma organização; Ajuda a compreender como a organização está organizada e como as diferentes áreas de comunicam; Identifica as atividades core e as atividades de apoio; Auxilia a mapear as delimitações de contextos.
12. EXEMPLO calma, o slide não está vazio isso é um quadro para desenhos
13. EXEMPLO
14. LINGUAGEM UBÍQUA Uma linguagem "universal" que possibilita que as diferentes equipes envolvidas (desenvolvedores, POs, domain experts, etc.) possam se comunicar "sem ruídos"; Auxilia no descobrimento e definição das delimitações de contextos; Serve para que os setores possam entender suas dores específicas e também se entenderem entre si.
15. LINGUAGEM UBÍQUA IIlustração da importância centralizadora da linguagem universal. Imagem retirada em: https://www.infoq.com/articles/ddd-contextmapping/
16. LINGUAGEM UBÍQUA Um dos desafios da linguagem "universal" é a ambiguidade: Falar da mesma coisa com termos diferentes Ou usar termos diferentes para falar da mesma coisa.
17. LINGUAGEM UBÍQUA Ambiguidade para o termo “Account” em diferentes contextos. Imagem retirada em: https://www.infoq.com/articles/ddd-contextmapping/
18. CONTEXTOS DELIMITADOS Bounded Contexts são um delimitador do domínio; Cada contexto delimitado terá sua própria intenção de negócio, ainda que aja sobre o mesmo domínio; Cada contexto pode ter sua própria linguagem ubíqua, abordagem arquitetural, etc. “Dentro do limite, todos os termos e frases da Linguagem Ubíqua têm um significado específico” (BRITO, 2019). Colaboração entre devs e domain experts é importante para essa delimitação.
19. CONTEXTOS DELIMITADOS Diagrama ilustrativo sobre contextos delimitados. Imagem retirada em: https://www.brunobrito.net.br/domain-driven-design/
20. COMO DELIMITAR CONTEXTOS?
21. A PROBLEMÁTICA Minha empresa possui dois setores: suporte e financeiro; O setor de suporte é responsável por tirar dúvidas de alunos, enquanto o financeiro lida com boletos e afins; Se meu aluno tem uma dúvida sobre financeiro, em qual contexto isso se enquadra: suporte ou financeiro?
22. CONTEXTOS DELIMITADOS Além do domínio principal, temos contextos que funcionarão como auxiliares (ou subdomínios); Os contextos poderão comunicar-se entre si por meio de algum tipo de “relação”. Exemplo: fornecedores, conformistas , parceiros ou ACLs.
23. CONTEXTOS DELIMITADOS Mapa de delimitações de contextos e como estão relacionados. Imagem retirada em: https://www.infoq.com/articles/ddd-contextmapping/
24. DESIGN TÁTICO Reflete sobre a implementação; Complexidade de negócio x complexidade de técnica (ou ocasional); Pensa-se sobre quais padrões de projeto (design pattern) e arquiteturais serão utilizados; Busca-se isolar domínio da aplicação;
25. ARQUITETURA EM CAMADAS Diagrama de uma arquitetura em camadas. Imagem retirada do livro Domain-Driven Design: Atacando as Complexidades no Coração do Software
26. DESIGN TÁTICO Organizaçao de pastas, arquiteturas em camadas ou patterns (como entidades, objetos de valor, DTOs, etc.) serão extretamente úteis para esse objetivo; Diferentes contextos podem atuar com diferentes estratégias táticas para suas complexidades específicas.
27. ÓPERA RESUMO DA
28. RESUMO DA ÓPERA DDD é uma discussão mais sobre negócios do que código; Não há receita pronta: o diálogo é essencial!; As estratégias táticas devem entrar em ação após uma visão estratégica do negócio e suas delimitações de contextos: Evitar misturar complexidade técnica com as de negócios. Arquiteturas em camadas e padrões de projeto são artifícios táticos que devem ser usados para isolar o domínio e suas regras de negócios;
29. RESUMO DA ÓPERA Quando pensamos em DDD, é preciso refletir se o que está sendo resolvido é um problema de negócio ou problema técnico para suportar negócio.
30. JOGO RÁPIDO BATE BOLA, #REFLITÃO
31. DISCUSSÕES Pensar nas complexidades que atuem no coração do software é um trabalho que demanda tempo. Assim, o DDD pode ser tão problemático quanto o modelo cascata com relação ao tempo investido? Não necessariamente! Assim como DDD não está ligado diretamente à arquitetura, nada impede de utilizar metodologias ágeis para atuar com DDD; Mas, é inegável a necessidade investir tempo para definições de comunicação, delimitações de contextos, etc.
32. REFERÊNCIAS BRANDOLINI, Alberto. Strategic Domain Driven Design with Context Mapping. 2009. Disponível em: https://www.infoq.com/articles/ddd- contextmapping/. Acesso em: 17 de dezembro 2024. BRITO, Bruno. Domain-Driven Design - Conceitos básicos. 2019. Disponível em: https://www.brunobrito.net.br/domain-driven- design/. Acesso em: 12 de dezembro de 2024. Dias de Dev. DDD não é sobre arquitetura - O que é Domain-Driven Design. 2022. 14 min. Disponível em: https://www.youtube.com/ watch?v=SNdGV0c40yo. Acesso em: 12 de dezembro de 2024.
33. REFERÊNCIAS Dicionário do Programador. DDD (Domain-Driven Design). 2020. 10 min. Disponível em: https://youtu.be/GE6asEjTFv8? si=PBfNlfLDj6v2KQ9O. Acesso em: 12 de dezembro de 2024. EVANS, Eric. Domain-Driven Design Referência: Sumário de Padrões e Definições. 2015. FullCycle. Intensivo Domain Driven Design (DDD): Os 3 pilares que você precisa saber. 2022. 106 min. Disponível em: https:// www.youtube.com/watch?v=vFZkOyaPK4E. Acesso em: 12 de dezembro de 2024.
34. E OBRIGADO PELOS PEIXES ATÉ MAIS