O documento aborda a 16ª reunião do Domain Driven Design (DDD), destacando a importância do foco no domínio e a criação de modelos que reflitam uma linguagem comum entre especialistas e desenvolvedores. São discutidos conceitos-chave como integração contínua, mapeamento de contexto, segregação de responsabilidade de comando e consulta, e padrões de design, incluindo entidades, agregados e repositórios. O objetivo é facilitar a colaboração e a adaptação em projetos de software complexos, garantindo consistência e clareza na comunicação.

1. http://netponto.org16ª Reunião Presencial - 11/12/2010DomainDriven DesignJoão Nicolau Oliveira

2. Patrocinadores desta reunião

3. João Oliveira 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 FactoryC#ASP.NetWPFWCFDNNjQueryDelphiJavaZope

7. Citação...«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.»EricEvans

8. AgendaO que é? Quando usar? Como?UbiquousLanguage, BoundedContexts, Integração Contínua, ContextMap, PersistenceIgnoranceCommand and Query Responsability SegregationPatterns: ValueObject, Entity, Aggregate, Factory, Repository, UnitOfWork, Specification

9. Também disponível em vídeo...Assista!http://www.vimeo.com/21488644

10. O que é DDD?Focalização no domínioUm domínio é um âmbito. É definido por um conjunto de características que descrevem uma família de problemas para os quais procuramos uma solução.A análise do domínio identifica, captura e organiza informação para que seja reutilizável aquando da criação de novos sistemas.

11. O que é o modelo do domínio?

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

13. O que é DDD?Focalizar no modeloElaborar uma representação abstracta do domínio que nos ajude a cumprir o propósitoLinguagem omnipresenteOs peritos do domínio e os programadores partilham uma linguagem comumÉ Object-Oriented e combina bem com outras metodologias ágeisTDD, BDD, … Reduz complexidade/facilita manutenção.

14. Quando usar?Projectos em que os desenhadores do modelo estão dispostos a “pôr as mãos na massa”Colaboração efectiva entre peritos do domínio e os developersAbertura para explorar e experimentar (os primeiros modelos não são satisfatórios)Contexto explicito e bem definidoApenas adequando para o núcleo do domínio

15. Modelar - Como?Processo de melhoria, ajuste, adaptação, aprendizagem, experimentaçãoModelos EmergentesLinguagem Omnipresente

16. Linguagem OmnipresenteSó nos entendemos se falarmos a mesma língua Peritos de Domínio

17. Linguagem OmnipresenteSó nos entendemos se falarmos a mesma língua Peritos de DomínioProgramadores

18. Linguagem OmnipresenteSó nos entendemos se falarmos a mesma língua Peritos de DomínioProgramadores

19. Linguagem OmnipresenteSó nos entendemos se falarmos a mesma língua Peritos de DomínioProgramadores

20. Linguagem OmnipresenteSó nos entendemos se falarmos a mesma língua Peritos de DomínioProgramadores“Alhos”

21. Linguagem OmnipresenteSó nos entendemos se falarmos a mesma língua Peritos de DomínioProgramadoresTradução complexa“Alhos”

22. Linguagem OmnipresenteSó nos entendemos se falarmos a mesma língua Peritos de DomínioProgramadoresTradução complexa“Bugalhos?”“Alhos”

23. Linguagem OmnipresenteSó nos entendemos se falarmos a mesma língua Peritos de DomínioProgramadores“Alhos”

24. Linguagem OmnipresenteSó nos entendemos se falarmos a mesma língua Peritos de DomínioProgramadoresMODELO“Alhos”

25. Linguagem OmnipresenteSó nos entendemos se falarmos a mesma língua Peritos de DomínioProgramadoresMODELO“Alhos”

26. Linguagem OmnipresenteSó nos entendemos se falarmos a mesma língua Peritos de DomínioProgramadoresMODELO“Alhos”

27. Linguagem OmnipresenteO nosso Modelo sustenta a nossa linguagemExperts de DomínioProgramadoresNegócioMODELOCódigo

28. Uma mesma linguagem para tudoO código também deve reflectir a linguagem.Exemplo:Nomes => ClassesVerbos => métodos, serviços, …Uma entidade empregadora coloca um anúncio de emprego:Classes: Job, JobBoardAcções: JobBoard.PostJob(Job)

