SOLID em MuleSoft: o que vem do design orientado a objetos e o que não se encaixa

Quase toda aplicação Mule começa pequena e organizada. Um ano depois, a mesma aplicação tem um flow de 60 passos que valida, transforma, chama três sistemas e envia um e-mail, e ninguém quer mexer nele antes de um release. Os princípios SOLID foram criados para evitar exatamente esse tipo de degradação em código orientado a objetos. A pergunta para quem trabalha com integração é quanto desse conselho sobrevive à troca de classes por flows, contratos de API e adaptadores.

Esta série responde com código que roda. Cada artigo tem uma versão antes e uma depois no repositório mulesoft-solid-examples, uma aplicação Mule 4 com testes MUnit que comprovam o que o texto afirma. Nada depende de sistemas externos: ERPs e meios de pagamento são simulados, então basta clonar e rodar mvn clean test.

De onde vem o SOLID

Robert C. Martin descreveu os princípios no artigo Design Principles and Design Patterns, de 2000, e Michael Feathers depois os organizou no acrônimo SOLID. Dois deles são mais antigos que o acrônimo: Bertrand Meyer formulou o Princípio Aberto/Fechado em 1988, e a ideia de substituição de Barbara Liskov vem da palestra Data Abstraction and Hierarchy, de 1987.

Os cinco foram escritos para linguagens orientadas a objetos, em que a unidade de design é a classe e a unidade de reuso é a interface. O Mule não tem nenhuma das duas. Ele tem flows, sub-flows, configuração, DataWeave, especificações de API e os sistemas por trás delas. Por isso cada princípio precisa ser traduzido antes de ser útil, e a tradução não funciona igualmente bem para os cinco.

Quanto cada princípio se encaixa

Princípio	O que vira no Mule	Encaixe
Responsabilidade Única	Flows e sub-flows agrupados pelo motivo de mudança	Forte — quase direto
Aberto/Fechado	Novo comportamento por configuração e novos flows, sem editar o roteador	Parcial — útil, com custos reais
Substituição de Liskov	Várias implementações (adaptadores, system APIs) respeitando um contrato	Forte, quando se deixa de procurar herança
Segregação de Interfaces	Um contrato de API por tipo de consumidor	Forte no nível de API, fraco dentro da aplicação
Inversão de Dependência	Flows de negócio donos de um modelo canônico que os adaptadores implementam	Forte — é para isso que existe a conectividade API-led

Os artigos deixam as lacunas explícitas. O Aberto/Fechado, por exemplo, leva a roteamento dinâmico, que o Anypoint Studio não consegue validar e que o MUnit só aceita com um contorno. Esse custo faz parte da lição.

O que cada artigo traz

O princípio na forma original, em uma ou duas frases.
O que ele significa numa aplicação Mule e onde a analogia se quebra.
Um exemplo antes e depois tirado do repositório, em sintaxe válida do Mule 4.
O teste MUnit que mostra a diferença.
Um checklist curto de revisão.

Rodando os exemplos

git clone https://github.com/brunosouzas/mulesoft-solid-examples.git
cd mulesoft-solid-examples
mvn clean test

O MUnit roda no runtime Enterprise do Mule, então o Maven precisa das credenciais do repositório Enterprise da MuleSoft no ~/.m2/settings.xml, como em qualquer projeto MuleSoft. Para chamar os endpoints, importe o projeto no Anypoint Studio, rode a aplicação e use as requisições do requests.http.

Esta série substitui a versão de 2025, que não tinha código executável e continha erros que os exemplos revelaram.