DDD - Domain Storytelling

Definição Formal

"Domain Storytelling é uma técnica colaborativa e visual que utiliza uma linguagem pictográfica simplificada para transformar o conhecimento dos Domain Experts em narrativas visuais claras. O objetivo principal é alinhar a compreensão entre o time de negócio e o time de TI, mapeando como atores, objetos e atividades se relacionam no tempo."
— Hofer & Schwenter (2021)

Em outras palavras

Não tente adivinhar as regras lendo código antigo ou especificações gigantes. Em vez disso, junte os Domain Experts e peça para eles contarem histórias do dia a dia do negócio.

Enquanto eles contam, você desenha a história na tela usando ícones simples. Isso expõe ruídos de comunicação, remove jargões de TI e cria um entendimento único do processo real antes de escrever qualquer linha de código.

1. A Linguagem Pictográfica (A Sintaxe Visual)

Sua história será contada combinando apenas 3 elementos fundamentais:

• Atores (Quem?): Representam as pessoas, sistemas, times ou papéis que executam alguma ação.
  • Regra: Nomeie por função, nunca pelo nome da pessoa (ex.: use Secretária, não Maria).
• Objetos de Trabalho (O quê?): Elementos físicos, digitais ou abstrações manipulados pelos atores.
  • Exemplos: Ficha de Matrícula (físico), E-mail de Confirmação (digital), Matrícula (conceito).
• Atividades (Como?): Representadas por setas nomeadas indicando as ações que os atores realizam sobre os objetos de trabalho.

2. As Regras de Ouro da Modelagem

Para manter o diagrama legível para o negócio, evite vícios de programação:

1. Sem Condicionais (if-else): O mapa foca no caminho feliz daquela história específica. Fluxos alternativos ou de erro devem virar novas histórias.
2. Sem Retornos (loopback): Não desenhe setas voltando só para indicar "resposta" ou "confirmação" (como faria em diagramas de infra/redes). Foque no objetivo e intenção da ação.
3. Números Sequenciais: Toda ação (seta) recebe um número (1, 2, 3...) para dar ordem cronológica à narrativa. Ações em paralelo usam o mesmo número.
4. Escopo ("Nível do Mar"): Foque no objetivo real do usuário. Não detalhe cliques na tela ou chamadas de API, nem suba demais ao ponto de perder a regra de negócio.

3. Elementos de Organização e Destaque

• Anotações: Notas coladas ao diagrama para sinalizar limites, gatilhos de eventos, regras de negócio ou exceções pontuais.
• Grupos: Linhas de fronteira desenhadas ao redor de um conjunto de passos para delimitar subdomínios, etapas do processo ou responsabilidades de sistemas.
• Cores: Utilizadas pontualmente para dar ênfase visual a gargalos, falhas ou trechos de atenção crítica no fluxo.

4. Estratégia e Dinâmica da Sessão

Cenários: AS IS vs. TO BE

• AS IS (O Hoje Real): O processo exatamente como ele acontece na prática. Comece sempre por este para garantir que todos entendam a dor atual.
• TO BE (O Amanhã Desejado): A proposta de novo processo otimizado suportado pelo software.

Papéis na Sala de Mapeamento

• Domain Experts: Contam as histórias do negócio e validam se o desenho refletido está correto.
• Ouvintes: Time de desenvolvimento/TI focado em aprender sobre o domínio.
• Moderador: Guia a conversa, faz perguntas e impede que o grupo se perca em detalhes técnicos ou discussões fora de escopo.
• Modelador: Desenha a história em tempo real utilizando os elementos pictográficos.

Takeaway

Domain Storytelling não é para desenhar arquitetura de software ou fluxo de banco de dados; é para entender o processo do negócio. Desenhe a história atual (AS IS), garanta que todos concordam com ela e só então projete como o software ajudará no processo futuro (TO BE).