Integrar um ERP de vinte anos sem tocar nele
A camada anticorrupção deixa sistemas novos falarem com um ERP intocável sem herdar o modelo de dados dele. O que entra nela e como mantê-la fina.
Existe uma categoria de sistema que ninguém tem permissão de mudar. O ERP que roda desde 2005. O motor de agendamento cujo autor saiu em 2013. O sistema de sinistros que é certificado, e recertificar custa mais do que o projeto que você está tentando fazer.
Ainda assim você precisa integrar com ele. A pergunta é como fazer isso sem que o sistema novo herde trinta anos de decisões de modelagem acumuladas.
O que é, de fato, uma camada anticorrupção
O termo vem do design orientado a domínio, e é mais literal do que parece. A camada existe para impedir que o modelo de um sistema corrompa o do outro.
Concretamente: uma fronteira de tradução que fala a língua do sistema legado de um lado e a língua do seu domínio do outro. Nada do seu lado da fronteira sabe que CUST_STAT_CD existe, que 9 significa ativo, ou que um cliente sem linhas em CUST_ADDR é um registro provisório e não um cliente de verdade.
O que pertence a ela
A camada se paga absorvendo cinco tipos específicos de feiura. Se não estiver fazendo pelo menos três deles, é um salto inútil.
| Preocupação | Pertence à camada | Exemplo |
|---|---|---|
| Vocabulário | Sim | CUST_STAT_CD 9 vira status: ativo |
| Formato | Sim | Seis tabelas planas viram um Cliente com lista de endereços |
| Semântica ausente | Sim | Data-fim nula significa em aberto, não desconhecida |
| Protocolo de acesso | Sim | SOAP, arquivo posicional ou leitura de réplica |
| Limites de taxa e lote | Sim | O ERP aceita 5 requisições por segundo antes de degradar |
| Regra de negócio | Não | Elegibilidade de desconto é do seu domínio, não da fronteira |
| Política de cache dos consumidores | Não | Cada consumidor sabe do que precisa em termos de frescor |
As duas últimas linhas são onde essas camadas dão errado. Assim que regra de negócio começa a pousar na fronteira de tradução, ela deixa de ser fronteira e vira uma segunda aplicação da qual ninguém é dono.
Leitura é fácil; a escrita decide o desenho
Ler de um sistema intocável é sobretudo um problema de dados. Escrever nele é um problema de consistência, e é o que conduz o desenho inteiro.
Três opções, em ordem crescente do que custam:
Escrever pela interface do próprio ERP. Se ele expõe uma API ou um formato de importação, use e aceite a validação dele. Sua camada traduz e encaminha. É a única opção que mantém o ERP como fonte única da verdade, que é quase sempre o que você quer.
Escrever numa fila que o ERP drena. Quando o ERP só ingere em lote, você aceita consistência eventual e a torna explícita. O sistema novo precisa conseguir mostrar um estado pendente, e o usuário precisa entender que "salvo" não é "lançado". Isso é decisão de produto, não só técnica.
Escrever direto nas tabelas dele. Às vezes é a única opção. Trate como último recurso, com uma lista escrita de cada restrição e gatilho que você está contornando, porque agora você é responsável por invariantes que a aplicação garantia.
Mantendo-a fina
Camadas anticorrupção crescem. Cada consumidor que precisa de mais um campo, cada caso de borda, cada "já que estamos aqui" acrescenta uma linha. Depois de dois anos a camada é maior do que o serviço que ela deveria proteger.
Três hábitos a mantêm pequena:
- Uma camada por sistema legado, não por consumidor. Várias camadas de tradução sobre o mesmo ERP significam várias interpretações do mesmo campo, e elas vão divergir.
- A camada não tem banco de dados. No momento em que guarda estado, vira fonte da verdade e deixa de ser tradução. Cache tudo bem; cache com caminho de escrita próprio, não.
- Campo novo exige consumidor nomeado. "Vai que a gente precisa" é como uma tradução de 40 campos vira uma de 300.
Quando você não precisa de uma
Se o sistema legado já expõe uma API limpa e bem modelada, embrulhá-la acrescenta um salto e um deploy sem benefício. Chame direto.
Se você está substituindo o sistema legado em vez de integrar com ele, a camada ainda pode valer, porque ela vira a fachada de uma migração em fatias. Mas aí é um artefato de migração com data de aposentadoria, e deve ser planejada assim.
E se a "integração" é na verdade automação de tela porque não existe interface alguma, o território é outro: veja RPA ou integração por API.
Boa parte do que fazemos em modernização é isso. Se o sistema guarda dado regulado, as regras de acesso das nossas práticas de segurança valem para a camada como para qualquer outra coisa.