Artigo

Por que recusei generalizar um sistema financeiro que funciona

O Receiva começou com uma operação. A próxima pergunta de arquitetura é como apoiar outra sem fazer o sistema atual pagar por abstrações que ainda não existem.

Journal de Engenharia
Publicado 3 min de leitura

A pergunta

Receiva começou como uma camada operacional para a GoldCash, uma operação de financiamento de motos com carteira real e requisitos reais de integridade financeira. Fomentis é a fonte financeira. Receiva adiciona contexto operacional: carteira, agenda, contatos, negociações, promessas de pagamento, próximas ações, histórico, safety gates e publicação controlada.

A próxima pergunta não é “como transformamos isso em um SaaS?”. É: como o Receiva pode apoiar outra operação sem quebrar o que já funciona para a GoldCash?

Estado atual verificado

Receiva é um produto operacional real, em desenvolvimento e uso ativos ao redor da operação atual. A direção presente inclui FOMENTIS_SYNC, mantendo os dados de origem rastreáveis, e visões operacionais que tornam acompanhamento e contexto financeiro mais fáceis de revisar.

UNICAR é o primeiro cliente ou operação externa em discovery. Sua planilha é evidência do produto para entender a operação, não o schema. Este registro não afirma que a UNICAR esteja em produção.

A decisão arquitetural

A decisão atual é manter dois conceitos distinguíveis:

  • FOMENTIS_SYNC: preservar a fonte existente e sua fronteira de reconciliação.
  • RECEIVA_NATIVE: um possível modo financeiro nativo e isolado para operações que precisarem dele.

O princípio é simples: não generalizar a GoldCash à força. Adaptadores específicos por cliente podem surgir quando a evidência exigir, enquanto a fonte financeira que funciona permanece protegida.

Segurança antes da abstração

A superfície de engenharia inclui proteção do golden master, controle de regressão, backups, disaster recovery, auditabilidade, trabalho de performance, publicação controlada e safety gates explícitos. Isso não são recursos decorativos de plataforma; são proteções para a integridade da operação financeira.

Por isso, event sourcing desnecessário e multi-tenancy prematuro também não são tratados como padrões obrigatórios. Uma capacidade futura pode ser descoberta e isolada sem transformar o produto atual em um exercício de abstração.

Discovery / direção futura

RECEIVA_NATIVE é uma direção de discovery, não um modo implementado. Fronteiras de adapters e suporte a outras operações são possibilidades em investigação. Multi-tenancy não é afirmado como implementado, e Receiva não é representado como uma plataforma SaaS madura.

Interpretação retrospectiva

A pergunta útil não é se a arquitetura consegue imaginar todo cliente futuro. É se o cliente atual será obrigado a pagar o custo de complexidade antes que esses clientes existam.

Essa é a tensão: um sistema financeiro que funciona precisa poder evoluir, mas não ao custo de esconder sua fonte de verdade, enfraquecer a recuperação ou dificultar a auditoria do comportamento operacional.

Publicado por

Juan Gomes

Parte de

NorthCore Journal

Publicado