A ponte construída por duas equipes
Uma ponte foi construída por duas equipes começando de margens opostas, que quase não se coordenaram. No meio, os dois lados não se encontraram no mesmo ponto — houve um degrau. O problema não foi de engenharia de concreto: foi de comunicação entre as equipes, e a ponte ficou com a cara exata dessa falta de conversa. Software é igual: a 'junta' entre dois módulos tem a qualidade da conversa entre os times que os fizeram.
Usar a lei a favor
Como a estrutura organizacional vai moldar o sistema de qualquer jeito, a escolha não é 'se' obedecer a Conway, e sim se você a deixa acontecer por acaso ou a usa de propósito.
O 'inverse Conway maneuver' inverte a ordem: em vez de desenhar a arquitetura e torcer para os times a seguirem, você molda os times na forma da arquitetura desejada — e ela emerge porque a comunicação agora a favorece.
É por isso que a organização de 'times por domínio' (cada time dono de um serviço, de ponta a ponta) tende a produzir microsserviços coesos, enquanto uma organização por camada técnica (um time de front, um de back, um de banco) tende a produzir um sistema fatiado por tecnologia, com toda feature atravessando três times. A arquitetura que você consegue sustentar é a que o seu organograma permite.
A lei também explica dores comuns que parecem técnicas e não são: a integração ruim entre dois serviços cujos times ficam em fusos e prioridades diferentes; o backend-for-frontend que nasce porque o time de mobile precisava de um contrato só seu; o módulo compartilhado que ninguém mantém direito porque não tem dono claro. Antes de reprojetar o código, vale perguntar se o problema não está no desenho dos times — porque, se estiver, o novo código vai reencontrar o mesmo degrau.
Como isso aparece na prática
A migração para microsserviços que virou monólito distribuído
Cenário
Um time único e monolítico dividiu o sistema em dez serviços, mas continuou trabalhando como um time só, com todos mexendo em tudo. Os serviços ficaram tão acoplados que um deploy exigia coordenar os dez.
Como o padrão entra
Antes de continuar a divisão técnica, a empresa reorganizou as pessoas em times donos de domínios específicos. As fronteiras de serviço passaram a coincidir com as fronteiras dos times.
Trade-off: A reorganização de pessoas foi lenta e politicamente cara. Em troca, os serviços passaram a poder ser desenvolvidos e implantados de forma independente — o que a divisão só de código nunca entregou.
A integração que só melhorou depois de um canal de conversa
Cenário
Dois módulos de áreas que reportavam a diretorias diferentes viviam com bugs na fronteira. Cada revisão de contrato virava uma negociação demorada entre chefias.
Como o padrão entra
Criou-se um contrato de API versionado e um ritual de sincronização entre as duas áreas. A qualidade da fronteira melhorou junto com a qualidade da comunicação.
Trade-off: Adicionou reuniões e um processo de contrato onde antes não havia. Em troca, a fronteira parou de ser a fonte crônica de incidentes — porque a conversa que faltava passou a existir.
Onde isto dá errado
Desenhar arquitetura ignorando o organograma
Decidir os módulos no quadro branco sem olhar como os times se comunicam é planejar contra a corrente. A estrutura de comunicação real vai moldar o sistema de qualquer forma, e o diagrama vira ficção.
Dividir o código sem dividir os times
Quebrar um monólito em serviços mantendo um time único que mexe em tudo produz um monólito distribuído: todo o acoplamento de antes, agora com latência de rede e deploys que precisam ser coordenados.
Tratar todo problema como organizacional
Conway explica muita coisa, mas não tudo. Usar a lei como desculpa para não resolver um acoplamento genuinamente técnico é fugir do problema em vez de enfrentá-lo.
A lei, e como usá-la a favor
// A Lei de Conway nao e sobre codigo — e sobre quem escreve o codigo.
//
// "Organizacoes desenham sistemas que copiam a estrutura de
// comunicacao da propria organizacao." — Melvin Conway, 1968
//
// 4 times -> 4 modulos que conversam como os 4 times conversam.
//
// Se o time de "pagamentos" e o de "pedidos" quase nao se falam,
// a integracao entre os modulos deles vai ser pobre e cheia de
// mal-entendidos — nao por incompetencia tecnica, por organograma.
// INVERSE CONWAY MANEUVER: em vez de brigar com a lei, use-a.
// Quer uma arquitetura de servicos independentes por dominio?
// Primeiro organize TIMES independentes por dominio.
// A arquitetura desejada emerge da estrutura social que a favorece.Quando usar × quando evitar
Use quando
3- Ao planejar migração para microsserviços ou grande reorganização.
- Quando integrações entre áreas quebram sem causa técnica clara.
- Ao montar ou dividir times, pensando na arquitetura resultante.
Evite quando
2- Como explicação única para todo problema de arquitetura.
- Em times pequenos e únicos, sem fronteiras sociais a refletir.
Testar o que ficou
3 armadilhas de Lei de Conway viram perguntas, com o nome do padrão escondido, misturadas com padrões parecidos.
Onde isto aparece de verdade
Você já usa isto, talvez sem saber o nome.
microsserviços por timeCada time dono de um serviço faz a arquitetura espelhar o organograma — Conway em ação, muitas vezes de propósito.o BFF que nasceu do time de mobileUm backend-for-frontend costuma existir porque há um time de mobile separado, não por uma necessidade puramente técnica.inverse Conway maneuverReorganizar os times de propósito para que a arquitetura desejada emerja é a Lei de Conway usada como alavanca.
O padrão em uma linha
Sem nome de domínio, sem cerimônia. Só a ideia.
// A arquitetura espelha a comunicação dos times.
// Fronteira de serviço ≈ fronteira de time.O que ele cobra
Nenhum salto a mais entre a chamada e o efeito.
- Ignorá-la faz a arquitetura desejada brigar com a comunicação real dos times, e a comunicação vence
- Aplicá-la de propósito exige reorganizar pessoas, que é mais lento e mais político do que mudar código
Não vale se: o sistema é construído por um time só e pequeno — sem várias fronteiras organizacionais, não há estrutura social a espelhar.
Onde isto aparece
Continue por aqui
- Arquitetura HexagonalIsola o domínio no centro e o conecta ao mundo externo por portas (interfaces) e adaptadores (implementações), tornando infraestrutura um detalhe plugável.
- SRP — Responsabilidade ÚnicaUm módulo deve ter apenas uma razão para mudar — ou seja, deve responder a um único interessado do negócio, e não acumular decisões que evoluem por motivos diferentes.