Exemplo Pratico
Imagine que sua empresa está desenvolvendo uma plataforma online de vendas e precisa implementar o recurso de recuperação de senha para os usuários. Com o FDD, esse recurso é tratado como uma feature (funcionalidade) que entrega valor real ao cliente.
FEATURE
1. Modelagem de Domínio
É a construção de uma visão geral do sistema, com foco nos conceitos principais envolvidos no projeto. O objetivo é identificar o que é importante no sistema e como as partes se relacionam.
No exemplo:
Os analistas e desenvolvedores se reúnem com o cliente ou stakeholders para entender o fluxo de recuperação de senha.
São identificados os objetos principais: Usuário, Email, Token, Senha.
Cria-se um diagrama simples mostrando como um Usuário pode solicitar uma redefinição e como o sistema responde com um Token.
Essa lista contém todas as funcionalidades que o sistema precisa ter, descritas em uma linguagem clara e centrada no valor para o cliente. Elas devem ser pequenas o suficiente para serem concluídas em até duas semanas.
Enviar link de redefinição de senha para o e-mail do usuário.
Validar o token do link de redefinição.
Exibir formulário para nova senha.
Validar nova senha (mínimo de caracteres, símbolos, etc).
Atualizar a senha no sistema.
Após a criação da lista, cada feature é planejada de forma incremental, ou seja, uma por vez ou em pequenos grupos, priorizando o que é mais importante ou urgente.
No exemplo:
A equipe planeja iniciar com:
Semana 1: Envio do link com token por e-mail.
Semana 2: Validação do token e exibição do formulário.
Semana 3: Validação da nova senha e atualização no banco.
Cada funcionalidade recebe um pequeno planejamento de design técnico. Um desenvolvedor é designado como "dono da classe" e detalha como vai implementar a feature, quais classes serão afetadas, quais testes serão feitos etc.
No exemplo:
Para a feature “Validar nova senha”:
Classes envolvidas: SenhaService, ValidadorDeSenha
Regras: mínimo 8 caracteres, pelo menos uma letra maiúscula, um número e um símbolo
O desenvolvedor define como vai codificar isso e prepara os testes.
Cada feature é implementada por um desenvolvedor, que será responsável por todo o ciclo: escrever, testar e entregar o código. Pair programming pode ser usado, mas a responsabilidade principal é de uma pessoa.
No exemplo:
A funcionalidade “Validar nova senha” é atribuída ao João. Ele escreve o código, executa testes unitários e faz o commit no repositório.
Code Review e Documentação
Todo código e documentação são revisados por outro membro da equipe. O objetivo é garantir qualidade, aderência aos padrões e evitar bugs futuros.
No exemplo:
Outro desenvolvedor revisa o código de João, sugere melhorias e valida se as regras de senha estão sendo aplicadas corretamente. O analista de requisitos verifica se a feature está documentada corretamente.
No exemplo:
Ao fim da semana, a feature de validação de senha é integrada ao sistema de homologação. O cliente testa o recurso em um ambiente simulado antes da ida ao ambiente de produção.
O status de cada feature é constantemente atualizado: “não iniciada”, “em andamento”, “entregue”, “em revisão” etc. Isso ajuda a equipe a se organizar e os gestores a tomarem decisões.
No exemplo:
A equipe utiliza um quadro Kanban ou ferramenta como Trello ou Jira para acompanhar:
“Validar nova senha” – Entregue
“Atualizar senha no banco” – Em andamento
“Enviar link por e-mail” – Atrasada
Cada feature deve ter uma documentação objetiva com quatro partes: Entrada, Tarefas, Verificação e Saída. Isso garante rastreabilidade e entendimento futuro.
No exemplo – Feature: Validar nova senha
Entrada: Senha digitada pelo usuário
Tarefas: Verificar número de caracteres, símbolos, letras maiúsculas e minúsculas
Verificação: Testes automatizados de validação
Saída: Confirmação da senha válida e atualização no banco
Esse processo contínuo permite que pequenas entregas com alto valor sejam feitas em ciclos curtos e previsíveis. O cliente vê resultado logo, a equipe trabalha de forma focada e o projeto evolui de maneira estável e rastreável.