No episódio anterior, analisamos como a física da rede impõe limites severos à computação distribuída por meio de latências e leis de paralelismo. Contudo, existe uma força de atração invisível ainda mais poderosa que molda a arquitetura dos sistemas: a estrutura organizacional e os limites de comunicação das equipes que desenvolvem o software.

1. O que realmente define a arquitetura do seu sistema

A forma como as pessoas da empresa se comunicam molda o software antes mesmo de qualquer linha de código ser escrita. Quando a comunicação é difícil ou fragmentada, o sistema acaba ficando fragmentado também. Muitas empresas tentam resolver problemas de organização usando apenas tecnologia, e isso costuma dar errado.

2. Um exemplo realista

Uma empresa dividiu seu sistema em vários pedaços achando que isso aceleraria as entregas. Mas, como os times eram pequenos e precisavam conversar o tempo todo, eles passaram mais da metade do tempo só alinhando detalhes e resolvendo conflitos entre partes do sistema.

O resultado foi:

• produtividade menor;
• entregas mais lentas;
• estresse maior;
• necessidade de voltar atrás e unificar tudo novamente.

3. Por que isso acontece

Se a empresa tem poucos times que trabalham juntos o tempo todo, dividir o sistema em muitas partes só cria burocracia e atrito. O software acaba refletindo exatamente como as pessoas se organizam e se comunicam — como um espelho do organograma.

Quando a comunicação é fluida, o sistema tende a ser simples. Quando a comunicação é fragmentada, o sistema também fica fragmentado.

4. Como descobrir onde realmente faz sentido separar o sistema

Para saber onde dividir, observe o negócio:

• Onde o significado das palavras muda entre áreas diferentes? Por exemplo, a palavra "produto" significa coisas totalmente diferentes para o time de logística e para o time de faturamento.
• Quais informações sempre mudam juntas? Se dados precisam ser atualizados no mesmo instante, eles devem ficar no mesmo espaço.
• Quais áreas precisam conversar o tempo todo para fazer alterações? Se a conversa é constante, o código deve ser unificado.

Se duas áreas precisam mexer no mesmo código sempre que algo muda, elas devem continuar juntas no mesmo sistema.

5. O maior risco: separar fisicamente sem separar de verdade

O pior cenário é quando o sistema é dividido em várias partes, mas as regras continuam totalmente dependentes umas das outras. Isso cria um efeito dominó: mudar uma parte quebra várias outras, exigindo atualizações coordenadas e tirando toda a autonomia das equipes. Em vez de ganhar velocidade, a empresa ganha fragilidade.

6. Uma regra prática para não errar

Se a empresa tem menos de 25 a 30 desenvolvedores, manter um sistema unificado costuma ser a opção mais eficiente. Dividir demais só aumenta o custo de coordenação e diminui a velocidade de entrega.

7. Conclusão

O software sempre imita a forma como as pessoas trabalham juntas. Código é a sombra da conversa entre as pessoas. Antes de pensar em dividir sistemas, é preciso entender como o negócio funciona e como os times se comunicam.

"Código é apenas a sombra da conversa entre as pessoas. Não existe arquitetura de software melhor do que o organograma e a comunicação da sua própria empresa."

No próximo artigo, faremos um levantamento financeiro cru: quanto custa manter a infraestrutura de suporte a microsserviços na nuvem comparado a servidores monolíticos, e qual o peso mental (carga cognitiva) imposto à saúde da equipe? Nos vemos na Parte 4.

— Fim do Episódio 3. Continua no Artigo 04: “A Realidade Financeira e Operacional (FinOps & Carga Cognitiva)”.

Tags de compartilhamento:
#DomainDrivenDesign #ConwaysLaw #SoftwareArchitecture #ProductStrategy