Se já viu ou ouviu falar dos temidos sistemas legados sabe que modificar ou acrescentar novas funcionalidades são tarefas complexas ou inviáveis recorrendo a famosa e muito utilizada técnica de refazer tudo do zero com a esperança de que desta vez o software responda na mesma velocidade que o negócio evolui. E mesmo aplicando as “boas práticas” com o passar do tempo o resultado é o mesmo, um sistema complexo repleto de abstrações que não fazem sentido pro negócio. Nesta palestra vou te mostrar abordagens e ferramentas do Domain Driven Design (DDD) que vão te ajudar a construir sistemas de maneira colaborativa com o pessoal que entende do negócio junto com quem é mais técnico (Devs, UX, …) para que o sistema reflita o negócio e evolua de acordo com a velocidade do negócio.

1. Indo além do técnico
para desenvolver sistemas
que evoluem na
velocidade do negócio
Sebastian Ferrari - CTO
@sebas5384

2. Quem?
Sebastian Ferrari (Sebas)
● Uruguaio morando no Brasil
● CTO e Co-fundador da Taller
● +15 anos construindo sistemas
● Agilista e praticante do Fluxo Unificado a
vários anos
● +2 anos como praticante de DDD e
Eventstormer
@sebas5384

3. Velocidade do Negócio?
Negócio
muda
Proposta de
mudança
Processo de
Desenvolv.
Novo
Sistema

4. Pensamento linear

5. O sistema começa com um simples
modelo da realidade se tornando
cada vez mais complexo
Sistema evolui com o
passar do tempo

6. Pensamento Sistêmico
Modelo mental que ajuda a
dar sentido à complexidade,
incentivando um equilíbrio entre
reducionismo e emergência.

7. O que é um sistema?
Um conjunto de elementos inter-relacionados organizados
para servir a uma função específica ou
para buscar um objetivo específico.
– Donella Meadows

8. Modelo inicial,
rápido de criar.
1
2
3
.
.
.
Domínios
Modelos

9. Modelo inicial,
rápido de criar.
1
2
3
.
.
.
Evolução resultando no
“Big Ball of Mud”.
Domínios
Modelos

10. Modelo inicial,
rápido de criar.
1
2
3
.
.
.
Evolução resultando no
“Big Ball of Mud”.
Funciona, mas ninguém
sabe como.
Mudanças se tornam
arriscadas e difíceis.
Domínios
Modelos

11. complexidade
do design
tempo

12. complexidade
do design
tempo

13. complexidade
do design
tempo
O que acha que precisa
mais tarde.
O que precisa agora.
O que tem agora.
YAGNI
You Ain‘t Gonna Need It
agora depois

15. Design por meio
de refatoração
A coisa mais simples
que possa funcionar
Realize progresso em
pequenos passos

16. Grande design
prematuro
Design caótico
e aleatório
Design bom e
incremental

17. A complexidade no Software,
é o resultado inerente da
complexidade do domínio (essencial)
misturada com a
complexidade técnica (acidental)
– Scott Millet

18. Domínio?
Uma esfera específica de atividade (o que) ou conhecimento (como).
Área do problema, é o que dá motivo de existência ao modelo.
Onboarding
Vendas
Precificação
Marketing

19. Modelo do Domínio
Domínio do
mundo real Modelo do Domínio
para o caso de uso

20. O que é o DDD?
Domain Driven Design
Abordagem de design de software, com foco
na modelagem de software para corresponder
a um domínio de acordo com a entrada dos
especialistas desse domínio.
– Wikipedia
Eric Evans - 2003

21. Outros livros
Vaughn Vernon

22. Microsserviços
Foco no tático
Devs estão se
distanciando
do problema

23. Pilares
Duas categorias de design:
Tático
Estratégico

24. Pilares
Duas categorias de design:
Tático
Estratégico
Ferramentas para a
modelagem e
entendimento do
domínio de maneira
colaborativa
● Contextos Delimitados
● Linguagem Ubíqua
● Mapeamento de
Contextos

