Your SlideShare is downloading. ×
0
Domain-Driven Design Uma Abordagem Introdutória
Apresentações <ul><li>Armênio Cardoso </li></ul><ul><li>Consultor, Arquiteto de Sistemas e Professor </li></ul>http://www....
Reflexões <ul><li>Quanto mais  simples  algo é, mais  fácil  é o seu  entendimento . </li></ul><ul><li>Quanto mais  comple...
Reflexões <ul><li>O  Desejo  de construir um software é diretamente proporcional ao seu  Valor  e inversamente proporciona...
Reflexões <ul><li>Nossa Missão </li></ul><ul><li>Desenvolver sistemas que... </li></ul><ul><ul><li>...tenham o  máximo  de...
Reflexões <ul><li>Cada vez mais as pessoas parecem confundir complexidade com sofisticação. </li></ul><ul><li>O incompreen...
Definições <ul><li>Domain-Driven Design  é uma abordagem para o Desenvolvimento de Software que estabelece uma forte ligaç...
Definições <ul><li>Domain-Driven Design  não é uma tecnologia ou uma metodologia.  </li></ul><ul><li>DDD  fornece uma estr...
Definições <ul><li>Domínio </li></ul><ul><ul><li>A esfera do conhecimento, influência ou atividade de negócio. </li></ul><...
Definições <ul><li>Idioma onipresente  (ubiquitous) </li></ul><ul><ul><li>Uma linguagem estruturada em torno do modelo de ...
Peças do DDD Model-Driven Design Layered Architecture
Arquitetura em Camadas
Arquitetura em Camadas <ul><li>User Interface : responsável pela apresentação das informações e interpretação das interaçõ...
Peças do DDD Entities
Peças do DDD <ul><li>Entities </li></ul><ul><ul><li>Entidades derivam objetos com identidade, distinção e continuidade (ci...
Peças do DDD Value Objects
Peças do DDD <ul><li>Value Objects </li></ul><ul><ul><li>Value Object é um tipo de objeto que é imutável e não tem identid...
Peças do DDD Aggregates
Peças do DDD <ul><li>Aggregates   </li></ul><ul><ul><li>É uma Entidade composta por outros objetos (Entities e/ou Value Ob...
Peças do DDD Services
Peças do DDD <ul><li>Services </li></ul><ul><ul><li>Quando uma operação de negócio não pertence conceitualmente a um único...
Peças do DDD <ul><li>Services </li></ul><ul><ul><li>A  Camada de Serviço  define os limites de uma aplicação e seu conjunt...
Peças do DDD Factories
Peças do DDD <ul><li>Factories </li></ul><ul><ul><li>Métodos para criar objetos de domínio complexos devem delegar a objet...
Peças do DDD Repositories
Peças do DDD <ul><li>Repositories </li></ul><ul><ul><li>Um repositório é um mecanismo para encapsular o armazenamento, rec...
Critérios de Sucesso <ul><li>Use  DDD  se </li></ul><ul><ul><li>O seu domínio não é trivial. </li></ul></ul><ul><ul><li>A ...
Critérios de Sucesso <ul><li>Domain-Driven Design  é um tema muito amplo e contém muitas coisas que são difíceis ou imposs...
Perguntas? e Obrigado!
Upcoming SlideShare
Loading in...5
×

Domain-Driven Design - Uma Abordagem Introdutória

826

Published on

Palestra proferida na semana de Engenharia de Software e Banco de Dados do Instituto Infnet.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
826
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
24
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Domain-Driven Design - Uma Abordagem Introdutória"

  1. 1. Domain-Driven Design Uma Abordagem Introdutória
  2. 2. Apresentações <ul><li>Armênio Cardoso </li></ul><ul><li>Consultor, Arquiteto de Sistemas e Professor </li></ul>http://www. linkedin .com/in/ armeniocardoso http://www. slideshare .net/ armeniocardoso
  3. 3. Reflexões <ul><li>Quanto mais simples algo é, mais fácil é o seu entendimento . </li></ul><ul><li>Quanto mais complexo algo é, mais difícil é o seu entendimento . </li></ul><ul><li>Quanto menos você entende algo, mais difícil é consertá-lo ou modificá-lo. </li></ul><ul><li>Conclusão : quanto mais complexo um </li></ul><ul><li>sistema fica, mais difícil e caro é mantê-lo. </li></ul>Max Kanat-Alexander, Code Simplicity.
  4. 4. Reflexões <ul><li>O Desejo de construir um software é diretamente proporcional ao seu Valor e inversamente proporcional ao Esforço dedicado a desenvolvê-lo. </li></ul><ul><li>D = (Vn + Vf) / (Ei + Em) </li></ul>Max Kanat-Alexander, Code Simplicity. Vi = Valor de Implementação Vf = Valor Futuro Ei = Esforço de Implementação Em = Esforço de Manutenção
  5. 5. Reflexões <ul><li>Nossa Missão </li></ul><ul><li>Desenvolver sistemas que... </li></ul><ul><ul><li>...tenham o máximo de Valor ... </li></ul></ul><ul><ul><li>...com o mínimo de Esforço de desenvolvimento. </li></ul></ul>
  6. 6. Reflexões <ul><li>Cada vez mais as pessoas parecem confundir complexidade com sofisticação. </li></ul><ul><li>O incompreensível deveria causar suspeita e não admiração. </li></ul><ul><li>Possivelmente, esta tendência resulta de uma crença errônea de que o uso de mistério confere uma aura de poder. </li></ul>Niklaus Wirth, “pai” da Linguagem Pascal.
  7. 7. Definições <ul><li>Domain-Driven Design é uma abordagem para o Desenvolvimento de Software que estabelece uma forte ligação entre a implementação e o modelo evolutivo dos conceitos de negócio. </li></ul><ul><li>Implementação X Negócios </li></ul>
  8. 8. Definições <ul><li>Domain-Driven Design não é uma tecnologia ou uma metodologia. </li></ul><ul><li>DDD fornece uma estrutura de práticas e terminologia para a tomada de decisões de design. </li></ul><ul><li>O foco é acelerar os projetos de software e alinhar com os domínios de negócio. </li></ul>
  9. 9. Definições <ul><li>Domínio </li></ul><ul><ul><li>A esfera do conhecimento, influência ou atividade de negócio. </li></ul></ul><ul><ul><li>A área de negócio que será abordada pelo projeto de software. </li></ul></ul><ul><li>Modelo </li></ul><ul><ul><li>Um sistema de abstrações que descreve aspectos selecionados de um domínio com o objetivo de resolver problemas de negócio. </li></ul></ul>
  10. 10. Definições <ul><li>Idioma onipresente (ubiquitous) </li></ul><ul><ul><li>Uma linguagem estruturada em torno do modelo de domínio e usado por todos os membros da equipe para conectar todas as atividades da equipe com o software. </li></ul></ul><ul><li>Contexto </li></ul><ul><ul><li>A situação onde uma palavra ou declaração aparece, determinando o seu significado. </li></ul></ul>
  11. 11. Peças do DDD Model-Driven Design Layered Architecture
  12. 12. Arquitetura em Camadas
  13. 13. Arquitetura em Camadas <ul><li>User Interface : responsável pela apresentação das informações e interpretação das interações dos usuários. </li></ul><ul><li>Application Layer : coordena as atividades da aplicação. </li></ul><ul><li>Domain Layer : contém os componentes de negócio – é o centro da aplicação. </li></ul><ul><li>Infraestructure Layer : provê o suporte para as outras camadas, bibliotecas, persistência etc. </li></ul>
  14. 14. Peças do DDD Entities
  15. 15. Peças do DDD <ul><li>Entities </li></ul><ul><ul><li>Entidades derivam objetos com identidade, distinção e continuidade (ciclo de vida). </li></ul></ul><ul><ul><li>Entidades podem ter atributos alterados sem que a identidade do objeto seja afetada. </li></ul></ul><ul><ul><li>Entidades contém métodos de negócio que implementam regras que se aplicam ao objeto em questão. </li></ul></ul><ul><ul><ul><li>Pessoa, Aluno, Professor, Nota-fiscal. </li></ul></ul></ul>
  16. 16. Peças do DDD Value Objects
  17. 17. Peças do DDD <ul><li>Value Objects </li></ul><ul><ul><li>Value Object é um tipo de objeto que é imutável e não tem identidade. </li></ul></ul><ul><ul><li>Value Object deriva objetos que são definidos pelos seus atributos e por isso são imutáveis. </li></ul></ul><ul><ul><li>Objetos de valor não têm métodos de negócio. </li></ul></ul><ul><ul><ul><li>Endereço, Itens da Nota-Fiscal, Unidade da Federação, Estado Civil, Usuário (login e senha). </li></ul></ul></ul>
  18. 18. Peças do DDD Aggregates
  19. 19. Peças do DDD <ul><li>Aggregates </li></ul><ul><ul><li>É uma Entidade composta por outros objetos (Entities e/ou Value Object) vista como uma unidade. </li></ul></ul><ul><ul><li>Essa Entidade é denominada de Raiz da Agregação. </li></ul></ul><ul><ul><li>A raiz de agregação garante a consistência das mudanças que são feitas dentro do agregado, impedindo que objetos externos realizem referências a seus membros. </li></ul></ul><ul><ul><ul><li>Nota-Fiscal é um agregado que contém Itens de Nota-Fiscal. </li></ul></ul></ul><ul><ul><ul><li>Cliente é um agregado que contém Endereços. </li></ul></ul></ul>
  20. 20. Peças do DDD Services
  21. 21. Peças do DDD <ul><li>Services </li></ul><ul><ul><li>Quando uma operação de negócio não pertence conceitualmente a um único objeto esta reside em um Service. </li></ul></ul><ul><ul><li>Services têm uma ligação estreita com os casos de uso modelados no sistema. </li></ul></ul><ul><ul><li>Services não têm estado. </li></ul></ul><ul><ul><ul><li>A classe SecretariaService contém um método matricularAluno que recebe Aluno e Turma como parâmetros. </li></ul></ul></ul>
  22. 22. Peças do DDD <ul><li>Services </li></ul><ul><ul><li>A Camada de Serviço define os limites de uma aplicação e seu conjunto de operações disponíveis a partir da perspectiva do cliente. </li></ul></ul><ul><ul><li>Ela encapsula a lógica de negócios, transações e coordenação das respostas na implementação de suas operações. </li></ul></ul>http://martinfowler.com/eaaCatalog/serviceLayer.html
  23. 23. Peças do DDD Factories
  24. 24. Peças do DDD <ul><li>Factories </li></ul><ul><ul><li>Métodos para criar objetos de domínio complexos devem delegar a objetos de fábrica especializados, de forma que as implementações possam ser facilmente mantidas. </li></ul></ul><ul><ul><li>São úteis na criação de Aggregates. </li></ul></ul>
  25. 25. Peças do DDD Repositories
  26. 26. Peças do DDD <ul><li>Repositories </li></ul><ul><ul><li>Um repositório é um mecanismo para encapsular o armazenamento, recuperação e comportamento de busca, que emula uma coleção de objetos. </li></ul></ul><ul><ul><li>Para cada tipo de objeto que precisa de acesso global, criar um Repositório que pode fornecer a ilusão de uma coleção em memória de todos os objetos desse tipo. </li></ul></ul>
  27. 27. Critérios de Sucesso <ul><li>Use DDD se </li></ul><ul><ul><li>O seu domínio não é trivial. </li></ul></ul><ul><ul><li>A equipe de desenvolvimento tem experiência e interesse em OOP/OOD. </li></ul></ul><ul><ul><li>Existe o acesso aos detentores das informações sobre o domínio. </li></ul></ul><ul><ul><li>O processo de desenvolvimento é iterativo. </li></ul></ul>
  28. 28. Critérios de Sucesso <ul><li>Domain-Driven Design é um tema muito amplo e contém muitas coisas que são difíceis ou impossíveis de incorporar no código de um aplicativo simples. </li></ul><ul><li>Coisas a se destacar </li></ul><ul><ul><li>Comunicação com o especialista de domínio. </li></ul></ul><ul><ul><li>Modelagem iterativa. </li></ul></ul><ul><ul><li>Descoberta de uma linguagem onipresente. </li></ul></ul>
  29. 29. Perguntas? e Obrigado!
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×