Pular para o conteúdo
thiagoetipadrões

Contatos

apps/service-design/microkernel

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

Microkernel (Arquitetura de Plugins)

Um núcleo mínimo só registra plugins e despacha cada requisição aos que declaram tratar aquele tipo; toda regra de negócio mora nos plugins. Tipo novo é plugin novo, e o núcleo não muda — aberto para extensão, fechado para modificação. Use em motores com modalidades que crescem com o tempo, como meios de pagamento, regras de compliance ou cálculo de tarifa por produto.

passos
6
arquivos
4
testes
0
tecnologias
5
Infraestrutura realTypeScriptBunElysiaPostgreSQLDocker
CenárioRelaçõesComparar
Baixar cartão

Cenário

O banco processa PIX (até R$ 5.000,00 por transação), TED (só na janela das 6h às 17h, tarifa de R$ 10,90) e boleto (linha de 47 dígitos, tarifa de R$ 3,50). Depois, o produto lança pagamentos em Drex: o time escreve um plugin e registra — o núcleo, os plugins de PIX, TED e boleto e a liquidação continuam intocados.

Planta

Fluxo
10/10
POST /payments/:typeKernelPaymentregistro e despachoamount-validation *pixtedboletodrexregistrado depoissettlement *grava paymentsaudit *nao criticoPostgreSQLvalidatevalidatevalidatevalidatevalidatesettleobserve
10

10 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Núcleo mínimo estendido por plugins.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

settle+2
validate+1
if+1
  1. 01

    Cada plugin declara nome, versão, fase (validate, settle, observe), os tipos que trata (ou *) e se é crítico

  2. 02

    O núcleo filtra os plugins do tipo pedido e os executa por fase e, dentro da fase, na ordem de registro — sem nenhum if por tipo

  3. 03

    Tipo sem plugin próprio é recusadoPlugins * sozinhos não tornam um tipo válido

  4. 04

    Plugin crítico que falha interrompe o pagamento antes da liquidação; plugin não crítico (auditoria) vira aviso e o pagamento segue

  5. 05

    Os plugins só conversam pelo contexto compartilhado (result, errors), nunca chamando uns aos outros

  6. 06

    settlement grava o pagamento e audit o rastro no PostgreSQL; o núcleo não guarda nada

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Núcleo estável, tipo novo sem tocar no que existe

  • Plugins testados e versionados isoladamente

  • Crítico e não crítico separados por declaração

  • Fase explícita independe da ordem de registro

Custos

  • Contexto compartilhado cria acoplamento implícito entre plugins

  • Só o registro diz quais plugins estão ativos

  • Descobrir em qual plugin falhou exige o rastro do contexto

  • Despacho a cada requisição custa em altíssimo volume

apps/service-design/microkernel

4 arquivos

src/

  • kernel_payment.tsO núcleo: contrato do plugin, registro, fases e despacho
  • plugin_payment.tsOs plugins: validação, PIX, TED, boleto, liquidação e auditoria
  • api_payment.tsComposição dos plugins e a API HTTP

sql/

  • 01_schema.sqlschemaTabelas escritas pelos plugins de liquidação e auditoria

Executar · com Docker

  1. ./docker.sh up# sobe PostgreSQL
  2. cp .env.example .env# variáveis de ambiente
  3. bun install# dependências
  4. bun run demo# roda o cenário
  5. bun run test# integração contra o serviço real
Requisitos
BunDocker
Sobe junto
PostgreSQL

Relações

Onde ele se encaixa

Mapa
  1. Microkernel
  • Combina com3

Por que se relacionam

Combina com

Teste rápido

Qual destes combina com Microkernel?

Próximo projeto · Padrões de Design de ServiçoCoreografia vs Orquestração
Esc

↑ ↓ navegarEnter abrir191 resultados