Visão geral

Domain-Driven Design (DDD) é uma forma de desenvolver software que foca em implementar o melhor design de software baseado em modelos que refletem explicitamente as competências da organização. DDD força a organização a entender onde deve se distinguir, ao mesmo tempo em a guia na criação de um modelo de software correto. Isso leva a software valioso, usável e também elimina desperdícios.

Por que me importar?

Software está comendo o mundo e as empresas precisam se tornar em empresas de software. Não importa se o negócio está em um ramo tradicional, como finanças ou manufatura, software evoluiu de uma ferramenta para suportar o negócio para ser o negócio em si.

A revolução Ágil que aconteceu nos últimos 16 anos reduziu significantemente o ciclo de entrega de software. Mas foi uma revolução parcial, pois muitas empresas que passaram por uma transformação Ágil não adotaram as práticas técnicas aos quais as metodologias Ágeis se amparam. E pior, nesse processo, o design também foi relegado e muitos projetos Ágeis estão produzindo código ruim.

Para as empresas, isso significa oportunidades perdidas. A única forma de resolver esse problema é voltar a fazer design.

Duração

45 minutos

Eventos

Esse conteúdo foi apresentado (ou será apresentado) no(s) seguinte(s) evento(s):

Dicas dadas durante a palestra

Livros

Sugiro a leitura na seguinte ordem:

  1. Vernon, 2016. Domain-Driven Design Distilled (minha resenha)
  2. Vernon, 2013. Implementing Domain-Driven Design
  3. Evans, 2003. Domain-Driven Design: Tackling Complexity in the Heart of Software

Como fazer uma sessão de Event Storming ou de User Story Mapping

O livro Domain-Driven Distilled, do Vaughn Vernon, contém uma descrição completa de como fazer uma sessão de Event Storming.

Dou uma visão geral de como fazer uma sessão de User Story Mapping no meu artigo Mapeando seu conhecimento de domínio.

Citações, referências e agradecimentos

Citações

As citações nem sempre são literais, mas tento manter o sentido delas o mais próximo possível do texto original. Incluo o texto original quando a citação for adaptada e/ou traduzida.

  • Slide 2.

    Software está comendo o mundo

    In short, software is eating the world.

    Andreessen, 2011.
  • Slide 3.

    Muitos projetos ágeis estão produzing código ruim

    Many Agile projects are now, steadily and iteratively, producing crap code.

    Mancuso, 2014. p. 12
  • Slide 4.

    Questionamentos se design é necessário ou acessível perdem o ponto: design é inevitável. A alternativa para bom design é design ruim, e não a ausência de design

    Questions about whether design is necessary or affordable are quite beside the point: design is inevitable. The alternative to good design is bad design, not no design at all.

    Douglas Martin. Vernon, 2016. p. 5
  • Slide 5.

    Uma Grande Bola de Lama é uma selva de código mal estruturado, desleixado, espaguete e todo remendado com fita adesiva

    A Big Ball of Mud is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle.

    Foote; Yoder, 1999.
  • Slide 7.

    É um enigma. As pessoas que são especialistas no domínio – os especialistas de domínio – raramente estão qualificadas para escrever software. As pessoas que estão qualificadas para escrever software – os programadores – nem sempre entendem o domínio-problema.

    It's a conundrum. The people who are experts in the problem domain – the domain expers – are rarely qualified to write software. The people who are qualified to write software – the programmers – don't always understand the problem domain.

    Shore, 2007. p. 126
  • Slide 8.

    Se os programadores não estão interessados no domínio, eles aprendem apenas o que a aplicação deve fazer, não os princípios por trás dela. Software útil pode ser desenvolvidor dessa maneira, mas o projeto nunca chegará em um ponto onde novas funcionalidades poderosas surgirão como desdobramento de funcionalidades existentes.

    (...) if programmers are not interested in the domain, they learn only what the application should do, not the principles behind it. Useful software can be built that way, but the project will never arrive at a point where powerful new features unfold as corollaries to older features.

    Evans, 2003. p. 14
  • Slide 14. Imagem, Da Vinci pintando a Monalisa por partes como se tivesse uma visão clara do resultado final. Patton, 2014. p. 139
  • Slide 15. Imagem, Da Vinci pintando a Monalisa de forma iterativa, onde cada iteração aproxima o quadro do resultado final. Patton, 2014. p. 140
  • Slide 16.

    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.

    Strategic design is used like broad brushstrokes prior to getting into the details of implementation. It highlights what is strategically important to your business, how to divide up the work by importance, and how to best integrate as needed.

    Vernon, 2016. p. 7
  • Slide 17.

    DDD é primariamente sobre modelar uma Linguagem Ubíqua em um Contexto Delimitado

    In short, DDD is primarily about modeling a Ubiquitous Language in an explicitly Bounded Context.

    Vernon, 2016. p. 11
  • Slide 38.

    Software funcionando é a medida primária de progresso.

    Beck et al, 2001.
  • Slide 39.

    No DDD há esse princípio de que o software deve refletir o modelo explicitamente

    But in Domain-Driven Design, there is this principle that the software should explicitly reflect that model

    Evans, 2016. Minuto 3:50
  • Slide 41.

    Microserviços são serviços pequenos e autônomos que trabalham em conjunto

    Microservices are small, autonomous services that work together.

    Newman, 2015. p. 2
  • Slide 42.

    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 microserviços estão com baixo acoplamento e alta coesão

    So, if our service boundaries align to the bounded contexts in our domain, and our microservices represent those bounded contexts, we are off to an excellent start in ensuring that our microservices are loosely coupled and strongly cohesive.

    Newman, 2015. p. 33
  • Slide 46.

    A arte nunca está terminada, é apenas abandonada

    Great art is never finished, only abandoned.

    Leonardo da Vinci. Patton, 2014. p. 141
  • Slide 47.

    Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.

    Beck et al, 2001.
  • Slide 51. Imagem, Construindo conhecimento compartilhado com conversas. Patton, 2014. p. 29
  • Slide 52.

    Não podemos fugir da responsabilidade de sermos humanos

    There is no way to escape the weight of responsibility that comes with being human.

    Warburton, 2011. p. 199

Referências

Agradecimentos

Agradeço às seguintes pessoas pela ajuda inestimável:

Tecniquês

Softwares usados

  • LibreOffice Impress
  • GIMP
  • Inkscape

Créditos dos arquivos audiovisuais