Domain-Driven Design - Uma Abordagem Introdutória

  • 796 views
Uploaded on

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

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

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
796
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
24
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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