29. Bounded ContextEm projectos grandes temos vários modelos em jogoÉ importante circunscrever o contexto ao qual o modelo se aplicaExplicitar fronteiras relativamente às diferentes equipas envolvidas, espaços físicos e repositórios de código e de dadosPreocupar-se apenas em garantir consistência dentro dessas fronteiras

30. Continuous IntegrationQuanto maior é a equipa, maior é a tendência para fragmentar o modelo:Instituir um processo de integração contínua que faça merging do código e dos artefactosTestes automatizados que detectem os erros ASAP

31. Context MapOs contextos de outros modelos podem ser vagos e estar em permanente mudançaIdentificar todos os modelos em jogo (inclusivé subsistemas não object-oriented)Dar nomes a esses contextos e fazer com que esses nomes se tornem parte da nossa linguagem ubíquaIdentificar os pontos de contacto e desenhar tradutores.

32. Persistence Ignorance

33. Ignorar a PersistênciaPorquê?Não queremos um modelo data-drivenQueremos liberdade na escolha do mecanismo de persistência dos nossos dadosFacilitar os nossos testes unitários e a abordagem TDDComo?Adoptar frameworks de acesso a dados “DDD-friendly”Rejeitar ORMs estilo Active ObjectsUsar ORMs pouco intrusivos (Ex: NHibernate, EF4)Tirar partido dos Repositórios e Agregados

34. Arquitectura DDDUIApplication / ServicesDomainData AccessInfrastructure

35. Arquitectura DDDInfrastructureFuncionalidades genéricas que suportam as camadas superioresComponentes de UIUtilitáriosDomainLógica e regras Estado do negócioÉ o núcleo/coração da aplicação

36. Arquitectura DDDApplicationOrquestrador, Serviços, Tarefas de negócioInteracção com outros sistemasEsta camada deve ser finaNão deve ter regras nem conhecimentos do negócioNão guarda o estado do negócioPode guardar estado do progresso de uma tarefaUser InterfaceMostrar informação ao utilizadorInterpretar comandos

37. Single ResponsabilityPrincipleUma classe deve ter apenas uma razão para sofrer mudanças.Se tivermos 2 razões para mudar então deveremos separar em duas classes distintas.ImprimirGerar PDFMartin, Robert C. (2002). Agile Software Development, Principles, Patterns, andPractices

38. Command and Query Responsibility SegregationPerformanceSimplicidadeAuditoriaBIAgilidadeCommandsQueriesDiagrama de Mark Nijhof

39. CQRS – Divisão de tarefas e rentabilidadeEquipa de baixo custo produz código sem exigências de qualidade.Ideal para outsourcing.Equipa pequenaaltamentequalificadaDiagrama de Mark NijhofEquipa especializadaem UI

40. Command and Query Responsibility SegregationUI: Orientados à tarefaComandos: Mudam o estado do domínioEvent Store: Armazena literalmente os eventosQuery Store: Uma tabela por View (UI)Exposta via SOA web services, WCF, WCF RIA

41. Osblocos de códigoPatterns

42. EntidadesSão objectos definidos pela sua identidade (identificadores únicos)A sua forma ou conteúdo podem mudar, mas a identidade tem de ser preservada ao longo do ciclo de vidaEntidade

43. EntidadesSão ainda definidos por:ResponsabilidadesEstruturaComportamentos A persistência nunca é responsabilidade da entidade (não usar entidades com métodos CRUD)

44. Exemplo:

45. ValueObjectsImutáveisUma mesma instância pode ser usada em várias entidadesSe queremos um valor diferente então criamos uma nova instânciaExemplos: Moradas, Dinheiro, Códigos e até identificadores de entidades

46. Exemplo:

47. AgregadosFronteiraRaíz do Agregado

48. AgregadosÉ um agrupamento de objectos associados com os quais lidamos como se se tratassem de uma só unidade.Dão consistência ao modeloDefinem relações de pertençaDefinem fronteirasSalvaguardam as invariantes (regras)

49. AgregadosQualquer mudança de estado tem de garantir sempre as invariantes do agregado.FronteiraSepara o interior do exteriorRaizÉ sempre uma EntidadeResponsável por garantir as invariantesPode ser livremente referenciada do exterior

50. AgregadosOs membrosPodem ser Entidades e ValueObjectsEstas entidades apenas precisam de identidade “local”Os objectos exteriores não devem ver estes membros fora do contexto da entidade raiz

