O documento discute os princípios do Domain-Driven Design (DDD), abordando como entender o domínio de um software, desenhar um modelo efetivo e implementar uma arquitetura orientada a domínio. O DDD foca em regras de negócio complexas, baixo acoplamento e independência de tecnologia através de boas práticas como modelagem do domínio, linguagem ubíqua, entidades, objetos de valor, agregados, serviços, repositórios e fábricas.

1. Software complexo? Entenda o seu domínio e desenhe um modelo Abordagem sobre o Desenho Dirigido ao Domínio (Domain-Driven Design ou DDD)

2. Quem sou eu? Thiago Holder Software Developer Estudante de Sistemas da Informação

3. Objetivo Entender a importância de se pensar em um domínio, a linguagem que você usa para falar sobre ele.

4. “O desafio da complexidade”

5. O que é DDD? “ É uma maneira de pensar e um conjunto de prioridades, voltado para a aceleração de projetos de softwares com domínios complicados ” Eric Evans.

6. O que o DDD apresenta? Boas práticas Padrões Experiência

7. Qual o foco do DDD? Regras de negócio complexos Isolamento entre domínios Reutilização Domínio Baixo acoplamento Independente de tecnologia

8. Padrões do DDD Contexto Resumo do problema Por esta Razão Discussão da solução Discussão do problema Conseqüências, Implementações e exemplo Resumo do problema Contexto resultante

9. Partes do DDD

10. O que é Domínio? Esfera de conhecimento, influência ou atividade. A área em que o usuário utiliza o software.

11. Modelo? Não Não

12. Excesso de informação atrapalha

13. Modelo

14. Os ingredientes de uma modelagem eficaz

15. Ligando o modelo e a implementação Consulta Paciente * * Protótipo rudimentar

16. Cultivando uma linguagem baseada no modelo Consulta A Agenda() Paciente Consulta B Agenda() Agenda() Consulta C Frases consistentes com a estrutura do modelo e ser entendido sem ambigüidade e sem tradução

17. Desenvolvendo um modelo rico em conhecimento Consulta Agendamento Secretária Paciente Atendido Médico Verifica Disponibilidade Agenda Captar vários tipos de conhecimento

18. Destilando o modelo Agenda Médica Secretária Verifica Paciente Atendido Agenda a consulta Médico Consulta Realiza Novo modelo que distingue o conceito essencial

19. Colhendo idéia

20. Linguagem Ubíqua “ Quer dizer que estar em todos os lugares, ou seja onipresente”.

21. ModelDriven Design (MDD) Modelo Domínio Guia Design Refatoração Evolui Software perdido, dependente de tecnologia. Desenvolvedores perdidos.

22. Distância no o contexto do domínio Analista de Negócio Analista de Sistemas Arquiteto Desenvolvedor

23. Tijolos de construção

24. Arquitetura em camadas Camadas dever ter sentido “Verifique suas responsabilidades” As camadas tem que ter separação.

25. Arquitetura proposta no DDD

26. Blocos que compõe o modelo

27. Entidade Entidade: têm significado no domínio Entidade: possuem identidades

28. Objeto de valor não tem identidade para o negócio São imutaveis Descrevem coisas, tipos... Ciclo de vida rápido Exemplo: cores, especialidade, tipo de dados.

30. Agregados Entidade Entidade Objeto de valor Objeto de valor

31. Exemplo <<Raiz>> Motor <<Raiz>> Carro Roda Cliente Posição Posição

32. Algumas regras

33. Fábricas Quando a criação de um objeto, ou AGREGADO inteiro, se torna complicada ou revela uma grande parte da estrutura interna, as FÁBRICAS fornecem o encapsulamento

34. Interação básica com uma fábrica A FÁBRICA faz o objeto que satisfaz o cliente e as regras internas O cliente especifica o que quer Cliente Fábrica Produto novos(parâmetros) criar produto

35. Serviços Não tem estado próprio Fica isolado do modelo Definido como o que ele pode fazer por um “cliente” “Verbo em vez de substantivo” Fala a linguagem ubíqua

36. Módulos ou Pacotes Os módulos existentes na camada de domínio devem surgir como uma parte significativa do modelo. Modelos = Histórias Módulos = Capítulos Módulos = Capítulos Módulos = Capítulos Módulos = Capítulos Módulos = Capítulos Módulos = Capítulos

37. Código Cliente Entidade Repositório Repositórios Busca Agregado Entidade Entidade Cria Entidade Remover Agregado Entidade Agregado

38. Linguagem Ubíqua Design Dirigido por Modelos Expressar o modelo Nomes entram em Isolar o modelo Arquitetura em camadas Módulos Serviços Entidades Objeto de Valor Integridade Encapsula Encapsular Repositórios Fábricas Acessar Agregados

39. Obrigado E-mail:thiagoholder@gmail.com Blog:http//thiagoholder.wordpress.com Msn: thiagoholder Skype: thiagoholder