SlideShare uma empresa Scribd logo
1 de 48
Domain Driven Design
Daniel Everling
danieleverling@gmail.com
Quem Sou?
Profissional com mais de 8 anos de experiência
na área de desenvolvimento de aplicações web.
Graduado em Sistemas para Internet pela
Feevale.
Pós-Graduado em Engenharia de Software pela
Decision/Infnet.
Pós-Graduando em Arquitetura de Software pela
IGTI
Entusiasta quando o assunto é arquitetura,
qualidade de software, testes, clean code, DDD,
CQRS e Event Sourcing.
Entrevista com usuário
Precisamos ter segurado
com cpf, cnh e e-mail
válidos, N contatos, além
de poder adicionar
dependentes a apólice
de seguro.
OK, precisamos salvar
segurado em uma
tabela, validar seu CPF
e e-mail, e ter uma
tabela para salvar os
contatos, dependentes
e apólice de seguro
Como seria uma implementação deste cenário?
Da forma “tradicional”, teríamos algo como!
Da forma “tradicional”, teríamos algo como!
Da forma “tradicional”, teríamos algo como!
Da forma “tradicional”, pensamos em dados!
● Pensamos em dados, modelamos o banco de dados e fazemos nossas classes
“espelharem” um banco de dados
● Pensamos em camadas:
○ Camada de Apresentação;
○ Camada de Serviço;
○ Camada de Persistência.
● Utilizamos modelo anêmico, pois nossas classes são POJOs, e o negócio é
resolvido pela camada de serviço
○ Possuímos classes somente com DADOS outras somente COMPORTAMENTO.
○ Assim, DADOS e COMPORTAMENTO ficam desacoplados como unidades / componentes de
negócio.
Data Centric Model
DB
Reflexão!
1. Quantas vezes abrimos o modelo
ER durante a sprint?
2. No desenvolvimento da sprint,
debatemos mais sobre o negócio
ou sobre os dados?
3. Sabemos que objetos acoplados
são ruins, mas o acoplamento de
negócio entre camadas não é
pior?
4. Será que não programamos de
maneira procedural dentro de uma
linguagem Orientada a Objetos?
E o DDD?
Não é!
Domain Driven Design
● O DDD é uma abordagem de modelagem de software que segue um conjunto de
práticas com objetivo de facilitar a implementação de complexas regras /
processos de negócios que tratamos como domínio.
● Domain Driven Design como o nome já diz é sobre design. Design guiado pelo
domínio, ou seja, uma modelagem de software focada em resolver problemas na
complexidade do negócio.
O que é um domínio ?
Como seria o domínio desta fábrica ?
Provavelmente falaríamos de:
1. Esteira de Produção
2. Produtos / N domínio de Produtos
3. Trabalhadores
4. Logística
5. Almoxarifado
E cada um destes processos poderiam
ser um sub-domínio específico com
suas regras específicas
● Domínio é um processo que nossos clientes executam no dia-a-dia.
● Domínio é o que o cliente faz, é seu negócio.
O que é um modelo?
O que é um modelo?
● Modelos são uma simplificação da realidade
● Com DDD, o modelo é o código, e o código é o modelo.
● Quadro Branco
● BDD
● TDD
Por onde começamos a modelagem com DDD?
Linguagem Ubíqua / Linguagem Onipresente
● A Linguagem Ubíqua é uma linguagem compartilhada e desenvolvida pelo
Domain Experts e de pela equipe de desenvolvimento.
● A Linguagem Ubíqua é a linguagem do negócio dentro da empresa e todos
devem fazer uso dela para expressar corretamente todos processos / intenções
de negócio.
Linguagem Ubíqua / Linguagem Onipresente
Nos requisitos o cliente usou palavras como:
● Segurado
● Dependente
● CNH
● Apólices podem ter dependentes
● Dependentes podem ser desativados
Tais conceitos de negócio necessitam estar refletidos no modelo e no nosso código,
pois elas fazem parte do domínio que nossos usuários conhecem.
Quando não respeitamos a linguagem ubíqua.
Modelagem estratégica ou projeto estratégico
● bounded context
● mapa de contextos
● núcleo compartilhado
● camada anti-corrupção
Darwin e Mendel
Como implementamos o modelo?
Modelagem Tática
● Entity (Entidade)
○ Uma entidade do domínio, é uma classe que possui identidade e um ciclo de vida, além de
possuir estados, comportamentos e lógica de negócio (lógica de domínio).
● Value Object
○ Um objeto que agrega valor de negócio as entidades, não possui identidade e deve ser imutável.
● Agregados
○ Compostos de Entidades ou Objetos de Valores que são encapsulados numa única classe. O
Agregado serve para manter a integridade do modelo.
Modelagem Tática
● Factory
○ Classe responsável por construir adequadamente uma raiz de agregação e ou entidades. Algumas
vezes, agregados são relativamente complexos e não queremos manter a lógica de criação desses
agregados nas classes que o compõem.
● Repository
○ Uma classe que tem a finalidade de abstrair a persistência do domínio. Ela existe com a finalidade
de facilitar a linguagem ubíqua ao falarmos sobre conceitos de persistência de uma raiz de
agregação / entidade.
● Domain Service
○ Serviço do domínio servem para lógica de negócio que não possuem em “lar”, ou seja, conceitos de
domínio que envolvem N entidades e sua lógica de negócio não é responsabilidade de nenhuma
destas.
Como ficaria então a implementação?
Juntando tudo teremos algo assim!
O domínio ficou rico.
Ligando conceitos a implementação!
● Entidade
Ligando conceitos a implementação!
● Value Object
Ligando conceitos a implementação!
● Agregados
Ligando conceitos a implementação!
● pacotes ou namespaces != Módulos
Logo DDD tem haver com...
● Entender o negócio do cliente
● O negócio será sempre o centro dos debates
● Colocar o negócio a frente de tecnologias e frameworks, primeiro vamos pensar
em como resolver o problema do cliente
● Integração entre desenvolvedores e especialistas de domínio
● Extrair e entender a linguagem do cliente é de extrema importância para reduzir
o gap de contexto entre os times de desenvolvimento com o cliente
● Entender o contexto de cada domínio para evitar redundância de código /
negócio e modelar as necessidades de determinado contexto
E o que não é DDD?
O que não é DDD
Como aplicar com hexagonal.
Erros comuns ao aplicar DDD
● Permitir que a persistência / repositório influencie no modelo de domínio.
● Não se envolver com os especialistas do domínio.
● Ignorar a linguagem ubíqua, ou seja, a linguagem do especialista do domínio.
● Não identificar corretamente os contextos e suas fronteiras.
● Usar um modelo de domínio anêmico.
● Concentrar-se na infraestrutura.
● Achar que DDD é sobre tecnologia.
● Achar que DDD é uma arquitetura em camadas.
Quando não usar DDD?
Quando não usar DDD
● Sistemas sem muitas regras de negócio, sistemas que são praticamente CRUD.
● Sistemas conversacionais / transacionais.
● Sistemas com domínios instáveis.
Benefícios ao utilizar DDD
O que DDD tem haver com micro serviços?
DDD e micro serviços
● Um micro serviço é um possível bounded context.
● DDD facilita o entendimento, descoberta e modelagem de micro serviços
● Práticas como bounded context nos ajudam a visualizar / descobrir serviços
● A implementação do modelo rico faz com que os micro serviços tornem-se
menos acoplados facilitando a manutenção e evolução do mesmo
Por onde começar?
Por onde começar?
Por onde começar?
● http://www.eduardopires.net.br/2016/08/ddd-nao-e-arquitetura-em-camadas/
● http://www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design
● https://www.infoq.com/br/news/2016/05/ddd-microservices-evans
● https://www.infoq.com/br/news/2016/01/architecture-ddd-cqrs
● https://www.kenneth-truyers.net/2013/12/05/introduction-to-domain-driven-
design-cqrs-and-event-sourcing/
● http://www.eduardopires.net.br/2016/03/ddd-bounded-context/
● https://martinfowler.com/bliki/BoundedContext.html
Implementação
https://github.com/DanielEverling/ProjetoDominioAnemico
https://github.com/DanielEverling/ProjetoOrientadoAoDominio
https://github.com/citerus/dddsample-core
https://github.com/VaughnVernon/IDDD_Samples
Dúvidas?
Domain Driven Design

