SlideShare uma empresa Scribd logo
DDD
@henriquericcio
Antes de mais nada
Revisitando conceitos e princípios.
Layers
É uma forma de agrupar elementos que
possuem uma mesma responsabilidade.
Ex.:
Camada de Dados
Camada de Lógica de Negócio
Camada de Integração
Modelo
É aquilo que abstrai e expressa algo.
Ex.:
● Modelo matemático;
● Planta de edifícios;
● Modelo de domínio;
Modelar é importante, pois viabiliza a
transmissão de informações sobre o assunto.
Uncle Bob
Robert C. Martin
Escreveu diversos livros e artigos sobre OOP.
E aprensentou os seguintes princípios:
● ISP - Interface Segregation Principle
● SRP - Single Responsability Principle
● DIP - Dependency Inversion Principle
"Clientes não devem ser forçados a depender
de interfaces que eles não usam"
ISP
SRP
"Uma classe deve ter apenas uma simples
responsabilidade"
DIP
"algo deve depender de abstrações e não de
implementações."
Design Patterns
Design Patterns: Elements
of Reusable Object-Oriented
Software é um livro de
engenharia de software que
descreve soluções
recorrentes para problemas
comuns na modelagem de
software.
Factory Method
Um pattern criacional, responsável por abstrair
o processo de criação de objetos complexos.
P of EAA
Um livro sobre design
de software orientado
a objeto escrito por
Martin Fowler e
Colaboradores, no
qual abordou diversos
padrões.
Repository
Mediador entre o domínio e as camadas de mapeamento
de objeto, usando uma interface do estilo de coleção, para
acessar objetos de domínio.
Service Layer
Define um limite de
aplicação com uma camada
de serviços que estabelece
um grupo de operações
disponíveis e coordena a
resposta da aplicação para
cada operação.
Value Object
Um pequeno e simples objeto, como money ou
date range, cuja igualdade não é baseada na
identidade, mas sim nos valores de seus
atributos.
Data Transfer Object
Um objeto que transfere dados entre processos
com o intuíto de reduzir o número de
chamadas ao método.
Separated Interface
Define uma interface
em um pacote
separado de sua
implementação.
Remote Facade
Provê uma fachada, de baixa granularidade, para acesso
de objetos altamente granulares no intuito de melhorar a
eficiência de transmissão de rede.
Domain Model
Um modelo de objetos
do domínio que
incorpora
comportamento e
dados.
Agora sim...
Vamos comecar a falar de DDD.
Domain-Driven Design
Modelagem orientada ao domínio
Erick Evans lançou em 2003 o
“Domain-Driven Design: Tackling
Complexity in the Heart of
Software”.
Mas o que é?
Uma compilação de práticas para criação de
softwares que expressem as necessidades de
negócio através do modelo de domínio.
Layered Architecture
O Domain Layer deve ser
o mais isolado possível.
Usar DI ajuda!!!
User Interface Layer
Responsável por apresentar informação para o
usuário e interpretar seus comandos.
User Interface não é necessariamente uma
tela!
Application Layer
Uma fina camada que coordena a atividade da
aplicação. Ela não contem regra de negócio,
não mantém estado dos objetos de negócio,
mas pode manter o estado de uma tarefa da
aplicação.
Domain Layer
Esta camada contém informação sobre o
domínio. Este é o coração do software.O
estado dos objetos é mantido aqui.
Persistência dos objetos de negócio e
possivelmente seu estado são delegados à
camada de infraestrutura.
Infrastructure Layer
Esta camada age como uma biblioteca de
suporte para todas as outras camadas. Ela
provê comunicação entre camadas,
implementa persistência para objetos de
negócio, contem bibliotecas de suporte para a
camada de interface, etc
Domain Patterns
O DDD define o uso de alguns padrões para
modelagem de domínio:
● Repository
● Domain Service
● Factories
● Entities
● Value Objects
● Aggregates
Entity
● Possui uma identidade;
● Implementadas como
POCO's (POJO's);
● Métodos fortes (negócio);
● Constructor com a
identidade;
Value Object
● Imutáveis;
● Reconhecidos pelos seus
atributos;
● Constructor define o valor de
todos os atributos do objeto;
Domain Services
É a representação de serviços oferecidos ao
domínio. Todo comportamento que não pode
ser de responsabilidade de uma entidade, é
representado desta forma.
Factories
● Para criação de entidades;
● Encapsula a complexidade de criação;
Repositories
Representa, no domínio, a persistência da
entidade, que pode ser efetivamente realizada
em banco de dados, arquivo, ou até integração
com outro sistema.
Aggregates
Objetos se associam, uns aos outros, criando
relações complexas.
Dentre os objetos de uma relação, um possuí
maior expressão (naquele contexto).
Ex.: Conta Corrente e Lançamento
Ubiquotous Language
Traduzindo, “Linguagem Onipresente”, é a que
está em todo lugar. É a linguagem de quem
entende do negócio.
É uma forma de todos falarem a mesma língua,
a língua do negócio (Domínio).
Bounded Context
Continuous Refactoring
Refactoring do modelo!
Se a compreensão do problema mudou,
refatore!
Quando usar?
Quando o projeto envolve regras complexas
como processamento de uma fatura de cartão
de crédito.
Recursos
Livro Patterns of Enterprise Application Architecture - Martin Fowler
http://martinfowler.com/books/eaa.html
Princípios de Design OO - Uncle Bob
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Design Patterns: Elements of Reusable Object-Oriented Software (material oficial)
http://c2.com/cgi/wiki?DesignPatternsBook
Design patterns e exemplos em C#
http://www.dofactory.com/Patterns/Patterns.aspx
E-book gratuíto sobre DDD
http://www.infoq.com/minibooks/domain-driven-design-quickly
O livro do Eric Evans
http://www.amazon.com/exec/obidos/ASIN/0321125215/domainlanguag-20
Exemplo em C# usado para esse treinamento
https://github.com/henriquericcio/ExemploDDD

