Introdução ao Domain-Driven Design

Introdução ao Domain-Driven Design

• 1.
  André Zanatta Borgonovo
• 2.
  1. Introdução 2. Conceitos 3. Arquitetura 4. Artefatos de Domínio (exemplos em C#) 5. Aplicação e Processo
• 3.
  O que ée não é DDD
• 4.
   Algo que resolve tudo  Sempre a melhor solução  Um caminho fácil para seguir “Everything should be made as simple as possible, but not simpler.” Albert Einsten
• 5.
   Design (Projeto) Orientado ao Domínio  Uma abordagem de desenvolvimento de software  Uma metodologia de arquitetura para a evolução de um sistema alinhado às necessidades do negócio  Software OO feito da maneira correta (Jak Charlton, DDD Step-by-step)
• 6.
  “Atacando as Complexidades no Coração do Software” Eric Evans
• 7.
  1. Corrige a arquitetura do projeto. Diminui a complexidade e aumenta a manutenibilidade da aplicação 2. Você faz software para durar 3. Quem deve se preocupar com DDD? 4. “Durabilidade” do DDD 5. Outros *DDs
• 8.
   O foco é no domínio, são as regras de negócio, os comportamentos  O foco NÃO é trabalhar com o banco de dados  Software de negócios com regras complexas “Domínio é a área de conhecimento do software”
• 9.
   O foco deve ser o domínio e a lógica do domínio  Projetos complexos devem ser baseados em um modelo  Iniciar uma colaboração criativa entre a área técnica e os domain experts para iterativamente estarem mais perto do coração conceitual do problema
• 10.
  Linguagem ubíqua, contextos delimitados,módulos, domain expert, domínio e modelo
• 11.
  Ubiquitous = Ubíquo= Está em todo lugar Linguagem ubíqua é a linguagem usada pelo: Business expert = Domain expert = Product owner (Scrum) • O time inteiro utiliza a mesma linguagem • Não utilizar linguagem técnica para falar com o Domain expert • Proximidade entre o Domain expert e os desenvolvedores • A análise realizada deve ser natural para o Domain expert • É importante que todos do projeto conheçam o domínio • Substantivos = Classes • Verbos = Métodos, Serviços e etc.
• 12.
   É relativo. Não tem padrão. Baseado em abstrações.  É usado para resolver problemas. Tem que ser útil.  Deve estar atualizado. Deve refletir no código.  Representa o domínio. Use POCOs (Plain Old CLR Objects)
• 13.
  Pode ser assim: Ferramenta ajuda a manter seu modelo atualizado …Ou assim:
• 14.
  Apresentação Aplicação Domínio Infraestrutura
• 15.
  • Camadas devem estar separadas • Separação de responsabilidades • Arquitetura flexível Layers X Tiers Layers: Camadas lógicas Tiers: “Projetos do Visual Studio”
• 17.
  Usuário pode seroutro sistema. Camada de apresentação
• 18.
  Coordena as atividades(workflow) da aplicação. Transformação de objetos (DTOs). Transação, auditoria e segurança.
• 19.
  “A camada dedomínio é o coração do software”
• 20.
  Persistência de dados. Conceitostransversais: autenticação, autorização, cache, gerenciamento de exceções, log, validação.
• 21.
  Usuário pode seroutro sistema. Camada de apresentação Coordena as atividades (workflow) da aplicação. Transformação de objetos (DTOs). Transação, auditoria e segurança. “A camada de domínio é o coração do software” Persistência de dados. Conceitos transversais: autenticação, autorização, cache, gerenciamento de exceções, log, validação.
• 23.
  Entidades, objetos devalor, agregações, fábricas, serviços e repositórios
• 24.
   Objetos que tem significado no Domínio  Tem identidade  Exemplos: ◦ Cliente ◦ Carro ◦ Produto
• 25.
  Abstração para entidades Entidadesimples
• 26.
   Não tem identidade para o negócio  São reconhecidos pelos seus atributos  Atributo diferente = objeto diferente  Imutáveis  Exemplos: ◦ Cores ◦ Coordenadas ◦ Endereços
• 27.
  Abstração para objetos de valor Objeto de valor simples
• 30.
   Reúne entidades e objetos de valor que fazem sentido no domínio  Raiz da agregação (Aggregate Root)  Regras de agregações: ◦ Todas as atualizações passam pela raiz ◦ Todas as referencias obtidas para os objetos recupera-se pela raiz ◦ Exclusão apaga todos os filhos da agregação ◦ Regras de negócio são garantidas pela raiz
• 33.
   Resolvem problemas de negócio, mas não são entidades ou objetos de valor  Um bom serviço tem três caracteristicas: 1. A operação é relacionada a um conceito do domínio que não é naturalmente parte de uma entidade ou objeto de valor 2. A interface é definida baseada em outros objetos do modelo do dominio 3. A operação é Stateless
• 35.
   Criam objetos de negócio  É responsabilidade de um objeto construir a si mesmo?  Regras complexas para construção  Fábrica cria objetos consistentes
• 37.
   “Não tem banco de dados”  Persistence Ignorance  Representam uma lista de itens em memória  Não tem lógica de negócio. No máximo valida consistência do objeto. Assim como guardou deve ser recuperado  São especificados para Agregações, não para Entidades
• 38.
  Abstração para repositórios Repositóriosimples
• 39.
  Exemplo de implementação de repositóriocom Entity Framework
• 40.
   Fábricas criam os objetos  Repositórios: ◦ Inserem; ◦ Recuperam; ◦ Alteram; ◦ Destroem os objetos.
• 41.
  Go DDD, goAgile!
• 42.
   Regras denegócio complexas  Atenção: ◦ Arquitetos geralmente trabalham em projetos complexos ◦ Projetos simples podem se tornar importantes para o negócio da empresa no futuro Use DDD na maior parte dos softwares que tem regra de negócio
• 43.
   Não para o desenvolvimento em cascata (Waterfall). Recomendado desenvolvimento ágil  DDD aceita as mudanças. Software se torna altamente adaptável  Proximidade e contato com o Domain expert
• 46.
  Autor André Zanatta Borgonovo [email protected] @azborgonovo LinksRecomendados http://domaindrivendesign.org/ http://microsoftnlayerapp.codeplex.com/ http://blog.lambda3.com.br/