Mais conteúdo relacionado

Mais procurados (7)

Entendendo Domain-Driven Design
Entendendo Domain-Driven DesignEntendendo Domain-Driven Design
Entendendo Domain-Driven Design
 
Domain Driven Design - Aplicando estrategias e padrões
Domain Driven Design - Aplicando estrategias e padrõesDomain Driven Design - Aplicando estrategias e padrões
Domain Driven Design - Aplicando estrategias e padrões
 
Domain Driven Design (DDD)
Domain Driven Design (DDD)Domain Driven Design (DDD)
Domain Driven Design (DDD)
 
Criando software para o futuro com DDD, Arquitetura, Patterns, e Atitude
Criando software para o futuro com DDD, Arquitetura, Patterns, e AtitudeCriando software para o futuro com DDD, Arquitetura, Patterns, e Atitude
Criando software para o futuro com DDD, Arquitetura, Patterns, e Atitude
 
DDD - Domain Driven Design
DDD - Domain Driven DesignDDD - Domain Driven Design
DDD - Domain Driven Design
 
DDD - Domain Driven Design
DDD - Domain Driven DesignDDD - Domain Driven Design
DDD - Domain Driven Design
 
clean code
clean codeclean code
clean code
 

Semelhante a Domain Driven Design

Introdução ao Domain-Driven Design
Introdução ao Domain-Driven DesignIntrodução ao Domain-Driven Design
Introdução ao Domain-Driven Design
André Borgonovo
 
