Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Começando com Domain-Driven Design

Começando com Domain-Driven Design

Nesta palestra iremos introduzir o que é domain-driven design e como a utilização de seus fundamentos podem ajudar na construção de uma aplicação mais robusta e flexível. Serão apresentados conceitos como linguagem ubíqua, model-driven design, bounded contexts e os principais blocos de construção (entidades, objetos de valor, agregados entre outros). Assista essa palestra e conheça o valor que o domain-driven design entrega ao permitir aplicações mais expressivas e projetadas para mudança.

Marcel dos Santos

September 12, 2020
Tweet

More Decks by Marcel dos Santos

Other Decks in Programming

Transcript

  1. Interaja nas mídias sociais!
 
 - fale sobre o evento,

    palestrantes e conteúdo - tire fotos do evento e publique
 - interaja com outros participantes do evento - tire dúvidas ou dê feedbacks para os palestrantes
  2. o termo é o nome de um livro famoso conhecido

    como "livro azul" escrito por Eric Evans em 2003
  3. e, como diz o título do livro, domain-driven design é

    sobre atacar as complexidades no coração do software
  4. "The heart of software is its ability to solve domain-related

    problems for its user." 
 ― Eric Evans, Domain-Driven Design
  5. exemplo 01 
 escolher entre utilizar monolitos ou microsserviços, framework

    A ou B, banco de dados relacionais ou não-relacionais são exemplos de complexidades acidentais
  6. exemplo 02 
 a coordenação de motoristas de aplicativos, isto

    é, identificar os motoristas disponíveis nas imediações da solicitação de uma chamada é um exemplo de complexidade essencial pois faz parte do problema
  7. a complexidade essencial é aquela que não pode ser evitada

    e está relacionada a complexidade do domínio
  8. a linguagem ubíqua é a linguagem criada pelo time de

    desenvolvimento em conjunto com os especialistas de domínio
  9. ela surge da conversa com especialistas de domínio e deve

    ser compreendida por todos e sem ambiguidade
  10. o código desenvolvido deverá utilizar a linguagem ubíqua no nome

    de módulos, classes, métodos e funções
  11. exemplo 03
 
 um especialista de domínio descreve o seguinte

    cenário: "o cliente poderá finalizar o pedido quando estiver satisfeito com os itens em seu carrinho de compras"
  12. no código teremos:
 
 - uma classe para a entidade

    Cliente
 - uma classe para a entidade 
 CarrinhoDeCompras
 - um método para a ação finalizarPedido()
  13. "To communicate effectively, the code must be based on the

    same language used to write the requirements—the same language that the developers speak with each other and with domain experts." 
 ― Eric Evans, Domain-Driven Design
  14. uma "big ball of mud" ou grande bola de lama

    é um código com uma arquitetura mal definida…
  15. …e que correções e pequenas evoluções se tornam um grande

    desafio pela dificuldade de compreender o código
  16. "A big ball of mud is haphazardly structured, sprawling, sloppy,

    duct-tape and bailing wire, spaghetti code jungle.” 
 ― Brian Foote and Joseph Yoder, 1999
  17. "Uma grande bola de lama é uma selva de código

    espaguete, aleatoriamente estruturado, espalhado, desleixado e cheio de fita adesiva." 
 ― Brian Foote and Joseph Yoder, 1999
  18. subdomínio principal
 
 - domínio que traz valor para o

    negócio e onde fica a lógica principal
 
 - é a atividade principal da empresa e geralmente é um software feito sob medida
  19. subdomínio de suporte
 
 - suporta o domínio principal
 


    - é importante mas não representa o negócio principal
  20. subdomínio genérico
 
 - não possui relação direta com o

    domínio principal
 
 - geralmente faz uso de software terceiro
  21. contexto delimitado ou bounded context é uma fronteira conceitual onde

    reside o modelo de domínio e a linguagem ubíqua
  22. os contextos delimitados buscam delimitar o seu domínio complexo em

    contextos baseados nas intenções do negócio
  23. a linguagem ubíqua dentro de um contexto permite definir o

    limite de conceitos que podem ser diferentes dentro de diferentes contextos
  24. exemplo 04
 
 uma entidade Usuario no contexto A pode

    ser diferente de uma mesma entidade Usuario no contexto B
  25. isto significa que você deve delimitar as intenções de suas

    entidades com base no contexto que ela pertence
  26. cada contexto delimitado pode ter a sua própria arquitetura, modelo

    de persistência e ser desenvolvido por um time diferente
  27. os contextos delimitados podem se comunicar de diversas maneiras como,

    por exemplo, utilizando APIs REST ou sistema de mensageria
  28. um subdomínio é relacionado ao problema de domínio e o

    bounded context é relacionado à solução do problema
  29. "Se os limites dos nossos serviços alinham- se aos contextos

    delimitados do nosso domínio, nós começamos bem para garantir que nossos microsserviços estão com baixo acoplamento e alta coesão" 
 ― Sam Newman
  30. os padrões de compartilhamento são:
 
 - núcleo compartilhado
 -

    produtor-consumidor
 - conformista
 - parceria
 - camada anticorrupção
  31. o domain-driven design fornece um conjunto de conceitos e padrões

    para auxiliar no projeto do software em nível tático e estratégico
  32. é no design tático que falamos sobre entidades, objetos de

    valor, serviços de domínio, eventos de domínio, agregados, repositórios e fábricas
  33. os padrões não são exclusividade do domain-driven design, isto é,

    eles já eram conhecidos e utilizados anteriormente
  34. "Design estratégico é como fazer o rascunho antes de entrar

    nos detalhes da implementação. Destaca o que é estrategicamente importante para o seu negócio, como dividir o trabalho por importância e como fazer integrações da melhor maneira." 
 ― Vaughn Vernon
  35. a arquitetura em camadas é utilizada para organizar a aplicação

    e permite separá-la em camadas com responsabilidades específicas
  36. domínio
 
 responsável por conter os conceitos e regras de

    negócio relacionados ao domínio e é o principal foco do domain-driven design
  37. infraestrutura
 
 responsável por fornecer os recursos técnicos que dão

    suporte às outras camadas como persistência de dados e I/O
  38. agregados
 
 é um elemento conceitual que é responsável por

    conter outras entidades que não podem ser acessadas de fora
  39. agregados
 
 para isso utiliza-se o encapsulamento e a lei

    de Demeter e sempre falaremos com o aggregate root
  40. eventos de domínio
 
 representa algo que ocorreu no domínio

    e que é desejado que outras partes tenham conhecimento
  41. fábricas
 
 agregados são complexos e as fábricas permitem extrair

    a complexidade de criação de uma agregado de sua definição
  42. serviços
 
 classes que contém regra de negócio mas que

    não pertencem a nenhuma entidade ou objeto de valor
  43. repositórios
 
 o domínio não deve estar acoplado a um

    banco de dados e, para isso, utiliza-se abstrações (e, mais especificamente, o padrão data mapper)
  44. módulos
 
 o agrupamento não deve ser feito segundo conceitos

    de infraestrutura e, sim, conceitos de domínio
  45. o foco do domain-driven design é atender as necessidades do

    domínio, ou seja, a complexidade essencial
  46. para isso, deve-se utilizar a linguagem onipresente para aproximar os

    especialistas de domínio da equipe técnica
  47. uma aplicação construída com domain- driven design pode fazer uso

    de qualquer decisão arquitetural como arquitetura hexagonal, CQRS ou clean architecture