Domain-Driven Design

1.590 visualizações

Publicada em

1 comentário
7 gostaram
Estatísticas
Notas
  • Jogando.net/MU *21*

    Boa tarde amigos,

    Venham conhecer nossos Servidores de Mu
    Online Season 6 http://www.jogando.net/mu/
    >>muitos kits novos;
    >> Nossos GMs online em todos os servers
    Fazem eventos todos os dias:
    Fazemos sua Diversão com qualidade,há mais de 5 anos
    Servers ON 24 horas por dia
    Vários Server esperando por você.Venha se divertir de verdade.
    >>>CURTA nossa Fan page no Facebook e concorra a prêmios.
    SORTEIO de 2 pacotes de 100 JCASHs mais 15 dias VIP Premium
    >>>Conheçam também Animes Cloud -> http://www.animescloud.com, mais de 20.000 videos online,feito exclusivo para sua diversão.
    Site http://www.jogando.net/mu/ Benvindos ao nosso servidor.
    Wartemix Divulgadora Oficial !
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
Sem downloads
Visualizações
Visualizações totais
1.590
No SlideShare
0
A partir de incorporações
0
Número de incorporações
153
Ações
Compartilhamentos
0
Downloads
0
Comentários
1
Gostaram
7
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Domain-Driven Design

  1. 1. Rodrigo Branas - @rodrigobranas – http://www.agilecode.com.br Domain-Driven Design
  2. 2. http://www.slideshare.net/rodrigobranas
  3. 3. @rodrigobranas rodrigo.branas@gmail.com http://www.agilecode.com.brFormação AcadêmicaCiências da Computação – UFSCGerenciamento de Projetos - FGVCertificaçõesSCJA, SCJP, SCJD, SCWCD, SCBCD, PMP, MCP e CSM
  4. 4. Rodrigo Branas – rodrigo.branas@gmail.com10 anos de experiência na plataforma Java1000 horas em sala de aulaMais de 50 palestras em eventosLíder da área de desenvolvimento na GenneraAutor da revista Java MagazinePalestranteInstrutor da Academia Java e Agile da GlobalcodeCriador dos treinamentos de Clean Code, Selenium eMaven da Agile CodeTrabalhou com as empresas:EDS, HP, GM, Citibank, OnCast, Globalcode, V.Office, Dígitro, Softplan, Unimed, Suntech, Vale do Rio
  5. 5. Software é uma abstração da realidade
  6. 6. A realidade é formada porconhecimento tácito
  7. 7. Conhecimento Tácito“Conhecimento formado no dia-a-dia das pessoas, intangível e difícil de ser descrito através de palavras.” Exemplos: Dirigir, Tocar um instrumento musical, Praticar um esporte.
  8. 8. Esse conhecimento édenominado de Domain
  9. 9. Domain“Campo de ação, conhecimento e influência.”É completamente abstrato e intangível inicialmente
  10. 10. Cuidado: Domain não é um diagrama ou algo do tipo
  11. 11. Domain Model
  12. 12. Estruturar, organizar e esclarecer o Domain
  13. 13. Sua principal importância está no feedback
  14. 14. Cuidado: Também não é um diagrama ou algo do tipo
  15. 15. Domain Model é a idéia que o diagrama tenta transmitir
  16. 16. O conhecimento está na cabeça dos Domain Experts
  17. 17. Domain Experts
  18. 18. Quem é o Domain Expert?
  19. 19. Alguém que conhece profundamente os detalhes de um Domain
  20. 20. O que diferencia um DomainExpert de um Product Owner?
  21. 21. Distância entre Domain Experts e desenvolvedores
  22. 22. Cuidado: Problemas decomunicação pela frente!
  23. 23. Aprendizagem do Domain
  24. 24. Você já teve a sensação de estar perdido em um projeto?
  25. 25. Como começar?
  26. 26. Não entre em detalhes, crie umadefinição superficial e abrangente do escopo do projeto e a utilize comobase para continuar evoluindo rumo a um entendimento completo e profundo.
  27. 27. Problemas de falta de contexto
  28. 28. Montando o quebra-cabeça com apenas um pedaço do mapa
  29. 29. Cuidado: Tentar entender apenasuma pequena parte do todo, em detalhes, pode ser complicado
  30. 30. Nunca vá a frente sem entendertudo que é discutido e conversado
  31. 31. Linguagem e Comunicação
  32. 32. Convivemos em tribos diferentes
  33. 33. Por conta disso, utilizamos de linguagens muito diferentes
  34. 34. Domain Experts tem dificuldade em entender de tecnologia
  35. 35. Cuidado: Não imponha umalinguagem focada na tecnologia
  36. 36. É muito importante criar e estabeleceruma linguagem oficial, entendida por Domain Experts e desenvolvedores
  37. 37. Ubiquitous Language
  38. 38. A linguagem é o conhecimento de forma dinâmica
  39. 39. Deve ser utilizada todo o tempo no decorrer do projeto
  40. 40. Debate: Utilizar inglês ouportuguês dentro do código?
  41. 41. Diagramas
  42. 42. Existe algum diagrama específicopara trabalhar com Domain-Driven Design?
  43. 43. Facilitando a comunicação e melhorando o aprendizado
  44. 44. Breakthrough
  45. 45. Model-Driven Design
  46. 46. O que é o Design de um software?
  47. 47. Cuidado: Design não é relacionadoas cores utilizadas na interface gráfica
  48. 48. Qual é a diferença entre o Designe a Arquitetura de um software?
  49. 49. O código deve refletir a linguagem
  50. 50. Isolando e fortalecendo o Domain Model
  51. 51. Smart UI
  52. 52. Produtividade parece ser alta no início
  53. 53. Desvantagens:1. Não é reutilizável2. Pouco flexível3. Dificilmente integrável4. Ambiente torna-se caótico rapidamente
  54. 54. Arquiteturaem camadas
  55. 55. User Interface
  56. 56. Camada responsável por abrigar ações e comandoscapazes de interpretar ações realizadas por usuários. (Inclusive outro sistema)
  57. 57. Application
  58. 58. Camada responsável por suportar diversos tipos de UI,realizar traduções e conversõesde dados e ainda exposição das operações de negócios para quem tiver interesse na aplicação
  59. 59. Domain
  60. 60. Camada onde os artefatos expressam o domínio. Essacamada é onde fica o coração do software. Deve refletir o Domain Model.
  61. 61. Infrastructure
  62. 62. Suporte técnico para as outras camadas. Responsável pela persistência, segurança, e auditoria.
  63. 63. Domain Objects
  64. 64. Entity
  65. 65. Cuidado: O conceitos de ORM sobre entidades é diferente
  66. 66. Possuem uma identidade dentro do domínio
  67. 67. Value Object
  68. 68. Não tem identidade
  69. 69. Exemplo: Cor RGBPublic class RGBColor { public int red; public int green; public int blue; public RGBColor(int red, int green, int blue) { this.red = red; this.green = green; this.blue = blue; }}
  70. 70. Representam valores imutáveis
  71. 71. Service
  72. 72. Services são objetos quegerenciam a execução de fluxos de negócio orquestrando a interação entre os objetos do domínio
  73. 73. Cuidado: Modelo Anêmico
  74. 74. Services em geral não possuem estado
  75. 75. Entendendo SOAService-Oriented Architecture
  76. 76. Isolando conceitos
  77. 77. Aggregates
  78. 78. Grupo lógico de objetos
  79. 79. Uma entity deve ser a raiz e único ponto de acesso
  80. 80. Entendendo o ciclo de vida dos Domain Objects
  81. 81. Factory
  82. 82. Facilitar e assumi aresponsabilidade pela criação de objetos, ocultando a complexidade.
  83. 83. Tipos de Factory
  84. 84. Simple Factory
  85. 85. Factory Method
  86. 86. Abstract Factory
  87. 87. Repository
  88. 88. Guardando e recuperando Domain Objects
  89. 89. Faz uso da camada de infraestrutura
  90. 90. Repository não é parecido com o padrão DAO?
  91. 91. Supple Design
  92. 92. Aumentando a expressão do Domain no código
  93. 93. Intention revealing interfaces
  94. 94. Interface Implementação
  95. 95. Side-effect free functions
  96. 96. Métodos que realizamconsultas (Queries) e possuemretorno, no entanto modificam o estado de objetos (Comandos)
  97. 97. Assertions
  98. 98. Contorno conceitual
  99. 99. Qual é a precisão da abstração?
  100. 100. Classes independentes
  101. 101. Voltando as raízes daOrientação a Objetos
  102. 102. Coesão
  103. 103. A importância daresponsabilidade única
  104. 104. Acoplamento
  105. 105. Lei de Demeter
  106. 106. Strategic Design
  107. 107. Modularizando sistemas grandes e complexos
  108. 108. Trabalhar com equipes externas
  109. 109. Bounded Context
  110. 110. Domain Models diferentes
  111. 111. Redução do acoplamento
  112. 112. Como fica o reuso?
  113. 113. Continuous Integration
  114. 114. Integrando diferentes contextos
  115. 115. Cuidado: Contextos individuaispodem deixar de funcionar em conjunto
  116. 116. Context Map
  117. 117. Visualizar o todo
  118. 118. Descrição de cada ponto decontato entre os modelos de cada contexto
  119. 119. Exercício: Criar o Context Map para o Domain Model.
  120. 120. Shared Kernel
  121. 121. Quando dois times alteram uma mesma base de código comum. É importante que esse pedaço de código esteja bem definido e que possua muitos testes automatizados, que devem ser rodados por qualquer um dos grupos que desejar fazer alguma alteração.
  122. 122. Cuidado: Comunicar a outraequipe sempre que for realizar qualquer alteração
  123. 123. Customer/Suplier Teams
  124. 124. Contextos tecnologicamentediferentes, tornando inviável a utilização do Shared Kernel
  125. 125. Uma equipe fará o papel de consumidora e a outra de fornecedora
  126. 126. Conformist
  127. 127. A outra equipe não estáinteressada em colaborar
  128. 128. Como resultado temos umShared Kernel sem colaboração
  129. 129. Separate Ways
  130. 130. O trabalho para integrar é tãogrande que vale mais a pena seguir por um caminho separado
  131. 131. Open Host Service
  132. 132. API consumida como serviçoexterno através de protocolos de rede
  133. 133. Published API
  134. 134. Documentando e orientando a utilização da API
  135. 135. Anticorruption Layer
  136. 136. Quando temos um sistema legado, com código muito bagunçado e uma interface complexa, e estamos escrevendo um sistema novo com o código razoavelmente bem feito, criamos uma camada entre esses dois sistemas .O nosso sistema novo e bem feito falará com essa camada, que possui uma interface bem feita. E acamada anti-corrupção é responsável por traduzir e adaptar as chamadas para o sistema legado, usando uma fachada interna.
  137. 137. “Any fool can write code that a computer can understand.Good programmers write codethat humans can understand.” Martin Fowler

×