Pular para o conteúdo
thiagoetipadrões

Contatos

apps/service-design/specification-pattern

164 · Padrões de Design de Serviço · ≈ 6 min de estudo

Specification

Cada regra de negócio vira um objeto que responde isSatisfiedBy(candidato), e and, or e not — escritos uma vez na classe abstrata — combinam as regras em expressões. A mesma regra entra em produtos diferentes com limiares e combinações diferentes, sem if aninhado nem duplicação. Use quando regras de elegibilidade, antifraude ou segmentação se recombinam por contexto.

passos
6
arquivos
4
testes
0
tecnologias
4
Lógica puraTypeScriptBunElysiaStryker
CenárioRelaçõesComparar
Baixar cartão

Cenário

A fintech de crédito aprova empréstimo pessoal por perfil sólido (renda, endividamento, tempo de conta) ou, no lugar dele, por garantia; e oferece cartão de entrada só a clientes com menos de 3 meses de conta. Nos dois produtos a lista de restrição regulatória, consultada por HTTP, reprova quem estiver nela — nenhum caminho do or contorna essa checagem.

Planta

Fluxo
10/10
Renda minima R$ 3.000EDivida ate 40% da rendaConta com 6 meses ou maisEOUTem garantiaEFora da lista de restricaoEmprestimo pessoalWatchlist HTTPPOST /check
10

10 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Regras de negócio combináveis.

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    Cada regra é uma classe (SpecificationIncomeMin, SpecificationDebtToIncomeMax, SpecificationAccountAgeMin, SpecificationCollateralHas, SpecificationWatchlistClear) que só implementa isSatisfiedBy

  2. 02

    AbstractSpecificationComposite implementa and, or e not uma vez; os compostos também são specifications e se combinam em qualquer profundidade

  3. 03

    O produto é uma composiçãoO empréstimo usa perfil.or(garantia).and(watchlist); o cartão de entrada reusa renda com outro limiar e a idade de conta negada com not()

  4. 04

    A watchlist é o último and(): dentro do or() a garantia a contornaria — o teste mostra esse erro de composição

  5. 05

    Curto-circuitoand não avalia a direita se a esquerda falhou, então perfil reprovado não gasta chamada à watchlist

  6. 06

    Valores em centavos e razão em pontos-base comparada por multiplicação cruzada: o limite de 40% é exato, sem arredondamento; watchlist fora do ar lança erro, nunca aprova

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Regra reusada entre produtos só mudando limiar e combinação

  • Cada regra testável sozinha, na fronteira

  • Curto-circuito evita chamada remota desnecessária

  • Nova combinação sem mexer nas regras existentes

Custos

  • Uma classe por regra, mesmo as de uma linha

  • A ordem da composição carrega significado e engana quem lê rápido

  • Uma regra assíncrona torna a árvore inteira assíncrona

  • Não diz qual regra reprovou — para isso, Chain of Responsibility

apps/service-design/specification-pattern

4 arquivos

src/

  • specification.tsInterface, classe abstrata e os combinadores and, or, not com curto-circuito
  • specification_credit.tsAs regras de crédito, uma por classe
  • eligibility_credit.tsAs composições por produto: empréstimo pessoal e cartão de entrada
  • watchlist_compliance.tsWatchlist HTTP e o cliente que a regra de compliance usa

Executar · só Bun

  1. bun install# dependências
  2. bun run demo# roda o cenário
  3. bun run test# testes unitários
  4. bun run test:mutation# mutação com Stryker
Requisitos
Bun

Relações

Onde ele se encaixa

Mapa
  1. Specification Pattern
  • Combina com3

Por que se relacionam

Combina com

Teste rápido

Qual destes combina com Specification Pattern?

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

↑ ↓ navegarEnter abrir191 resultados