Uma introdução ao Domain Driven Design
Uma introdução ao Domain Driven DesignUma introdução ao Domain Driven Design
Uma introdução ao Domain Driven Design
Lambda3
 

Semelhante a Domain Driven Design (20)

DDD
DDDDDD
DDD
 
Domain driven-design
Domain driven-designDomain driven-design
Domain driven-design
 
Introdução ao Domain-Driven Design
Introdução ao Domain-Driven DesignIntrodução ao Domain-Driven Design
Introdução ao Domain-Driven Design
 
A importância de DDD e o Domain Model na construção de APIs!
A importância de DDD e o Domain Model na construção de APIs!A importância de DDD e o Domain Model na construção de APIs!
A importância de DDD e o Domain Model na construção de APIs!
 
Esquenta TDC - Como DDD e principalmente Domain Model contribuem na construçã...
Esquenta TDC - Como DDD e principalmente Domain Model contribuem na construçã...Esquenta TDC - Como DDD e principalmente Domain Model contribuem na construçã...
Esquenta TDC - Como DDD e principalmente Domain Model contribuem na construçã...
 
Domain-Driven-Design
Domain-Driven-DesignDomain-Driven-Design
Domain-Driven-Design
 
Domain-Driven Design
Domain-Driven DesignDomain-Driven Design
Domain-Driven Design
 
Uma introdução ao Domain Driven Design
Uma introdução ao Domain Driven DesignUma introdução ao Domain Driven Design
Uma introdução ao Domain Driven Design
 
DDD e PHP - TDC 2012
DDD e PHP - TDC 2012DDD e PHP - TDC 2012
DDD e PHP - TDC 2012
 
Domain Driven Design - Uma introdução
Domain Driven Design - Uma introduçãoDomain Driven Design - Uma introdução
Domain Driven Design - Uma introdução
 
Introdução a Domain-Driven Design
Introdução a Domain-Driven DesignIntrodução a Domain-Driven Design
Introdução a Domain-Driven Design
 
Domain-Driven Design - Uma Abordagem Introdutória
Domain-Driven Design - Uma Abordagem IntrodutóriaDomain-Driven Design - Uma Abordagem Introdutória
Domain-Driven Design - Uma Abordagem Introdutória
 
Domain Driven Design: como modelar uma aplicação em Node.js com DDD
Domain Driven Design: como modelar uma aplicação em Node.js com DDDDomain Driven Design: como modelar uma aplicação em Node.js com DDD
Domain Driven Design: como modelar uma aplicação em Node.js com DDD
 
Domain Driven Design com Python
Domain Driven Design com PythonDomain Driven Design com Python
Domain Driven Design com Python
 
Domain Driven Design : Pensando Fora da Caixa
Domain Driven Design : Pensando Fora da CaixaDomain Driven Design : Pensando Fora da Caixa
Domain Driven Design : Pensando Fora da Caixa
 
Seja um desenvolvedor disruptivo, e se torne um grande DevOps
Seja um desenvolvedor disruptivo, e se torne um grande DevOpsSeja um desenvolvedor disruptivo, e se torne um grande DevOps
Seja um desenvolvedor disruptivo, e se torne um grande DevOps
 
Encontrando equilíbrio do DDD enquanto sua aplicação cresce
Encontrando equilíbrio do DDD enquanto sua aplicação cresceEncontrando equilíbrio do DDD enquanto sua aplicação cresce
Encontrando equilíbrio do DDD enquanto sua aplicação cresce
 