Mais conteúdo relacionado

Mais procurados

Domain-Driven Design - Aplicada a um estudo de caso
Domain-Driven Design - Aplicada a um estudo de casoDomain-Driven Design - Aplicada a um estudo de caso
Domain-Driven Design - Aplicada a um estudo de casoJairo Junior
 
Domain Driven Design – DDD além da teoria!, por Paulo Victor Gomes
Domain Driven Design – DDD além da teoria!, por Paulo Victor GomesDomain Driven Design – DDD além da teoria!, por Paulo Victor Gomes
Domain Driven Design – DDD além da teoria!, por Paulo Victor GomesiMasters
 
Introdução ao Domain-Driven Design
Introdução ao Domain-Driven DesignIntrodução ao Domain-Driven Design
Introdução ao Domain-Driven DesignAndré Borgonovo
 
DDD – Domain Driven Design
DDD – Domain Driven DesignDDD – Domain Driven Design
DDD – Domain Driven DesignJonatas Saraiva
 
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 DesignLambda3
 
Atacando as complexidades no coração do software
Atacando as complexidades no coração do softwareAtacando as complexidades no coração do software
Atacando as complexidades no coração do softwareYan Justino
 
Engenharia de Software Baseada em Componentes
Engenharia de Software Baseada em ComponentesEngenharia de Software Baseada em Componentes
Engenharia de Software Baseada em Componenteselliando dias
 
Padroes de projetos gof
Padroes de projetos gofPadroes de projetos gof
Padroes de projetos gofYan Justino
 
05 - Waldemir Cambiucci - Matriz de habilidades de um arquiteto TI
05 - Waldemir Cambiucci - Matriz de habilidades de um arquiteto TI05 - Waldemir Cambiucci - Matriz de habilidades de um arquiteto TI
05 - Waldemir Cambiucci - Matriz de habilidades de um arquiteto TIDNAD
 
O (papel do) Arquiteto de Software
O (papel do) Arquiteto de SoftwareO (papel do) Arquiteto de Software
O (papel do) Arquiteto de SoftwarePeter Jandl Junior
 
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de softwareReflexões sobre arquitetura de software
Reflexões sobre arquitetura de softwareTiago Sciencia
 
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em ComponentesTCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em ComponentesJuliano Tiago Rinaldi
 
Programação orientada à objetos & mvc
Programação orientada à objetos & mvcProgramação orientada à objetos & mvc
Programação orientada à objetos & mvcJhordam Siqueira
 
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óriaarmeniocardoso
 
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!Flávio Lisboa
 

Mais procurados (16)

