Consumidor
O time que depende de um comportamento. Precisa de uma verificação que falha quando esse comportamento muda, sem chamar o outro serviço.
Software com um limite que a entrega verifica.
Desenhamos e construímos aplicações, APIs e o limite entre times. Uma mudança deve falhar no build quando a promessa se altera, sem chamar o outro sistema.
O limite, desenhado.
Consumidor, promessa, provedor. O meio é o que o build pode cobrar.
Contrato
A promessa numa forma que os dois lados versionam. REST, GraphQL ou um evento. A forma segue a restrição.
Provedor
O time dono do comportamento. Vê a quebra no próprio build, antes de uma jornada descobrir.
Um limite desenhado para a explicação.
O que deixamos.
A oferta é o limite e a verificação. Pact, OpenAPI e um registro de esquema são exemplos de como uma promessa pode ser mantida. Não são o serviço.
Um limite com nome
Quem é dono de cada lado, e quais mudanças podem atravessar.
Uma verificação no build
A promessa falha localmente e no CI, com dados semeados em vez de uma dependência viva.
Um time que consegue estender
A primeira versão não é uma ferramenta particular de um especialista. O próximo contrato é de vocês.
A borda do trabalho.
Dita antes de uma proposta, para o trabalho ter forma.
Vamos
Desenhar o limite, as verificações e o caminho até o CI para o time conseguir manter.
Podemos
Construir a primeira versão ao lado dos seus engenheiros, depois que o desenho estiver combinado.
Não vamos
Tratar uma migração de framework como estratégia, nem alocar um time que vocês não pretendem liderar.
Perguntas que esperamos.
Isto é só dublês de teste?
Não. A página é sobre limites que dá para mudar sem uma dependência viva em cada verificação.
Vocês constroem o produto inteiro?
Entrega de ponta a ponta é uma forma de trabalho. Consultoria embarcada é outra. A primeira conversa escolhe qual.
Nomeie a dependência que você está esperando.
Essa fila costuma ser um contrato que falta. Confirmamos isso numa conversa curta.