O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.
http://netponto.org<br />16ª Reunião Presencial - 11/12/2010<br />DomainDriven DesignJoão Nicolau Oliveira<br />
Patrocinadores desta reunião<br />
João Oliveira<br /><ul><li> Licenciado na Faculdade de Ciências de Lisboa
 12 anos de experiência em TI
 Adepto das metodologias ágeis
 Release Manager na Solutions Factory</li></ul>C#<br />ASP.Net<br />WPF<br />WCF<br />DNN<br />jQuery<br />Delphi<br />Jav...
Citação...<br />«Domain modeling is not a matter of making as “realistic” a model as possible. It is more like moviemaking...
Agenda<br />O que é? Quando usar? Como?<br />UbiquousLanguage, BoundedContexts, Integração Contínua, ContextMap, Persisten...
Também disponível em vídeo...<br />Assista!<br />http://www.vimeo.com/21488644<br />
O que é DDD?<br />Focalização no domínio<br />Um domínio é um âmbito. <br />É definido por um conjunto de características ...
O que é o modelo do domínio?<br />
O que é o modelo do domínio?<br />É umarepresentação<br />
O que é DDD?<br />Focalizar no modelo<br />Elaborar uma representação abstracta do domínio que nos ajude a cumprir o propó...
Quando usar?<br />Projectos em que os desenhadores do modelo estão dispostos a “pôr as mãos na massa”<br />Colaboração efe...
Modelar - Como?<br />Processo de melhoria, ajuste, adaptação, aprendizagem, experimentação<br />Modelos Emergentes<br />Li...
Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />
Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />
Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />
Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />
Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />...
Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />...
Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />...
Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />...
Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />...
Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />...
Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />...
Linguagem Omnipresente<br />O nosso Modelo sustenta a nossa linguagem<br />Experts de Domínio<br />Programadores<br />Negó...
Uma mesma linguagem para tudo<br />O código também deve reflectir a linguagem.<br />Exemplo:<br />Nomes => Classes<br />Ve...
Bounded Context<br />Em projectos grandes temos vários modelos em jogo<br />É importante circunscrever o contexto ao qual ...
Continuous Integration<br />Quanto maior é a equipa, maior é a tendência para fragmentar o modelo:<br />Instituir um proce...
Context Map<br />Os contextos de outros modelos podem ser vagos e estar em permanente mudança<br />Identificar todos os mo...
Persistence Ignorance<br />
Ignorar a Persistência<br />Porquê?<br />Não queremos um modelo data-driven<br />Queremos liberdade na escolha do mecanism...
Arquitectura DDD<br />UI<br />Application / Services<br />Domain<br />Data Access<br />Infrastructure<br />
Arquitectura DDD<br />Infrastructure<br />Funcionalidades genéricas que suportam as camadas superiores<br />Componentes de...
Arquitectura DDD<br />Application<br />Orquestrador, Serviços, Tarefas de negócio<br />Interacção com outros sistemas<br /...
Single ResponsabilityPrinciple<br />Uma classe deve ter apenas uma razão para sofrer mudanças.<br />Se tivermos 2 razões p...
Command and Query Responsibility Segregation<br />Performance<br />Simplicidade<br />Auditoria<br />BI<br />Agilidade<br /...
CQRS – Divisão de tarefas e rentabilidade<br />Equipa de baixo <br />custo produz código <br />sem exigências de qualidade...
Command and Query Responsibility Segregation<br />UI: Orientados à tarefa<br />Comandos: <br />Mudam o estado do domínio<b...
Osblocos de código<br />Patterns<br />
Entidades<br />São objectos definidos pela sua identidade (identificadores únicos)<br />A sua forma ou conteúdo podem muda...
Entidades<br />São ainda definidos por:<br />Responsabilidades<br />Estrutura<br />Comportamentos <br />A persistência nun...
Exemplo:<br />
ValueObjects<br />Imutáveis<br />Uma mesma instância pode ser usada em várias entidades<br />Se queremos um valor diferent...
Exemplo:<br />
Agregados<br />Fronteira<br />Raíz do Agregado<br />
Agregados<br />É um agrupamento de objectos associados com os quais lidamos como se se tratassem de uma só unidade.<br />D...
Agregados<br />Qualquer mudança de estado tem de garantir sempre as invariantes do agregado.<br />Fronteira<br />Separa o ...
Agregados<br />Os membros<br />Podem ser Entidades e ValueObjects<br />Estas entidades apenas precisam de identidade “loca...
NestedAggregates<br />Quando o membro do agregado referencia a raiz de outro agregado<br />Evitar encadeamentos com demasi...
Exemplo:<br />Agregado Cargo<br />
Factory<br />Criar (e reconstruir) os objectos e agregados mais complexos<br />Encapsular a estrutura interna<br />Para ob...
Factory<br />Diferentes tipos:<br />StandaloneFactory<br />FactoryMethod<br />Util em aggregates<br />Situações em que tem...
Factory<br />E as invariantes onde pertencem?<br />Pode-se delegar a validação ao próprio produto<br />Em agregados pode s...
Exemplo:<br />Utilizamos internalno método construtor de Car para obrigar o projecto cliente a utilizar sempre a Factory  ...
Repositório e UnitOfWork<br />Repositório<br />Abstrai o acesso aos dados<br />Funciona como uma colecção de objectos em m...
Citação...<br />«Leave transaction control to the client. (…) Transaction management will be simpler if the REPOSITORY kee...
Repositório<br />Um por cada Agregado<br />O agregado é sempre devolvido válido e completo<br />Abstrair a implementação<b...
Exemplo:<br />Implementação NHibernate<br />
Exemplo:<br />Implementação NHibernate<br />
Exemplo:<br />Implementação NHibernate<br />
RepositoryPerAggregate<br />GetById(int id)<br />GetByName(string name)<br />GetByCityAndState(City city, State state)<br ...
GenericRepository<br />Uma classe genérica para todos os Agregados<br />GetById<TId>(TIdid)<br />Query<T>(Expression<Func<...
IQueryable com Paginação<br />
IQueryable com Paginação<br />
IQueryable com Paginação<br />
IQueryable com Paginação<br />
Specification<br />Pode ser usada para:<br />Validar um objecto e verificar se cumpre certos requisitos ou se está prepara...
Exemplo:<br />
Resumo<br />Entidade (Tem identidade)<br />ValueObject (Imutável)<br />Aggregate (Garante consistência)<br />Factory (Faci...
Dúvidas?<br />
Referências<br />Domain-Driven Design: Tackling Complexity in the Heart of Software Eric Evans<br />Applying Domain-Driven...
Referências<br />DomainDriven Design Community<br />http://domaindrivendesign.org/<br />Apresentação Domaindriven Design -...
Próximos SlideShares
Carregando em…5
×

Domain-Driven Design

2.452 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

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 />

×