25. Pilares
Duas categorias de design:
Tático
Estratégico
Padrões técnicos para
construir modelos do
domínio dentro do
contexto delimitado:
● Entities
● Value Objects
● Aggregates
● Repository
● Services
● Events
● Modules
● Factories

26. NÃO

27. Construa entendimento coletivo se
aproximando aos especialistas de
domínio e desenhe o sistema com
enfoque no domínio principal do negócio
Design Estratégico

28. Contexto Delimitado
● Delimitação linguística ou conceitual
● Limita um conceito a um determinado contexto
● É o que dá significado a um substantivo
● Evita ambiguidade

29. Contexto Delimitado
Reserva
Identificação
e
Autenticação
Usuário
Contexto Contexto
Modelo
ambíguo
model model
model
model
model

30. NÃO
na maioria dos
casos…

31. Contexto Delimitado
Reserva
Identificação
e
Autenticação
Passageiro Usuário

32. Linguagem Ubíqua
● Linguagem utilizada dentro de um contexto
● Sem ambiguidade
● Sem jargões, não é uma linguagem “universal”
● Comunicação entre especialistas do domínio
e pessoas técnicas, ou outros envolvidos
● Faça um glossário dos conceitos por contexto

33. Organizações que desenvolvem
sistemas de software tendem a
produzir sistemas que são cópias
das estruturas de comunicação
dessas organizações.
– Melvin Conway, 1967

34. Mapeamento de Contexto
Pagamento Catálogo
Venda
U
D
Upstream/
Downstream
Parceria

35. Mapeamento de Contexto
Pagamento Venda
U D
Camada
Anticorrupção
ACL
Compra Ordem

36. Camada Anticorrupção

37. Mapeamento de Contexto
Contexto
Subdomínio

38. Subdomínios?
● Core / Principal
Diferencial de seu negócio, maior investimento
● Suporte
Necessário para o negócio funcionar
● Genérico
Solução de prateleira, nada especial para o negócio

41. Plataforma de validação,
exploração e construção do
Storytelling do negócio
de maneira colaborativa
EventStorming

42. EventStorming?
● Criado em 2012 que evoluiu na
comunidade DDD
● Baseado em Workshops e Gamestorming
para construir narrativas com eventos
● Modelagem colaborativa do domínio,
processos, jornadas de usuário ou fluxos
de trabalho
● Começa com um canvas em branco com
post-it na mão
Alberto Brandolini

43. Livro
Alberto Brandolini
Introducing
EventStorming
An act of Deliberate
Collective Learning

44. Entendimento coletivo
contando histórias

45. “ A ignorância é o maior
impedimento para o
throughput ”
– Dan North

48. Por que Eventos?
Eventos
Comportamento emergente
Propósito ou função
Interconexões / Relações
Elementos
Entender
um sistema

49. Exploração

50. Gerar Caos

51. Gerar Caos

52. Estrutura emergente

53. Estrutura emergente

54. Estrutura e relações
Subdominios
e Contextos

55. Validação de narrativas

56. Validação de narrativas

57. Vários sabores
● Big Picture
Usando eventos, atores, ações e sistemas para uma visão
geral do sistema envolvendo o pessoal de negócio.
● Process Modeling
Adicionando políticas e “informações” necessárias para as
ações, serve para entender ou criar novos serviços.
● Software Design
Mergulho em contextos com tecniquês, adicionando os
“agregados” ou componentes do software.

58. Diferentes momentos
TO-BE
AS-IS
Oportunidades
e problemas
Validação entre
o ideal e viável

59. Software Design

60. Aceitando a realidade

61. Descoberta incremental

62. “ É o entendimento do
desenvolvedor que se
torna software, e não o do
Stakeholder ”
– Alberto Brandolini

63. “ Por anos juntamos vários
times de uma organização e
misturamos em um software ”
– Alberto Brandolini

64. Manda
Salve!
sebas@taller.net.br
taller.net.br
blog.taller.net.br
Instagram: taller.team
Twitter: @tallerteam
Tallercast: spoti.fi/3V5w1Yk
Estamos contratando!