Arquitetura Hexagonal soa abstrata até você sentir a dor que ela resolve: mudar de banco de dados, trocar um serviço de e-mail ou testar uma regra de negócio sem precisar subir a aplicação inteira. No Simulado Solidário, essa separação entre domínio e infraestrutura é o que sustenta a plataforma crescendo sem virar um emaranhado.
Portas e adaptadores, sem jargão
Na prática, isso significa que a regra "como calcular o ranking de um aluno" não sabe nada sobre MySQL, fila ou e-mail. Ela recebe dados, aplica a lógica, devolve um resultado. Quem conversa com o banco, com a fila ou com o serviço de e-mail é um adaptador — uma peça que pode ser trocada sem tocar na regra de negócio.
Uma porta, nesse contexto, é apenas uma interface: um contrato que diz "eu preciso de algo que salve um aluno", sem especificar como. O adaptador é quem implementa esse contrato de fato, seja usando Eloquent, uma API externa ou um arquivo local. Essa indireção parece burocracia à primeira vista, mas é exatamente o que permite trocar de fornecedor de e-mail, por exemplo, sem tocar em uma linha da regra que decide quando o e-mail deve ser enviado.
O que isso muda no dia a dia
O ganho real aparece na manutenção: consigo testar a lógica de domínio sem banco de dados, trocar um serviço de terceiros sem quebrar regra de negócio, e entender rapidamente onde uma mudança deve entrar. Não é arquitetura por estética — é arquitetura para eu continuar entregando rápido depois que o projeto já não é mais pequeno.
Como isso se conecta com DDD
Arquitetura Hexagonal e DDD andam juntos na minha rotina: o DDD define como organizar o domínio, a Arquitetura Hexagonal define como esse domínio se comunica com o mundo externo. Se você ainda não decidiu quando vale a pena aplicar essas ideias, escrevi sobre isso em Por que escolho DDD mesmo em projetos pequenos — e sobre como esses princípios se conectam com SOLID em SOLID aplicado em Laravel.
