Domain-Driven Design

2.412 visualizações

Publicada em

Domain-Driven Design não é uma tecnologia ou metodologia. DDD é uma abordagem à modelação de software que providencia uma estrutura de práticas, padrões de programação e terminologias que ajudam à sua concepção.
Nesta sessão vamos conhecer o que é Domain-Driven Design, quando o usar e como implementar.

Publicada em: Tecnologia
1 comentário
2 gostaram
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
2.412
No SlideShare
0
A partir de incorporações
0
Número de incorporações
21
Ações
Compartilhamentos
0
Downloads
54
Comentários
1
Gostaram
2
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide
  • Domain Driven Design não é uma tecnologia ou metodologia. DDD é uma abordagem à modelação de software que providencia uma estrutura de práticas, padrões de programação e terminologias que ajudam à sua concepção.Nesta sessão vamos conhecer o que é Domain Driven Design, quando usar e como implementar. Para além disso serão apresentadas as principais Patterns acompanhadas com exemplos práticos de código.
  • Domain-Driven Design

    1. 1. http://netponto.org<br />16ª Reunião Presencial - 11/12/2010<br />DomainDriven DesignJoão Nicolau Oliveira<br />
    2. 2. Patrocinadores desta reunião<br />
    3. 3. João Oliveira<br /><ul><li> Licenciado na Faculdade de Ciências de Lisboa
    4. 4. 12 anos de experiência em TI
    5. 5. Adepto das metodologias ágeis
    6. 6. Release Manager na Solutions Factory</li></ul>C#<br />ASP.Net<br />WPF<br />WCF<br />DNN<br />jQuery<br />Delphi<br />Java<br />Zope<br />
    7. 7. Citação...<br />«Domain modeling is not a matter of making as “realistic” a model as possible. It is more like moviemaking, loosely representing reality to a particular purpose.»<br />EricEvans<br />
    8. 8. Agenda<br />O que é? Quando usar? Como?<br />UbiquousLanguage, BoundedContexts, Integração Contínua, ContextMap, PersistenceIgnorance<br />Command and Query Responsability Segregation<br />Patterns: ValueObject, Entity, Aggregate, Factory, Repository, UnitOfWork, Specification<br />
    9. 9. Também disponível em vídeo...<br />Assista!<br />http://www.vimeo.com/21488644<br />
    10. 10. O que é DDD?<br />Focalização no domínio<br />Um domínio é um âmbito. <br />É definido por um conjunto de características que descrevem uma família de problemas para os quais procuramos uma solução.<br />A análise do domínio identifica, captura e organiza informação para que seja reutilizável aquando da criação de novos sistemas.<br />
    11. 11. O que é o modelo do domínio?<br />
    12. 12. O que é o modelo do domínio?<br />É umarepresentação<br />
    13. 13. O que é DDD?<br />Focalizar no modelo<br />Elaborar uma representação abstracta do domínio que nos ajude a cumprir o propósito<br />Linguagem omnipresente<br />Os peritos do domínio e os programadores partilham uma linguagem comum<br />É Object-Oriented e combina bem com outras metodologias ágeis<br />TDD, BDD, … Reduz complexidade/facilita manutenção.<br />
    14. 14. Quando usar?<br />Projectos em que os desenhadores do modelo estão dispostos a “pôr as mãos na massa”<br />Colaboração efectiva entre peritos do domínio e os developers<br />Abertura para explorar e experimentar (os primeiros modelos não são satisfatórios)<br />Contexto explicito e bem definido<br />Apenas adequando para o núcleo do domínio<br />
    15. 15. Modelar - Como?<br />Processo de melhoria, ajuste, adaptação, aprendizagem, experimentação<br />Modelos Emergentes<br />Linguagem Omnipresente<br />
    16. 16. Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />
    17. 17. Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />
    18. 18. Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />
    19. 19. Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />
    20. 20. Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />“Alhos”<br />
    21. 21. Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />Tradução complexa<br />“Alhos”<br />
    22. 22. Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />Tradução complexa<br />“Bugalhos?”<br />“Alhos”<br />
    23. 23. Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />“Alhos”<br />
    24. 24. Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />MODELO<br />“Alhos”<br />
    25. 25. Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />MODELO<br />“Alhos”<br />
    26. 26. Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />MODELO<br />“Alhos”<br />
    27. 27. Linguagem Omnipresente<br />O nosso Modelo sustenta a nossa linguagem<br />Experts de Domínio<br />Programadores<br />Negócio<br />MODELO<br />Código<br />
    28. 28. Uma mesma linguagem para tudo<br />O código também deve reflectir a linguagem.<br />Exemplo:<br />Nomes => Classes<br />Verbos => métodos, serviços, …<br />Uma entidade empregadora coloca um anúncio de emprego:<br />Classes: Job, JobBoard<br />Acções: JobBoard.PostJob(Job)<br />
    29. 29. Bounded Context<br />Em projectos grandes temos vários modelos em jogo<br />É importante circunscrever o contexto ao qual o modelo se aplica<br />Explicitar fronteiras relativamente às diferentes equipas envolvidas, espaços físicos e repositórios de código e de dados<br />Preocupar-se apenas em garantir consistência dentro dessas fronteiras<br />
    30. 30. Continuous Integration<br />Quanto maior é a equipa, maior é a tendência para fragmentar o modelo:<br />Instituir um processo de integração contínua que faça merging do código e dos artefactos<br />Testes automatizados que detectem os erros ASAP<br />
    31. 31. Context Map<br />Os contextos de outros modelos podem ser vagos e estar em permanente mudança<br />Identificar todos os modelos em jogo (inclusivé subsistemas não object-oriented)<br />Dar nomes a esses contextos e fazer com que esses nomes se tornem parte da nossa linguagem ubíqua<br />Identificar os pontos de contacto e desenhar tradutores. <br />
    32. 32. Persistence Ignorance<br />
    33. 33. Ignorar a Persistência<br />Porquê?<br />Não queremos um modelo data-driven<br />Queremos liberdade na escolha do mecanismo de persistência dos nossos dados<br />Facilitar os nossos testes unitários e a abordagem TDD<br />Como?<br />Adoptar frameworks de acesso a dados “DDD-friendly”<br />Rejeitar ORMs estilo Active Objects<br />Usar ORMs pouco intrusivos (Ex: NHibernate, EF4)<br />Tirar partido dos Repositórios e Agregados<br />
    34. 34. Arquitectura DDD<br />UI<br />Application / Services<br />Domain<br />Data Access<br />Infrastructure<br />
    35. 35. Arquitectura DDD<br />Infrastructure<br />Funcionalidades genéricas que suportam as camadas superiores<br />Componentes de UI<br />Utilitários<br />Domain<br />Lógica e regras <br />Estado do negócio<br />É o núcleo/coração da aplicação<br />
    36. 36. Arquitectura DDD<br />Application<br />Orquestrador, Serviços, Tarefas de negócio<br />Interacção com outros sistemas<br />Esta camada deve ser fina<br />Não deve ter regras nem conhecimentos do negócio<br />Não guarda o estado do negócio<br />Pode guardar estado do progresso de uma tarefa<br />User Interface<br />Mostrar informação ao utilizador<br />Interpretar comandos<br />
    37. 37. Single ResponsabilityPrinciple<br />Uma classe deve ter apenas uma razão para sofrer mudanças.<br />Se tivermos 2 razões para mudar então deveremos separar em duas classes distintas.<br />Imprimir<br />Gerar PDF<br />Martin, Robert C. (2002). Agile Software Development, Principles, Patterns, andPractices<br />
    38. 38. Command and Query Responsibility Segregation<br />Performance<br />Simplicidade<br />Auditoria<br />BI<br />Agilidade<br />Commands<br />Queries<br />Diagrama de Mark Nijhof<br />
    39. 39. CQRS – Divisão de tarefas e rentabilidade<br />Equipa de baixo <br />custo produz código <br />sem exigências de qualidade.<br />Ideal para outsourcing.<br />Equipa pequena<br />altamentequalificada<br />Diagrama de Mark Nijhof<br />Equipa especializada<br />em UI<br />
    40. 40. Command and Query Responsibility Segregation<br />UI: Orientados à tarefa<br />Comandos: <br />Mudam o estado do domínio<br />Event Store: <br />Armazena literalmente os eventos<br />Query Store: Uma tabela por View (UI)<br />Exposta via SOA web services, WCF, WCF RIA<br />
    41. 41. Osblocos de código<br />Patterns<br />
    42. 42. Entidades<br />São objectos definidos pela sua identidade (identificadores únicos)<br />A sua forma ou conteúdo podem mudar, mas a identidade tem de ser preservada ao longo do ciclo de vida<br />Entidade<br />
    43. 43. Entidades<br />São ainda definidos por:<br />Responsabilidades<br />Estrutura<br />Comportamentos <br />A persistência nunca é responsabilidade da entidade (não usar entidades com métodos CRUD)<br />
    44. 44. Exemplo:<br />
    45. 45. ValueObjects<br />Imutáveis<br />Uma mesma instância pode ser usada em várias entidades<br />Se queremos um valor diferente então criamos uma nova instância<br />Exemplos: Moradas, Dinheiro, Códigos e até identificadores de entidades<br />
    46. 46. Exemplo:<br />
    47. 47. Agregados<br />Fronteira<br />Raíz do Agregado<br />
    48. 48. Agregados<br />É um agrupamento de objectos associados com os quais lidamos como se se tratassem de uma só unidade.<br />Dão consistência ao modelo<br />Definem relações de pertença<br />Definem fronteiras<br />Salvaguardam as invariantes (regras)<br />
    49. 49. Agregados<br />Qualquer mudança de estado tem de garantir sempre as invariantes do agregado.<br />Fronteira<br />Separa o interior do exterior<br />Raiz<br />É sempre uma Entidade<br />Responsável por garantir as invariantes<br />Pode ser livremente referenciada do exterior<br />
    50. 50. Agregados<br />Os membros<br />Podem ser Entidades e ValueObjects<br />Estas entidades apenas precisam de identidade “local”<br />Os objectos exteriores não devem ver estes membros fora do contexto da entidade raiz<br />
    51. 51. NestedAggregates<br />Quando o membro do agregado referencia a raiz de outro agregado<br />Evitar encadeamentos com demasiada profundidade<br />Exemplo de encadeamento:<br />Agregado Job Board (membros: Job)<br />Agregado Job (membros: Skill, Applicant)<br />Agregado Applicant (membros: ApplicantSkill)<br />
    52. 52. Exemplo:<br />Agregado Cargo<br />
    53. 53. Factory<br />Criar (e reconstruir) os objectos e agregados mais complexos<br />Encapsular a estrutura interna<br />Para objectos simples usar somente o construtor é suficiente<br />Deve ser uma operação atómica<br />Garantir todas as invariantes<br />
    54. 54. Factory<br />Diferentes tipos:<br />StandaloneFactory<br />FactoryMethod<br />Util em aggregates<br />Situações em que temos um objecto com grande relação de proximidade sobre o outro<br />AbstractFactory<br />Builder (para fluent interfaces)<br />
    55. 55. Factory<br />E as invariantes onde pertencem?<br />Pode-se delegar a validação ao próprio produto<br />Em agregados pode ser melhor ter as regras também na própria factory (porque tipicamente estão dispersas por vários objectos)<br />Regras do membro Identificador de uma entidade ou dum ValueObjecttêm existir na Factory<br />
    56. 56. Exemplo:<br />Utilizamos internalno método construtor de Car para obrigar o projecto cliente a utilizar sempre a Factory na instanciação da classe Car.<br />
    57. 57. Repositório e UnitOfWork<br />Repositório<br />Abstrai o acesso aos dados<br />Funciona como uma colecção de objectos em memória: Add, Remove, Get, Count<br />UnitOfWork<br />Registar as alterações ao estado dos objectos<br />Gerir as transacções: Commit, Rollback<br />ISession (NHibernate), DataContext (LinqToSQL)<br />
    58. 58. Citação...<br />«Leave transaction control to the client. (…) Transaction management will be simpler if the REPOSITORY keeps its hands off.»<br />Eric Evans<br />
    59. 59. Repositório<br />Um por cada Agregado<br />O agregado é sempre devolvido válido e completo<br />Abstrair a implementação<br />Facilitar os testes unitários<br />Maior liberdade para mudar a implementação<br />Facilitar optimizações de performance<br />Implementar mecanismos de caching<br />
    60. 60. Exemplo:<br />Implementação NHibernate<br />
    61. 61. Exemplo:<br />Implementação NHibernate<br />
    62. 62. Exemplo:<br />Implementação NHibernate<br />
    63. 63. RepositoryPerAggregate<br />GetById(int id)<br />GetByName(string name)<br />GetByCityAndState(City city, State state)<br />Add(Person person)<br />Count(), Sum()<br />Uma classeRepositórioporcadaAgregado<br />Dá-nosmaistrabalho do que o repositóriogenéricomaspermite-nosafinarmelhor as queries<br />
    64. 64. GenericRepository<br />Uma classe genérica para todos os Agregados<br />GetById<TId>(TIdid)<br />Query<T>(Expression<Func<T, bool>> query)<br />Insert<T>(T entity)<br />Delete<T>(T entity)<br />Ex: newRepository<Person, int>(…)<br />GetById (20)<br />Query (p => p.Idade > 20)<br />Tipo Entidade<br />Tipo Identificador<br />
    65. 65. IQueryable com Paginação<br />
    66. 66. IQueryable com Paginação<br />
    67. 67. IQueryable com Paginação<br />
    68. 68. IQueryable com Paginação<br />
    69. 69. Specification<br />Pode ser usada para:<br />Validar um objecto e verificar se cumpre certos requisitos ou se está preparado para um dado propósito<br />Seleccionar um objecto de uma colecção<br />Especificar as características de um objecto que vai ser instanciado<br />Podemos passar ao repositório com a especificação dos critérios de pesquisa traduzidos para a linguagem de acesso aos dados (SQL/Linq/NHibernate).<br />
    70. 70. Exemplo:<br />
    71. 71. Resumo<br />Entidade (Tem identidade)<br />ValueObject (Imutável)<br />Aggregate (Garante consistência)<br />Factory (Facilita início do ciclo de vida)<br />Repository(Faz gestão da persistência)<br />Specification(Definir requisitos/características)<br />
    72. 72. Dúvidas?<br />
    73. 73. Referências<br />Domain-Driven Design: Tackling Complexity in the Heart of Software Eric Evans<br />Applying Domain-Driven Design and Patterns <br />Jimmy Nilsson<br />
    74. 74. Referências<br />DomainDriven Design Community<br />http://domaindrivendesign.org/<br />Apresentação Domaindriven Design - CatapultSystems<br />http://www.slideshare.net/panesofglass/domain-driven-design<br />UnitOfWork - MartinFowler<br />http://martinfowler.com/eaaCatalog/unitOfWork.html<br />Repositories and IQueryable, the paging case<br />http://thinkbeforecoding.com/post/2009/01/19/Repositories-and-IQueryable-the-paging-case<br />CQRS: Recording of an online class – Greg Young<br />http://cqrsinfo.com/video/<br />
    75. 75. Referências<br />DDDSample (em Java)<br />http://dddsample.sourceforge.net/<br />ndddsample (C# DomainDriven Design sampleapplication)<br />http://code.google.com/p/ndddsample/<br />DDDSample .Net<br />http://dddsamplenet.codeplex.com/ <br />Rhino Commons, AyendeRahien<br />http://ayende.com/blog/archive/2007/06/08/rhino-commons-repositorylttgt-and-unit-of-work.aspx<br />
    76. 76. Patrocinadores desta reunião<br />
    77. 77. Obrigado!<br />João Oliveira<br />joao@nicolauoliveira.com<br />http://blog.nicolauoliveira.com<br />http://www.facebook.com/joaonoliveira<br />http://pt.linkedin.com/in/jnicolau<br />

    ×