Your SlideShare is downloading. ×
0
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Programando com prazer com DDD
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Programando com prazer com DDD

4,698

Published on

Palestra apresentada no .Net Architects Day 2009 (dnad2009), em 27 de junho de 2009.

Palestra apresentada no .Net Architects Day 2009 (dnad2009), em 27 de junho de 2009.

Published in: Technology
0 Comments
12 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,698
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
0
Likes
12
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. DomainDriven Design
    Programando com prazer com DDD
    Giovanni Bassi
    MVP, MCSD, MCPD, CSM
  • 2. Giovanni Bassi
    Arquiteto de software
    Consultoria, gestão e mentoring
    Treinamento
    Microsoft MostValuable Professional em C# (MVP)
    InetaBoardMember
    C#, VB, J#, F#, etc...
    .Net de Beta a Beta
    Dezenas de artigos na .Net Magazine
    Editor técnico da .Net Magazine
    Palestrante
    Professor universitário
    Líder e fundador do .Net Architects
  • 3. Online @:
    Email: giggio@giggio.net
    Blog: http://unplugged.giggio.net
    Site: http://giovannibassi.com
    Twitter: @giovannibassi
  • 4. Objetivo
    Entender porque é mais divertido programar com DDD
  • 5. Agenda
  • 6.
  • 7. Visão de futuro
    ou...
    Porque o arquiteto deve ser preocupar com DDD
  • 8. Começando pelo começo: o que é DDD?
    “É uma abordagem para o desenvolvimento de software”
  • 9.
  • 10. Qual o foco do DDD?
  • 11. Focado no banco?
  • 12. Focado no domínio!
  • 13. Motivo 1:
    Estamos livres do banco de dados!
    (pelo menos até o final da iteração)
  • 14. Quais são as duas principais premissas do DDD?
    “Para a maioria dos projetos de software o foco principal deve ser no domínio e na lógica do domínio.”
    “Desenhos complexos de domínio devem ser baseados em um modelo.”
    Eric Evans
  • 15. Domínio?
    Esfera de conhecimento, influênciaouatividade.
    A áreaemque o usuárioutiliza o software.
  • 16. Motivo 2:
    Acabou a briga com o usuário!
  • 17. Modelo?
    Não...
  • 18. Não precisa ser impecavelmente realista
    O mundo segundo os chineses do século XVIII
  • 19. Usadopara resolver problemas
  • 20. Modelos são abstrações
    Isso quer dizer que o que não interessa fica de fora
    Se você conseguir equalizar isso, o modelo é perfeito
    Modelos devem refletir o código ou são irrelevantes
  • 21. Não há padrão para um modelo
    Ele pode ser assim...
    Ou assim...
  • 22. No modelo vão...
  • 23. Motivo 3:
    Use o que faz sentido pra você e para sua empresa!
  • 24. UbiquitousLanguage
    (está em toda parte)
    Vem dos business experts
    É refletida no modelo
    É refletida no código
    É falada pelo time
  • 25. Não
    Sim
    “Carga”
    “Conta corrente”
    “Serviço de tradução de itinerário”
    “Repositório de clientes”
    “Agendamento de horário”
    “Tabela”
    “Classe”
    “Thread”
    “Banco de dados”
    “Façade”
    “.Net 3.5”
  • 26. Ouça o Business Expert
    É ele quem conhece o problema,
    não você
  • 27. Motivo 4:
    Entenda o cliente!
    Entenda o resto do time.
    Entenda o código!
  • 28. Camadas
    Camadas devem fazer sentido (verifique suas responsabilidades)
    Se não separou não é camada
    Layers != Tiers
  • 29.
  • 30. “Esta camada é o coração de um software de negócios”
    Eric Evans
  • 31. Motivo 5:
    Livre-se do código macarrônico que mistura responsabilidades
  • 32. Entidades têm significado no domínio
    Entidades possuem identidade
    Cores:
    Azul
    Amarelo
    Verde
    Vermelho
    Objetos de valor não tem identidade para o negócio
    Objetos de valor são reconhecidos por seus atributos
    Objetos de valorfreqüentemente são imutáveis
  • 33. Agregaçõesreunem entidades e objetos de valor de maneira que faça sentido para o negócio
    Agregações definem fronteirasclaras
    Toda agregação tem uma raiz
  • 34.
  • 35. Algumas regras...
  • 36. (
    )
    Utilize:
    POCOs
    Plain Old CLR Objects
    Bom e velhoobjeto do CLR
  • 37. Motivo 6:
    Classes de negócio de verdade são muito mais fáceis de entender.
  • 38. Serviços resolvem problemas de negócio mas não são entidades nem objetos de valor
    Serviços não possuem estado de negócio
  • 39.
  • 40. Motivo 7:
    Resolvido o problema de “onde eu ponho esse método?”
  • 41. Factories criam objetos
    Levemente diferente das factories de padrões de projeto
    Objetos devem ser criados consistentes
    Será responsabilidade de um objeto se construir?
  • 42. Como criar qualquer destes objetos?
    Só com factories
  • 43. Motivo 8:
    Defina claramente onde seus objetos nascem.
    Fim dos problemas de referência circular em entidades.
  • 44. Repositórios fingem que têm todos os dados na memória
    Para o consumidor do repositório não faz muita diferença onde está o objeto
    Os Repositórios são os responsáveis por persistir e destruir os objetos
  • 45. publicvoidUpdateCustomer(Customercustomer)
    {
    using (var transaction = _session.BeginTransaction())
    {
    try
    {
    _session.Update(customer);
    transaction.Commit();
    }
    catch (NHibernate.HibernateException)
    {
    transaction.Rollback();
    throw;
    }
    }
    }
  • 46. Algumas regras...
  • 47. Mais regras...
  • 48. Esclarescendo...
    A idéia do repositório vem do repositorypattern (Fowler, PoEAA)
    DDD != Repositorypattern
  • 49. Motivo 9:
    Fim (quase) dos problemas de transação.
  • 50. Motivo 10:
    Um ponto único para obter e salvar as entidades
  • 51. Ciclo de vida:
    Factories criam
    Repositórios recuperam
    Repositórios alteram
    Repositórios destroem
  • 52. Motivo 11:
    Definições claras de come interagir com dados persistentes.
  • 53. Processo
  • 54. Funciona assim?
  • 55. Feedback é fundamental
    O tempo todo!
  • 56. Assim é bem mais fácil
  • 57. Aceite as mudanças...
    ... não brigue com elas
  • 58. Motivo 12:
    DDD + agilidade =
    (Paz * Produtividade) ^ satisfação do cliente
  • 59. DDD pode dar trabalho
    Então o foco são projetos com regras de negócio complexas
  • 60. Downloads

  • 61. Referências
    DomainLanguage (empresa do Evans)http://domainlanguage.com/
    Grupo do Yahoo sobre DDD (eminglês)http://groups.yahoo.com/group/domaindrivendesign
    Greg Young(MVP - eminglês)http://codebetter.com/blogs/gregyoung/
    Domain Driven Design.org (eminglês)http://www.domaindrivendesign.org/
    Jimmy Nilsson (eminglês)http://jimmynilsson.com
  • 62. Recomendação de leitura
  • 63. Demonstração
  • 64. Perguntas
    ?
  • 65. Não se esqueçam de preencher as fichas de avaliação
  • 66. Obrigado!
    Giovanni Bassi
    giggio@giggio.net
    http://giovannibassi.com

×