Domain-Driven Design - Aplicada a um estudo de caso
Domain-Driven Design - Aplicada a um estudo de casoDomain-Driven Design - Aplicada a um estudo de caso
Domain-Driven Design - Aplicada a um estudo de caso
 
Domain Driven Design – DDD além da teoria!, por Paulo Victor Gomes
Domain Driven Design – DDD além da teoria!, por Paulo Victor GomesDomain Driven Design – DDD além da teoria!, por Paulo Victor Gomes
Domain Driven Design – DDD além da teoria!, por Paulo Victor Gomes
 
Introdução ao Domain-Driven Design
Introdução ao Domain-Driven DesignIntrodução ao Domain-Driven Design
Introdução ao Domain-Driven Design
 
DDD – Domain Driven Design
DDD – Domain Driven DesignDDD – Domain Driven Design
DDD – 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
 
Atacando as complexidades no coração do software
Atacando as complexidades no coração do softwareAtacando as complexidades no coração do software
Atacando as complexidades no coração do software
 
Engenharia de Software Baseada em Componentes
Engenharia de Software Baseada em ComponentesEngenharia de Software Baseada em Componentes
Engenharia de Software Baseada em Componentes
 
Desenvolvimento baseado em componentes
Desenvolvimento baseado em componentesDesenvolvimento baseado em componentes
Desenvolvimento baseado em componentes
 
Padroes de projetos gof
Padroes de projetos gofPadroes de projetos gof
Padroes de projetos gof
 
05 - Waldemir Cambiucci - Matriz de habilidades de um arquiteto TI
05 - Waldemir Cambiucci - Matriz de habilidades de um arquiteto TI05 - Waldemir Cambiucci - Matriz de habilidades de um arquiteto TI
05 - Waldemir Cambiucci - Matriz de habilidades de um arquiteto TI
 
O (papel do) Arquiteto de Software
O (papel do) Arquiteto de SoftwareO (papel do) Arquiteto de Software
O (papel do) Arquiteto de Software
 
Reflexões sobre arquitetura de software
Reflexões sobre arquitetura de softwareReflexões sobre arquitetura de software
Reflexões sobre arquitetura de software
 
TCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em ComponentesTCC - Engenharia de Software Baseada em Componentes
TCC - Engenharia de Software Baseada em Componentes
 
Programação orientada à objetos & mvc
Programação orientada à objetos & mvcProgramação orientada à objetos & mvc
Programação orientada à objetos & mvc
 
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
 
MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!MVC já era! O negócio é DCI!
MVC já era! O negócio é DCI!
 

Semelhante a Treinamento DDD .Net

DDD e PHP - TDC 2012
DDD e PHP - TDC 2012DDD e PHP - TDC 2012
DDD e PHP - TDC 2012Luís Cobucci
 
TDC2016SP - Trilha Microservices
TDC2016SP - Trilha MicroservicesTDC2016SP - Trilha Microservices
TDC2016SP - Trilha Microservicestdc-globalcode
 
Framework Entities - Apresentação da Defesa da Dissertacao
Framework Entities - Apresentação da Defesa da DissertacaoFramework Entities - Apresentação da Defesa da Dissertacao
Framework Entities - Apresentação da Defesa da DissertacaoMarcius Brandão
 
DDD – Domain Driven Design
DDD – Domain Driven DesignDDD – Domain Driven Design
DDD – Domain Driven DesignÍtalo Bandeira
 
Aula de Introdução - JAVA
Aula de Introdução  - JAVAAula de Introdução  - JAVA
Aula de Introdução - JAVAMoises Omena
 
Aula de Introdução - JAVA
Aula de Introdução  - JAVAAula de Introdução  - JAVA
Aula de Introdução - JAVAMoises Omena
 
Modelagem de sistemas
Modelagem de sistemasModelagem de sistemas
Modelagem de sistemassauloroos01
 
Como DDD e Strategic Design estão nos ajudando a modernizar um Legado
Como DDD e Strategic Design estão nos ajudando a modernizar um LegadoComo DDD e Strategic Design estão nos ajudando a modernizar um Legado
Como DDD e Strategic Design estão nos ajudando a modernizar um LegadoLuiz Costa
 
Plataforma Android: Produtividade Além do SDK
Plataforma Android: Produtividade Além do SDKPlataforma Android: Produtividade Além do SDK
Plataforma Android: Produtividade Além do SDKRyan Padilha
 
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!Isaac de Souza
 