Padrões Web & Code Standard
Padrões Web & Code StandardPadrões Web & Code Standard
Padrões Web & Code Standard
 
Indo além do técnico para desenvolver sistemas que evoluem na velocidade do...
Indo além do técnico para desenvolver sistemas que evoluem na velocidade do...Indo além do técnico para desenvolver sistemas que evoluem na velocidade do...
Indo além do técnico para desenvolver sistemas que evoluem na velocidade do...
 
DDD e Microsservicos - do negócio à arquitetura
DDD e Microsservicos - do negócio à arquiteturaDDD e Microsservicos - do negócio à arquitetura
DDD e Microsservicos - do negócio à arquitetura
 

Domain Driven Design

  • 1. Domain Driven Design Daniel Everling danieleverling@gmail.com
  • 2. Quem Sou? Profissional com mais de 8 anos de experiência na área de desenvolvimento de aplicações web. Graduado em Sistemas para Internet pela Feevale. Pós-Graduado em Engenharia de Software pela Decision/Infnet. Pós-Graduando em Arquitetura de Software pela IGTI Entusiasta quando o assunto é arquitetura, qualidade de software, testes, clean code, DDD, CQRS e Event Sourcing.
  • 3. Entrevista com usuário Precisamos ter segurado com cpf, cnh e e-mail válidos, N contatos, além de poder adicionar dependentes a apólice de seguro. OK, precisamos salvar segurado em uma tabela, validar seu CPF e e-mail, e ter uma tabela para salvar os contatos, dependentes e apólice de seguro
  • 4. Como seria uma implementação deste cenário?
  • 5. Da forma “tradicional”, teríamos algo como!
  • 6. Da forma “tradicional”, teríamos algo como!
  • 7. Da forma “tradicional”, teríamos algo como!
  • 8. Da forma “tradicional”, pensamos em dados! ● Pensamos em dados, modelamos o banco de dados e fazemos nossas classes “espelharem” um banco de dados ● Pensamos em camadas: ○ Camada de Apresentação; ○ Camada de Serviço; ○ Camada de Persistência. ● Utilizamos modelo anêmico, pois nossas classes são POJOs, e o negócio é resolvido pela camada de serviço ○ Possuímos classes somente com DADOS outras somente COMPORTAMENTO. ○ Assim, DADOS e COMPORTAMENTO ficam desacoplados como unidades / componentes de negócio.
  • 10. Reflexão! 1. Quantas vezes abrimos o modelo ER durante a sprint? 2. No desenvolvimento da sprint, debatemos mais sobre o negócio ou sobre os dados? 3. Sabemos que objetos acoplados são ruins, mas o acoplamento de negócio entre camadas não é pior? 4. Será que não programamos de maneira procedural dentro de uma linguagem Orientada a Objetos?
  • 13. Domain Driven Design ● O DDD é uma abordagem de modelagem de software que segue um conjunto de práticas com objetivo de facilitar a implementação de complexas regras / processos de negócios que tratamos como domínio. ● Domain Driven Design como o nome já diz é sobre design. Design guiado pelo domínio, ou seja, uma modelagem de software focada em resolver problemas na complexidade do negócio.
  • 14. O que é um domínio ? Como seria o domínio desta fábrica ? Provavelmente falaríamos de: 1. Esteira de Produção 2. Produtos / N domínio de Produtos 3. Trabalhadores 4. Logística 5. Almoxarifado E cada um destes processos poderiam ser um sub-domínio específico com suas regras específicas ● Domínio é um processo que nossos clientes executam no dia-a-dia. ● Domínio é o que o cliente faz, é seu negócio.
  • 15. O que é um modelo?
  • 16. O que é um modelo? ● Modelos são uma simplificação da realidade ● Com DDD, o modelo é o código, e o código é o modelo. ● Quadro Branco ● BDD ● TDD
  • 17. Por onde começamos a modelagem com DDD?
  • 18. Linguagem Ubíqua / Linguagem Onipresente ● A Linguagem Ubíqua é uma linguagem compartilhada e desenvolvida pelo Domain Experts e de pela equipe de desenvolvimento. ● A Linguagem Ubíqua é a linguagem do negócio dentro da empresa e todos devem fazer uso dela para expressar corretamente todos processos / intenções de negócio.
  • 19. Linguagem Ubíqua / Linguagem Onipresente Nos requisitos o cliente usou palavras como: ● Segurado ● Dependente ● CNH ● Apólices podem ter dependentes ● Dependentes podem ser desativados Tais conceitos de negócio necessitam estar refletidos no modelo e no nosso código, pois elas fazem parte do domínio que nossos usuários conhecem.
  • 20. Quando não respeitamos a linguagem ubíqua.
  • 21. Modelagem estratégica ou projeto estratégico ● bounded context ● mapa de contextos ● núcleo compartilhado ● camada anti-corrupção
  • 24. Modelagem Tática ● Entity (Entidade) ○ Uma entidade do domínio, é uma classe que possui identidade e um ciclo de vida, além de possuir estados, comportamentos e lógica de negócio (lógica de domínio). ● Value Object ○ Um objeto que agrega valor de negócio as entidades, não possui identidade e deve ser imutável. ● Agregados ○ Compostos de Entidades ou Objetos de Valores que são encapsulados numa única classe. O Agregado serve para manter a integridade do modelo.
  • 25. Modelagem Tática ● Factory ○ Classe responsável por construir adequadamente uma raiz de agregação e ou entidades. Algumas vezes, agregados são relativamente complexos e não queremos manter a lógica de criação desses agregados nas classes que o compõem. ● Repository ○ Uma classe que tem a finalidade de abstrair a persistência do domínio. Ela existe com a finalidade de facilitar a linguagem ubíqua ao falarmos sobre conceitos de persistência de uma raiz de agregação / entidade. ● Domain Service ○ Serviço do domínio servem para lógica de negócio que não possuem em “lar”, ou seja, conceitos de domínio que envolvem N entidades e sua lógica de negócio não é responsabilidade de nenhuma destas.
  • 26. Como ficaria então a implementação?
  • 27. Juntando tudo teremos algo assim!
  • 29. Ligando conceitos a implementação! ● Entidade
  • 30. Ligando conceitos a implementação! ● Value Object
  • 31. Ligando conceitos a implementação! ● Agregados
  • 32. Ligando conceitos a implementação! ● pacotes ou namespaces != Módulos
  • 33. Logo DDD tem haver com... ● Entender o negócio do cliente ● O negócio será sempre o centro dos debates ● Colocar o negócio a frente de tecnologias e frameworks, primeiro vamos pensar em como resolver o problema do cliente ● Integração entre desenvolvedores e especialistas de domínio ● Extrair e entender a linguagem do cliente é de extrema importância para reduzir o gap de contexto entre os times de desenvolvimento com o cliente ● Entender o contexto de cada domínio para evitar redundância de código / negócio e modelar as necessidades de determinado contexto
  • 34. E o que não é DDD?
  • 35. O que não é DDD
  • 36. Como aplicar com hexagonal.
  • 37. Erros comuns ao aplicar DDD ● Permitir que a persistência / repositório influencie no modelo de domínio. ● Não se envolver com os especialistas do domínio. ● Ignorar a linguagem ubíqua, ou seja, a linguagem do especialista do domínio. ● Não identificar corretamente os contextos e suas fronteiras. ● Usar um modelo de domínio anêmico. ● Concentrar-se na infraestrutura. ● Achar que DDD é sobre tecnologia. ● Achar que DDD é uma arquitetura em camadas.
  • 39. Quando não usar DDD ● Sistemas sem muitas regras de negócio, sistemas que são praticamente CRUD. ● Sistemas conversacionais / transacionais. ● Sistemas com domínios instáveis.
  • 41. O que DDD tem haver com micro serviços?
  • 42. DDD e micro serviços ● Um micro serviço é um possível bounded context. ● DDD facilita o entendimento, descoberta e modelagem de micro serviços ● Práticas como bounded context nos ajudam a visualizar / descobrir serviços ● A implementação do modelo rico faz com que os micro serviços tornem-se menos acoplados facilitando a manutenção e evolução do mesmo
  • 45. Por onde começar? ● http://www.eduardopires.net.br/2016/08/ddd-nao-e-arquitetura-em-camadas/ ● http://www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design ● https://www.infoq.com/br/news/2016/05/ddd-microservices-evans ● https://www.infoq.com/br/news/2016/01/architecture-ddd-cqrs ● https://www.kenneth-truyers.net/2013/12/05/introduction-to-domain-driven- design-cqrs-and-event-sourcing/ ● http://www.eduardopires.net.br/2016/03/ddd-bounded-context/ ● https://martinfowler.com/bliki/BoundedContext.html