Pular para o conteúdo

apps/architecture/soa

036 · Arquiteturas de Alto Nível (Macro-Architecture) · ≈ 6 min de estudo

SOA (Arquitetura Orientada a Serviços)

Serviços corporativos com contrato explícito conversam por um barramento (ESB). O ESB faz a mediação: recebe dos canais num modelo canônico, orquestra os serviços e traduz para o formato de cada um — inclusive o de um core bancário legado. Use em empresas com sistemas heterogêneos, legados e muitos canais que precisam consumir as mesmas capacidades.

passos
6
arquivos
6
testes
0
tecnologias
6
Infraestrutura realTypeScriptBunElysiaPostgreSQLRabbitMQDocker
Baixar cartão

Cenário

Banco com três canais e dois serviços corporativos: compliance, em JSON, e o core bancário, um sistema legado que só entende layout de largura fixa. Os canais enviam uma transferência no modelo canônico ao ESB; nenhum canal conhece o core nem o formato dele. Quando o core para, os canais recebem 504 no prazo, sem ficar pendurados.

Planta

Sequência
10/10
POST /v1/transfers (modelo canonico)1compliance.transfer.validate.v1 (replyTo, correlationId)2requisicao3aprovado4transforma JSON em linha de 62 posicoes5corebanking.transfer.execute.v16TRF...7debito, credito, lancamento idempotente8OK0000 A123... (33 posicoes)9201 aprovado10Canal (app, internet banking, agencia)ESB (HTTP para AMQP)RabbitMQ soa.busServico de compliance (JSON)Core bancario legado (largura fixa)PostgreSQL do core
10

10 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Serviços corporativos integrados por barramento.

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    O ESB expõe POST /v1/transfers e valida o modelo canônico (schemaTransferCanonical) antes de chamar qualquer serviço

  2. 02

    Cada chamada vira mensagem na exchange soa.bus com a versão do contrato na chave (compliance.transfer.validate.v1); a resposta volta pela fila exclusiva do ESB com o mesmo correlationId

  3. 03

    O serviço composto "transferência" consulta a compliance primeiro; só o aprovado chega ao core

  4. 04

    O ESB traduz o JSON para a linha de 62 posições do core e a resposta de 33 posições de volta; o core aplica cada operationId uma vez no próprio PostgreSQL

  5. 05

    mandatory faz a chave sem serviço ligado voltar na hora (502); expiration e o timeout fazem o serviço calado custar exatamente o prazo (504)

  6. 06

    Requisição que o serviço não consegue processar é rejeitada sem reentrega infinita

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Canais e serviços desacoplados por contrato versionado

  • Legado integrado sem expor o formato dele

  • Serviço composto reutilizado por todos os canais

  • Falha de serviço vira resposta no prazo, não espera infinita

Custos

  • O ESB concentra lógica e vira gargalo e ponto central de falha

  • Toda chamada paga o salto pelo barramento

  • Governança de contratos pesada entre times

  • Lógica de negócio tende a escorregar para o ESB

apps/architecture/soa

6 arquivos

src/

  • esb_soa.tsESB: mediação HTTP → AMQP, orquestração e tradução
  • bus_soa.tsRequest-reply no RabbitMQ com timeout, mandatory e expiration
  • contract_soa.tsModelo canônico e chaves de contrato versionadas
  • format_legacy.tsLayout de largura fixa do core legado
  • service_compliance.tsServiço de compliance
  • service_core_banking.tsCore bancário legado com o ledger no PostgreSQL

Executar · com Docker

  1. docker compose up -d --wait# sobe PostgreSQL · RabbitMQ
  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
PostgreSQLRabbitMQ

Por que se relacionam

Teste rápido

Qual destes combina com SOA?

Próximo projeto · Arquiteturas de Alto Nível (Macro-Architecture)Serverless / FaaS
Esc

↑ ↓ navegarEnter abrir191 resultados