As fronteiras são o produto

Quando audito um sistema, não começo pelas funcionalidades. Começo pelas linhas. Onde uma coisa termina e outra começa? Quem pode chamar quem? O que pode mudar sem acordar três outros times? As respostas me dizem mais sobre os próximos dois anos daquela empresa do que qualquer roadmap.

A maioria dos times acha que está entregando funcionalidades. Está entregando fronteiras. A funcionalidade é o que o usuário vê neste trimestre. A fronteira é aquilo com que toda funcionalidade futura vai precisar negociar.

Funcionalidade é temporária, fronteira não

Um botão de checkout é redesenhado quatro vezes. A decisão de que checkout, estoque e pagamentos compartilham uma única tabela com uma coluna de status sobrevive a todos os redesigns. Sobrevive porque ninguém vê, ninguém é dono, e mover isso exige mexer em tudo ao mesmo tempo.

Por isso digo que a fronteira é o produto. É a parte do sistema com a meia-vida mais longa. Código dentro de uma fronteira bem traçada pode ser reescrito em uma semana. Código que atravessa uma fronteira mal traçada não pode ser reescrito de jeito nenhum sem um projeto de migração que ninguém quer financiar.

O teste que uso é simples. Pegue qualquer módulo e pergunte: se eu apagasse isso amanhã e reconstruísse do zero, o que mais quebraria? Se a resposta for 'só quem chama, através de um contrato', a fronteira é real. Se a resposta for 'a gente teria que verificar', a fronteira é decorativa.

Como é uma fronteira de verdade

Uma fronteira de verdade tem quatro propriedades, e eu confiro cada uma delas em revisão.

• Tem um único ponto de entrada explícito: uma função, um export de módulo, um endpoint HTTP, um tópico de fila. Não sete.
• É dona dos próprios dados. Ninguém mais lê ou escreve naquelas tabelas, arquivos ou chaves diretamente.
• Pode falhar sem derrubar os vizinhos. Um timeout de um lado vira um erro do outro, não um travamento.
• O contrato está escrito em algum lugar que não é a implementação: tipos, um schema, um arquivo OpenAPI, uma suíte de testes que um estranho conseguiria ler.

Repare que nada disso exige microsserviços. Uma pasta num projeto Next.js com um único export no index.ts e uma camada de acesso a dados privada satisfaz as quatro. Um serviço com três endpoints públicos que também deixa outros serviços consultarem seu Postgres diretamente não satisfaz nenhuma.

Onde as fronteiras são traçadas errado

O erro mais comum é traçar fronteiras em torno de tecnologia em vez de em torno de mudança. 'A camada de API', 'a camada de banco', 'a camada de UI'. Essas são fronteiras entre tipos de código, não entre tipos de decisão. Uma mudança em como descontos funcionam vai passar pelas três camadas, então as camadas não protegem nada.

O segundo erro é traçá-las em torno do organograma do momento. Uma fronteira que existe porque dois times não queriam conversar em 2023 ainda vai estar lá em 2028, quando esses times já tiverem se fundido, separado e fundido de novo.

O terceiro é traçá-las cedo demais. Uma fronteira é uma aposta de que duas coisas vão mudar de forma independente. Se você ainda não sabe como o domínio se move, está chutando. Prefiro manter duas coisas juntas por seis meses e separá-las com evidência do que separá-las no primeiro dia e passar um ano construindo pontes de volta.

A pergunta que faço para gerentes de produto

Quando um gerente de produto me traz uma funcionalidade, faço uma pergunta antes de estimar qualquer coisa: quais fronteiras isso atravessa? Se vive dentro de uma só, é barato e seguro. Se atravessa duas, precisa de mudança de contrato e deploy coordenado. Se atravessa quatro, a funcionalidade na verdade é uma mudança de arquitetura vestida de funcionalidade, e deveria ser precificada como tal.

Essa pergunta muda conversas. O pessoal de produto não é burro. Quando eles enxergam que 'adicionar cupom de desconto no checkout' passa por precificação, carrinho, pagamentos e relatórios, começam a perguntar se as fronteiras estão no lugar certo. É exatamente a conversa que um arquiteto deveria querer.

Trace as linhas de propósito. Escreva por que cada uma está ali. Revisite quando o motivo desaparecer. Todo o resto do código é substituível. As linhas são o que você está construindo de verdade.