Pular para o conteúdo

apps/service-design/chain-of-responsibility

163 · Padrões de Design de Serviço · ≈ 5 min de estudo

Chain of Responsibility

Cada etapa de uma decisão vira um handler que aprova e passa adiante ou rejeita e para a cadeia. Nenhum handler conhece a ordem nem os outros; a montagem fica num lugar só. Use em esteiras de aprovação e validação em que qualquer etapa pode barrar e as seguintes não devem rodar.

passos
6
arquivos
4
testes
0
tecnologias
3
Lógica puraTypeScriptBunElysia
Baixar cartão

Cenário

A fintech analisa propostas de crédito em quatro etapas: documentos (KYC), limite de cinco rendas mensais, score mínimo 600 no bureau e lista restritiva regulatória. As checagens locais vêm primeiro: proposta barrada nelas não gasta consulta ao bureau. Bureau fora do ar não vira "crédito negado" — é falha de infraestrutura.

Planta

Fluxo
9/9
Proposta de creditoHandlerKycdocumentosHandlerLimitate 5 rendasHandlerScorebureau, minimo 600HandlerCompliancebureau, lista restritivaAprovadaParada em kycParada em limitParada em scoreParada em complianceaprovadoaprovadoaprovadoaprovadorejeitarejeitarejeitarejeita
9

9 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Handlers passam adiante até um tratar.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

  1. 01

    AbstractHandlerChain guarda o próximo handler; handle() chama process() da etapa e, se aprovado, repassa ao próximo

  2. 02

    process() devolve undefined para aprovar ou o motivo da rejeição; a rejeição para a cadeia e informa stoppedAt e as etapas já vencidas

  3. 03

    chainCreditCreate é o único lugar que define a ordem: kyc → limit → score → compliance

  4. 04

    Score e compliance consultam o bureau por HTTP com timeout; bureau inacessível lança ErrorBureauUnavailable, nunca uma rejeição de negócio

  5. 05

    Os handlers não guardam estado entre propostas: tudo vem na CreditApplication

  6. 06

    Reordenar ou inserir etapa muda só a montagem; nenhum handler é alterado

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Etapa nova sem tocar nas existentes

  • Rejeição cedo evita o custo das etapas seguintes

  • Cada regra testável sozinha

  • Resultado diz onde parou e o que passou

Custos

  • Fluxo espalhado por várias classes

  • Ordem errada na montagem muda o resultado sem erro

  • Depuração exige saber onde a cadeia parou

  • Só serve para rejeição binária — transformação é pipes and filters

apps/service-design/chain-of-responsibility

4 arquivos

src/

  • handler_chain.tsMecânica da cadeia: próximo, parada na rejeição, etapas vencidas
  • handler_credit.tsAs quatro etapas e a montagem da cadeia de crédito
  • bureau_credit.tsBureau de crédito simulado em Elysia: score e lista restritiva
  • config_chain.tsURL, porta e timeout do bureau

Executar · só Bun

  1. bun install# dependências
  2. bun run demo# roda o cenário
  3. bun run test# testes unitários
Requisitos
Bun

Por que se relacionam

Teste rápido

Qual destes combina com Chain of Responsibility?

Próximo projeto · Padrões de Design de ServiçoSpecification
Esc

↑ ↓ navegarEnter abrir191 resultados