1.
http://netponto.org<br />16ª Reunião Presencial - 11/12/2010<br />DomainDriven DesignJoão Nicolau Oliveira<br />

2.
Patrocinadores desta reunião<br />

3.
João Oliveira<br /><ul><li> Licenciado na Faculdade de Ciências de Lisboa

4.
12 anos de experiência em TI

5.
Adepto das metodologias ágeis

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.
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.
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.
Também disponível em vídeo...<br />Assista!<br />http://www.vimeo.com/21488644<br />

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.
O que é o modelo do domínio?<br />

12.
O que é o modelo do domínio?<br />É umarepresentação<br />

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.
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.
Modelar - Como?<br />Processo de melhoria, ajuste, adaptação, aprendizagem, experimentação<br />Modelos Emergentes<br />Linguagem Omnipresente<br />

16.
Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />

17.
Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />

18.
Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />

19.
Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />

20.
Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />“Alhos”<br />

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.
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.
Linguagem Omnipresente<br />Só nos entendemos se falarmos a mesma língua <br />Peritos de Domínio<br />Programadores<br />“Alhos”<br />

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.
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.
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.
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.
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.
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.
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.
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.
Persistence Ignorance<br />

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.
Arquitectura DDD<br />UI<br />Application / Services<br />Domain<br />Data Access<br />Infrastructure<br />

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.
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.
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.
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.
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.
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.
Osblocos de código<br />Patterns<br />

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.
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.
Exemplo:<br />

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.
Exemplo:<br />

47.
Agregados<br />Fronteira<br />Raíz do Agregado<br />

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.
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.
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.
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.
Exemplo:<br />Agregado Cargo<br />

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.
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.
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.
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.
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.
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.
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.
Exemplo:<br />Implementação NHibernate<br />

61.
Exemplo:<br />Implementação NHibernate<br />

62.
Exemplo:<br />Implementação NHibernate<br />

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.
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.
IQueryable com Paginação<br />

66.
IQueryable com Paginação<br />

67.
IQueryable com Paginação<br />

68.
IQueryable com Paginação<br />

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.
Exemplo:<br />

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.
Dúvidas?<br />

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.
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.
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.
Patrocinadores desta reunião<br />

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