Semelhante a Treinamento DDD .Net (20)

Domain-Driven Design
Domain-Driven DesignDomain-Driven Design
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
Domain Driven DesignDomain Driven Design
Domain Driven Design
 
Domain-Driven Design
Domain-Driven DesignDomain-Driven Design
Domain-Driven Design
 
TDC2016SP - Trilha Microservices
TDC2016SP - Trilha MicroservicesTDC2016SP - Trilha Microservices
TDC2016SP - Trilha Microservices
 
Design Patterns
Design PatternsDesign Patterns
Design Patterns
 
Framework Entities - Apresentação da Defesa da Dissertacao
Framework Entities - Apresentação da Defesa da DissertacaoFramework Entities - Apresentação da Defesa da Dissertacao
Framework Entities - Apresentação da Defesa da Dissertacao
 
Clean Architecture
Clean ArchitectureClean Architecture
Clean Architecture
 
UMLIntro.pptx
UMLIntro.pptxUMLIntro.pptx
UMLIntro.pptx
 
DDD – Domain Driven Design
DDD – Domain Driven DesignDDD – Domain Driven Design
DDD – Domain Driven Design
 
Corbawebserves
CorbawebservesCorbawebserves
Corbawebserves
 
Artigo oo em bd
Artigo   oo em bdArtigo   oo em bd
Artigo oo em bd
 
Aula de Introdução - JAVA
Aula de Introdução  - JAVAAula de Introdução  - JAVA
Aula de Introdução - JAVA
 
Aula de Introdução - JAVA
Aula de Introdução  - JAVAAula de Introdução  - JAVA
Aula de Introdução - JAVA
 
Modelagem de sistemas
Modelagem de sistemasModelagem de sistemas
Modelagem de sistemas
 
Padrões de Projeto de Software
Padrões de Projeto de SoftwarePadrões de Projeto de Software
Padrões de Projeto de Software
 
Como DDD e Strategic Design estão nos ajudando a modernizar um Legado
Como DDD e Strategic Design estão nos ajudando a modernizar um LegadoComo DDD e Strategic Design estão nos ajudando a modernizar um Legado
Como DDD e Strategic Design estão nos ajudando a modernizar um Legado
 
Plataforma Android: Produtividade Além do SDK
Plataforma Android: Produtividade Além do SDKPlataforma Android: Produtividade Além do SDK
Plataforma Android: Produtividade Além do SDK
 
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!
 
Aula1
Aula1Aula1
Aula1
 

