Nesta página
Duas empresas clientes têm um campo chamado “ativo”. Para uma, significa que a pessoa comprou algo no último ano. Para a outra, que o contrato de serviço está em vigor. Um conector compartilhado pode mover os dois campos corretamente. Uma regra compartilhada que trate ambos como o mesmo estado comercial pode estar errada para uma das empresas. É um exemplo ilustrativo, não um relato de implantação.
Uma discussão sobre plataformas compartilhadas e implantação local descreve uma empresa reutilizando grande parte da infraestrutura enquanto ainda realiza trabalho considerável no ambiente de cada cliente. Seus percentuais são específicos daquela empresa. A pergunta geral de arquitetura é onde a mecânica comum termina e começa o significado local.
Separe o contrato de transporte do contrato de negócio
Um contrato de transporte pode dizer: autenticar na origem, ler registros alterados, preservar identificadores, repetir com segurança e expor falhas. Esses comportamentos podem ser implementados uma vez e testados repetidamente. São valiosos porque toda integração precisa de um caminho confiável para os dados.
Um contrato de negócio diz qual registro é oficial, o que um status significa, quando uma ação é permitida e quem pode corrigir um erro.
- Transporte comum identidade · repetição · ID
entrega evento válido
- Política local significado · consentimento · tempo
decide se a ação é permitida
- Ação autorizada gravação · auditoria
registra o resultado
Esse contrato de negócio depende do fluxo. Pode usar a mesma origem e o mesmo destino de outro cliente e ainda exigir uma resposta diferente.
Considere uma conexão entre loja e e-mail. A plataforma pode oferecer recebimento de eventos, eliminação de duplicatas e trilha de auditoria. Quem controla o fluxo deve definir se “inscrito” representa permissão para uma finalidade específica de marketing, se uma compra suprime lembrete de carrinho e como uma mudança de consentimento afeta mensagens já programadas. Essas regras não são recursos do conector que se possam adivinhar pelos nomes dos campos.
O mapeamento ilustrado do Tajo copia três campos diretamente. Falta uma decisão: nenhuma linha define a permissão para marketing. Reutilizar o transporte poupa trabalho, mas quem responde pelo fluxo ainda precisa definir qual status permite cada ação. Um mapeamento claro revela essa lacuna sem resolvê-la.
Revise uma sincronização antes de executá-la
Sincronize as atualizações de clientes com minha plataforma de email.
Sincronização de clientes
| Campo de origem | Campo de destino | Regra |
|---|---|---|
email | EMAIL | Direta |
first_name | FIRSTNAME | Direta |
last_name | LASTNAME | Direta |
Prévia sintética aprovada
3 campos mapeados · Nenhuma gravação no destino
Layout ilustrativo baseado nas ferramentas de mapeamento do Tajo. Uma prévia sintética e um rascunho salvo não ativam a sincronização.
| Camada compartilhada | Camada local |
|---|---|
| Autenticação e renovação de token | Qual identidade pode acessar este fluxo |
| Transporte de eventos e novas tentativas | Qual evento conta como mudança de estado comercial |
| Identificadores estáveis e deduplicação | Quais registros representam o mesmo cliente real |
| Logs e pontos de recuperação | Quem resolve um estado contestado e como |
| Validação de contrato | O significado dos valores e quando podem gerar ação |
A tabela marca um limite de projeto, não afirma que toda implementação pode ser dividida com tanta limpeza.
O reuso falha quando esconde divergências
Uma plataforma genérica costuma ganhar um campo de configuração para cada exceção. No início, isso parece preservar o reuso. Depois, ninguém sabe dizer se uma opção é técnica, jurídica ou comercial. O núcleo compartilhado vira um controle remoto de decisões pelas quais não responde.
Procure uma propriedade estável. “Nunca aplicar o mesmo evento de origem duas vezes ao mesmo registro de destino” pode morar num mecanismo comum. “Enviar desconto quando o cliente ficar ativo” não pode ser compartilhado antes que “ativo”, o público permitido e a política da oferta tenham responsáveis. O mecanismo pode executar uma política aprovada, mas não inventá-la.
Isso também ajuda na manutenção. Se a API mudar, a equipe da plataforma atualiza o adaptador e seus testes. Se a definição de cliente elegível mudar, quem responde pelo negócio atualiza a política e os exemplos de teste sem esperar a reescrita do transporte. Um limite claro leva cada mudança a quem tem autoridade sobre ela.
Reutilize a mecânica sem achatar o significado
Algumas regras locais acrescentam custo. Uma plataforma sem contrato reutilizável vira uma coleção de scripts sob medida. A resposta é identificar mecanismos repetidos antes de abstrair significados repetidos. Um componente comum bem projetado pode receber um predicado tipado, horário do evento e limite de ação, deixando local a definição comercial do predicado.
Teste o limite com casos reais. Pegue um evento normal, uma duplicata, uma correção tardia e uma permissão revogada. Pergunte qual camada responde por cada reação. Se não for possível atribuir uma falha, a abstração esconde responsabilidade. Se um novo cliente obriga o enum compartilhado “ativo” a acumular interpretações sem relação, o tipo comum é amplo demais.
O artigo complementar sobre implantação examina se uma capacidade funciona dentro do fluxo real. Este pergunta o que pode ser construído uma vez sem apagar o significado do fluxo.
A interface entre camadas deve ser explícita o bastante para rejeitar uma suposição ruim. Um mecanismo comum pode exigir ID de evento, horário de origem, ator e finalidade declarada antes de aceitar um pedido de ação. O fluxo local fornece a política que decide se a ação é permitida. Sem finalidade, o mecanismo deve recusar o pedido; se a política for ambígua, quem controla o fluxo deve resolver a questão. É uma forma prática de preservar reuso sem entregar autoridade comercial ao código genérico. Documente o contrato com um exemplo aceito e outro rejeitado e teste os dois quando qualquer camada mudar.
Um conector reutilizável deve facilitar a expressão do significado local e sua execução segura. Nunca deve fazer duas promessas diferentes parecerem iguais só porque os campos têm o mesmo nome.
Perguntas frequentes
O que uma plataforma de integração geralmente deve reutilizar?
Mecânicas estáveis, como padrões de autenticação, transporte, aplicação única de eventos, novas tentativas, logs e verificação de contratos, podem ser compartilhadas quando os requisitos subjacentes coincidem.
O que deve continuar específico a cada negócio?
O significado dos campos, a autoridade da origem, as regras de consentimento, as exigências de tempo e quem pode agir com base num status devem ser definidos para aquele negócio e fluxo.
Como as equipes podem testar o limite?
Tente expressar um novo fluxo usando componentes existentes. Se isso mudar o significado comercial ou esconder exceções numa configuração genérica, mantenha a lógica local e torne a interface explícita.