O quadro branco é onde o sistema é construído de verdade

Já vi muitos sistemas serem construídos, e o padrão se repete: as decisões que importam foram tomadas na primeira hora, geralmente em pé na frente de um quadro branco ou de um diagrama compartilhado, muito antes de alguém abrir o editor. Tudo o que veio depois foi implementação dessas decisões, boas ou ruins.

Código é a coisa mais barata de mudar

As pessoas acham que código é caro e diagrama é barato, então passam correndo pelo diagrama para chegar logo no código. É o contrário. Código é o artefato mais mutável de um projeto. Um refactor custa um dia. Uma decisão de schema custa uma migração. Uma fronteira entre dois serviços custa um contrato, um acoplamento de deploy e um ano de coordenação. O modelo de dados e as fronteiras são o que o quadro branco decide, e são justamente as coisas que você não vai conseguir mudar depois sem dor.

O que eu desenho de verdade

Eu não desenho diagramas de arquitetura com caixinhas bonitas. Desenho quatro coisas, nesta ordem.

Primeiro, os dados. Quais são os substantivos, quem é dono de cada um e qual é a fonte da verdade. Se duas caixas acham que são donas do cadastro do cliente, já encontrei o primeiro bug.

Segundo, as escritas. Toda seta que muda estado. Leitura perdoa; escrita é onde moram consistência, ordem e idempotência. Para cada seta de escrita, eu pergunto o que acontece se ela funcionar e a resposta se perder.

Terceiro, as fronteiras. Onde termina um time, um deploy, um banco, e onde começa o outro. Toda fronteira é um lugar onde pode acontecer uma falha parcial, então eu quero o menor número que o problema realmente exige.

Quarto, os caminhos de falha, desenhados em outra cor: o timeout, o retry, a fila que acumula. Se o diagrama não tem linha vermelha, é diagrama de venda, não de design.

As perguntas que o quadro responde e o código não

O código responde "funciona?". O quadro branco responde "essa é a forma certa?". Na prática: existe uma única tabela em que toda funcionalidade escreve, e que vai virar o gargalo? Existe uma cadeia síncrona de quatro chamadas em que um elo lento trava o usuário? Existem duas fontes da verdade para o mesmo fato? Existe um relatório que precisa de dados de três serviços que nunca vão estar consistentes no mesmo instante?

Esses são problemas de forma. Você não enxerga isso num pull request, porque um pull request mostra um caminho. Você enxerga num diagrama, porque o diagrama mostra todos os caminhos de uma vez.

Como conduzir uma boa sessão de quadro branco

Mantenha o grupo pequeno: duas a quatro pessoas, e pelo menos uma que conheça as regras de negócio de cor. Comece por uma história de usuário concreta, não por componentes. Desenhe os dados primeiro, depois percorra a história por cima deles, seta por seta. Toda vez que alguém disser "e aí ele só chama o serviço", pare e pergunte o que esse "só" está escondendo. Registre as decisões como frases, não como figura, porque a figura vai se perder e as frases vão ser lidas.

Mais uma regra: quando alguém propuser um componente, pergunte qual problema ele resolve que o desenho atual não resolve. Metade das filas, caches e serviços propostos nessas sessões são soluções procurando um problema, e o quadro branco é o lugar mais barato para dizer não.

A parte que as pessoas pulam

A sessão termina com uma lista de coisas que vocês decidiram não tratar. Essa lista vale tanto quanto o diagrama. Seis meses depois, quando algo quebrar, ela diz se foi surpresa ou trade-off conhecido. Sistemas construídos sem essa lista tratam todo incidente como mistério. Sistemas construídos com ela tratam a maioria dos incidentes como dívida agendada.

Já auditei sistemas suficientes para dizer isso sem rodeio: normalmente consigo saber, só pelo schema e pelas fronteiras, se a hora de quadro branco aconteceu. Quando aconteceu, o código é chato e os incidentes são pequenos. Quando não aconteceu, o código é esperto e os incidentes não são pequenos.