51. NestedAggregatesQuando o membro do agregado referencia a raiz de outro agregadoEvitar encadeamentos com demasiada profundidadeExemplo de encadeamento:Agregado Job Board (membros: Job)Agregado Job (membros: Skill, Applicant)Agregado Applicant (membros: ApplicantSkill)

52. Exemplo:Agregado Cargo

53. FactoryCriar (e reconstruir) os objectos e agregados mais complexosEncapsular a estrutura internaPara objectos simples usar somente o construtor é suficienteDeve ser uma operação atómicaGarantir todas as invariantes

54. FactoryDiferentes tipos:StandaloneFactoryFactoryMethodUtil em aggregatesSituações em que temos um objecto com grande relação de proximidade sobre o outroAbstractFactoryBuilder (para fluent interfaces)

55. FactoryE as invariantes onde pertencem?Pode-se delegar a validação ao próprio produtoEm agregados pode ser melhor ter as regras também na própria factory (porque tipicamente estão dispersas por vários objectos)Regras do membro Identificador de uma entidade ou dum ValueObjecttêm existir na Factory

56. Exemplo:Utilizamos internalno método construtor de Car para obrigar o projecto cliente a utilizar sempre a Factory na instanciação da classe Car.

57. Repositório e UnitOfWorkRepositórioAbstrai o acesso aos dadosFunciona como uma colecção de objectos em memória: Add, Remove, Get, CountUnitOfWorkRegistar as alterações ao estado dos objectosGerir as transacções: Commit, RollbackISession (NHibernate), DataContext (LinqToSQL)

58. Citação...«Leave transaction control to the client. (…) Transaction management will be simpler if the REPOSITORY keeps its hands off.»Eric Evans

59. RepositórioUm por cada AgregadoO agregado é sempre devolvido válido e completoAbstrair a implementaçãoFacilitar os testes unitáriosMaior liberdade para mudar a implementaçãoFacilitar optimizações de performanceImplementar mecanismos de caching

60. Exemplo:Implementação NHibernate

61. Exemplo:Implementação NHibernate

62. Exemplo:Implementação NHibernate

63. RepositoryPerAggregateGetById(int id)GetByName(string name)GetByCityAndState(City city, State state)Add(Person person)Count(), Sum()Uma classeRepositórioporcadaAgregadoDá-nosmaistrabalho do que o repositóriogenéricomaspermite-nosafinarmelhor as queries

64. GenericRepositoryUma classe genérica para todos os AgregadosGetById<TId>(TIdid)Query<T>(Expression<Func<T, bool>> query)Insert<T>(T entity)Delete<T>(T entity)Ex: newRepository<Person, int>(…)GetById (20)Query (p => p.Idade > 20)Tipo EntidadeTipo Identificador

65. IQueryable com Paginação

66. IQueryable com Paginação

67. IQueryable com Paginação

68. IQueryable com Paginação

69. SpecificationPode ser usada para:Validar um objecto e verificar se cumpre certos requisitos ou se está preparado para um dado propósitoSeleccionar um objecto de uma colecçãoEspecificar as características de um objecto que vai ser instanciadoPodemos passar ao repositório com a especificação dos critérios de pesquisa traduzidos para a linguagem de acesso aos dados (SQL/Linq/NHibernate).

70. Exemplo:

71. ResumoEntidade (Tem identidade)ValueObject (Imutável)Aggregate (Garante consistência)Factory (Facilita início do ciclo de vida)Repository(Faz gestão da persistência)Specification(Definir requisitos/características)

72. Dúvidas?

73. ReferênciasDomain-Driven Design: Tackling Complexity in the Heart of Software Eric EvansApplying Domain-Driven Design and Patterns Jimmy Nilsson

74. ReferênciasDomainDriven Design Communityhttp://domaindrivendesign.org/Apresentação Domaindriven Design - CatapultSystemshttp://www.slideshare.net/panesofglass/domain-driven-designUnitOfWork - MartinFowlerhttp://martinfowler.com/eaaCatalog/unitOfWork.htmlRepositories and IQueryable, the paging casehttp://thinkbeforecoding.com/post/2009/01/19/Repositories-and-IQueryable-the-paging-caseCQRS: Recording of an online class – Greg Younghttp://cqrsinfo.com/video/