A Redescoberta da Alopoiese

“Sistemas complexos funcionam quando se organizam ao redor de fronteiras, não de centros.” — Eric Evans

O Capítulo 1 mostrou que a decomposição em microsserviços resolveu a escala em software. Mas não disse por quê. Por que fronteiras bem traçadas funcionam? Por que o baixo acoplamento é essencial, por que a autonomia local escala melhor que o controle central, por que o distribuído resiste mais que o monolítico? A resposta não está na tecnologia; está nos princípios. E esses princípios foram articulados — em contextos completamente diferentes, por dois pensadores que provavelmente nunca se encontraram — por Eric Evans, em 2004, escrevendo sobre complexidade em software, e por Humberto Maturana, em 1970, escrevendo sobre sistemas vivos. Este capítulo mostra a convergência não-intencional entre eles, e por que ela importa para organizações.

Bounded Context: a Fronteira

No início dos anos 2000, a engenharia de software vivia uma crise silenciosa: o software funcionava tecnicamente, mas não resolvia o problema de negócio. O abismo estava entre quem conhecia o domínio e quem escrevia o código. Eric Evans propôs algo aparentemente modesto e, no fundo, filosófico: que ambos falassem a mesma língua — a linguagem ubíqua —, e que o software fosse escrito na linguagem do domínio, não na da tecnologia. Porque a complexidade real não mora na tecnologia; mora no domínio — nas regras, nas exceções, no conhecimento tácito do especialista. Capturada mal, o software pode ser tecnicamente perfeito e ainda assim inútil.

O conceito que mudou tudo foi o Bounded Context. Em sistemas grandes, a mesma palavra significa coisas diferentes: “cliente” em vendas não é “cliente” no suporte, nem no financeiro. A tentação é criar uma classe universal de “cliente” que sirva a todos — e o resultado é um monstro de cinquenta atributos que ninguém entende: um monólito disfarçado. Evans propôs o contrário: o Bounded Context é a fronteira semântica dentro da qual um modelo é consistente. Dentro dela, a linguagem é precisa e o time é autônomo; fora, outros contextos usam os mesmos termos a seu modo, e a integração se dá por interfaces explícitas. Três traços o definem: autonomia semântica — cada contexto é dono do seu modelo; fronteiras explícitas — não há acesso direto ao interior; e coerência interna — que emerge de dentro, não é imposta de fora. Cada microsserviço materializa um Bounded Context: modelo de dados próprio, API pública, lógica interna privada.

E a comunicação entre contextos se faz por contrato. Uma API define o que pode ser pedido e o que será devolvido, sem expor como é feito por dentro — separa o quê do como. Os eventos, assíncronos, não comandam: informam. Transformam o comando-e-controle em coordenação consensual — não “vendas comanda o financeiro”, mas “vendas informa; o financeiro decide”.

A Convergência com Maturana

Esses princípios — baixo acoplamento, alta coesão, autonomia local, isolamento de falhas — não são arbitrários; são facetas de um mesmo insight. E é aqui que a convergência se revela. Trinta e quatro anos antes de Evans, estudando sistemas vivos, Maturana chegara ao mesmo princípio sobre processamento: o exterior pode perturbar ou solicitar, mas não pode instruir como o interior processa. Em Maturana, é a clausura operacional — a luz atinge a retina, os neurônios processam segundo a estrutura própria, a rã salta ou não; a luz não diz como. Em Evans, é o encapsulamento — a requisição chega, o serviço processa segundo a própria lógica, devolve a resposta; a API não diz como.

A correspondência tem um limite, e ele é justamente o ponto deste livro. No sistema vivo, o processamento é dinâmico: a estrutura interna se reconstrói continuamente. No sistema técnico, é estático: a lógica é fixada de antemão. O princípio do processamento local inviolável é o mesmo; a natureza do processamento — dinâmica ou estática — é o que difere. A convergência não é coincidência: é evidência de princípios organizacionais operando em escalas distintas.

Ashby e o Gap Ontológico

Falta um terceiro pilar. Evans deu a fronteira; Maturana, a proteção do que está dentro; W. Ross Ashby deu a medida: só variedade absorve variedade. Um regulador precisa de pelo menos tantos estados possíveis quanto o sistema que pretende regular. Se o ambiente oferece cem situações e o componente tem dez respostas, as noventa restantes não somem — voltam como falhas, exceções, complexidade compensatória, tratadas por próteses externas que tentam fazer por fora o que o componente não faz por dentro.

Juntos, os três delimitam o problema inteiro: Evans diz onde um domínio termina; Maturana protege o que processa lá dentro; Ashby determina quanta variabilidade esse dentro precisa ter para sobreviver ao que está fora. E é exatamente aqui que se abre o gap que o livro persegue. O DDD e os microsserviços cuidaram da fronteira e da proteção — mas não da variabilidade interna. Cada microsserviço respeita o Bounded Context, encapsula a lógica, comunica-se por contrato; mas, por dentro, é determinístico, e não absorve variabilidade. A que o ambiente exige precisa ir para algum lugar — e vai para os padrões que o Capítulo 3 examinará: Circuit Breaker para as falhas que o componente não absorve, Saga para as transações que não resolve sozinho, Service Mesh para o que não relata, CQRS para os domínios que mistura. Cada um é, ao mesmo tempo, solução brilhante e prova de uma limitação — próteses para a rigidez interna, batizadas de boas práticas. Ashby previra: num mundo em mutação, o componente sem variedade interna empurra a complexidade para fora. Ela não desaparece; desloca-se de dentro do componente para a malha entre componentes.

Do Software às Organizações

Se os microsserviços materializam princípios desse alcance, aplicá-los a organizações deixa de ser analogia forçada e passa a ser usar princípios universais numa nova escala. Com uma distinção ontológica que não se pode perder: pessoas são autopoiéticas — vivas, indivisíveis —, enquanto microsserviços são alopoiéticos — mecânicos, descartáveis. Mas as pessoas operam domínios — funções, projetos, responsabilidades —, e esses domínios podem ser tratados como bounded contexts. Não se trata de mecanizar a pessoa; trata-se de estruturar o trabalho que ela faz. A confusão entre as duas coisas — entre você e seus domínios — é, como veremos, a raiz do burnout.

A convergência entre Evans e Maturana não é acidente; é evidência. O Domain-Driven Design funciona não por ser boa prática de programação, mas por capturar algo estrutural sobre como a complexidade se organiza. O Capítulo 3 examina quatro padrões que a engenharia criou para problemas reais de sistemas distribuídos — e em cada um encontraremos a mesma surpresa: a solução é também o sintoma. Mas devagar; primeiro, os padrões.

O exterior pode perturbar. Não pode instruir como o interior processa — e é isso que a rigidez esquece.