Treinamento DDD .Net

  • 2. Antes de mais nada Revisitando conceitos e princípios.
  • 3. Layers É uma forma de agrupar elementos que possuem uma mesma responsabilidade. Ex.: Camada de Dados Camada de Lógica de Negócio Camada de Integração
  • 4. Modelo É aquilo que abstrai e expressa algo. Ex.: ● Modelo matemático; ● Planta de edifícios; ● Modelo de domínio; Modelar é importante, pois viabiliza a transmissão de informações sobre o assunto.
  • 5. Uncle Bob Robert C. Martin Escreveu diversos livros e artigos sobre OOP. E aprensentou os seguintes princípios: ● ISP - Interface Segregation Principle ● SRP - Single Responsability Principle ● DIP - Dependency Inversion Principle
  • 6. "Clientes não devem ser forçados a depender de interfaces que eles não usam" ISP
  • 7. SRP "Uma classe deve ter apenas uma simples responsabilidade"
  • 8. DIP "algo deve depender de abstrações e não de implementações."
  • 9. Design Patterns Design Patterns: Elements of Reusable Object-Oriented Software é um livro de engenharia de software que descreve soluções recorrentes para problemas comuns na modelagem de software.
  • 10. Factory Method Um pattern criacional, responsável por abstrair o processo de criação de objetos complexos.
  • 11. P of EAA Um livro sobre design de software orientado a objeto escrito por Martin Fowler e Colaboradores, no qual abordou diversos padrões.
  • 12. Repository Mediador entre o domínio e as camadas de mapeamento de objeto, usando uma interface do estilo de coleção, para acessar objetos de domínio.
  • 13. Service Layer Define um limite de aplicação com uma camada de serviços que estabelece um grupo de operações disponíveis e coordena a resposta da aplicação para cada operação.
  • 14. Value Object Um pequeno e simples objeto, como money ou date range, cuja igualdade não é baseada na identidade, mas sim nos valores de seus atributos.
  • 15. Data Transfer Object Um objeto que transfere dados entre processos com o intuíto de reduzir o número de chamadas ao método.
  • 16. Separated Interface Define uma interface em um pacote separado de sua implementação.
  • 17. Remote Facade Provê uma fachada, de baixa granularidade, para acesso de objetos altamente granulares no intuito de melhorar a eficiência de transmissão de rede.
  • 18. Domain Model Um modelo de objetos do domínio que incorpora comportamento e dados.
  • 19. Agora sim... Vamos comecar a falar de DDD.
  • 20. Domain-Driven Design Modelagem orientada ao domínio Erick Evans lançou em 2003 o “Domain-Driven Design: Tackling Complexity in the Heart of Software”.
  • 21. Mas o que é? Uma compilação de práticas para criação de softwares que expressem as necessidades de negócio através do modelo de domínio.
  • 22. Layered Architecture O Domain Layer deve ser o mais isolado possível. Usar DI ajuda!!!
  • 23. User Interface Layer Responsável por apresentar informação para o usuário e interpretar seus comandos. User Interface não é necessariamente uma tela!
  • 24. Application Layer Uma fina camada que coordena a atividade da aplicação. Ela não contem regra de negócio, não mantém estado dos objetos de negócio, mas pode manter o estado de uma tarefa da aplicação.
  • 25. Domain Layer Esta camada contém informação sobre o domínio. Este é o coração do software.O estado dos objetos é mantido aqui. Persistência dos objetos de negócio e possivelmente seu estado são delegados à camada de infraestrutura.
  • 26. Infrastructure Layer Esta camada age como uma biblioteca de suporte para todas as outras camadas. Ela provê comunicação entre camadas, implementa persistência para objetos de negócio, contem bibliotecas de suporte para a camada de interface, etc
  • 27. Domain Patterns O DDD define o uso de alguns padrões para modelagem de domínio: ● Repository ● Domain Service ● Factories ● Entities ● Value Objects ● Aggregates
  • 28. Entity ● Possui uma identidade; ● Implementadas como POCO's (POJO's); ● Métodos fortes (negócio); ● Constructor com a identidade;
  • 29. Value Object ● Imutáveis; ● Reconhecidos pelos seus atributos; ● Constructor define o valor de todos os atributos do objeto;
  • 30. Domain Services É a representação de serviços oferecidos ao domínio. Todo comportamento que não pode ser de responsabilidade de uma entidade, é representado desta forma.
  • 31. Factories ● Para criação de entidades; ● Encapsula a complexidade de criação;
  • 32. Repositories Representa, no domínio, a persistência da entidade, que pode ser efetivamente realizada em banco de dados, arquivo, ou até integração com outro sistema.
  • 33. Aggregates Objetos se associam, uns aos outros, criando relações complexas. Dentre os objetos de uma relação, um possuí maior expressão (naquele contexto). Ex.: Conta Corrente e Lançamento
  • 34. Ubiquotous Language Traduzindo, “Linguagem Onipresente”, é a que está em todo lugar. É a linguagem de quem entende do negócio. É uma forma de todos falarem a mesma língua, a língua do negócio (Domínio).
  • 36. Continuous Refactoring Refactoring do modelo! Se a compreensão do problema mudou, refatore!
  • 37. Quando usar? Quando o projeto envolve regras complexas como processamento de uma fatura de cartão de crédito.
  • 38. Recursos Livro Patterns of Enterprise Application Architecture - Martin Fowler http://martinfowler.com/books/eaa.html Princípios de Design OO - Uncle Bob http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Design Patterns: Elements of Reusable Object-Oriented Software (material oficial) http://c2.com/cgi/wiki?DesignPatternsBook Design patterns e exemplos em C# http://www.dofactory.com/Patterns/Patterns.aspx E-book gratuíto sobre DDD http://www.infoq.com/minibooks/domain-driven-design-quickly O livro do Eric Evans http://www.amazon.com/exec/obidos/ASIN/0321125215/domainlanguag-20 Exemplo em C# usado para esse treinamento https://github.com/henriquericcio/ExemploDDD