OpenLedg

Como representar pessoas, empresas e iniciadores de pagamento com regras diferentes, sem misturar perfis cadastrais com saldos e lançamentos? Um iniciador não pode receber uma conta de liquidação, inclusive quando o vínculo é criado diretamente por SQL.

O recorte entregue é a fundação OLGP: domínio, persistência, migração e operação local. Os endpoints atuais são a identificação do serviço, /health/live e /health/ready. Não há endpoints de cadastro nem uma jornada de pagamentos disponível.

Domain concentra invariantes sem depender do EF Core. Application define contratos; Infrastructure implementa persistência com EF Core/Npgsql; Api compõe dependências e health checks no Kestrel.

O PostgreSQL separa perfis, metadados de segurança e roteamento em schemas. Guarda referências de contas em formato decimal para preservar os 128 bits. Saldos e lançamentos ficam fora desse modelo; a porta ILedgerAccountDirectory ainda não tem adaptador TigerBeetle implementado.

TPH reúne os tipos de participante em uma tabela e evita joins de herança. Em troca, existem colunas nulas por subtipo e novos tipos exigem migrações dos CHECKs. O ADR não assume ganho de desempenho sem medição.

Chaves estrangeiras compostas e CHECKs reforçam as invariantes fora da aplicação. O papel da API pode operar perfis e roteamento, mas não tem DDL nem acesso ao schema security; bootstrap e migração usam um papel separado.

Separar o futuro ledger dos dados cadastrais torna explícita a responsabilidade de cada armazenamento. A contrapartida é planejar idempotência e reconciliação: não existe transação distribuída implementada.

Os testes xUnit inspecionados cobrem UUIDv4, estados iniciais de conformidade, rejeição de contas para iniciadores, preservação de UInt128, configuração de webhooks e dependências entre camadas.

A suíte de integração usa PostgreSQL real para verificar migrações, persistência dos subtipos, idempotência única, rejeição de vínculos inválidos por SQL e privilégios do papel de execução. Nesta revisão editorial, o código dos testes foi conferido; a suíte .NET não foi executada.

Projeto em andamento, sem transferências, autenticação ativa, integração DICT, KYC/AML real ou execução de webhooks. CPF/CNPJ têm normalização e validação de formato, sem verificação cadastral ou de dígitos verificadores.

TigerBeetle está previsto como fonte do estado financeiro e aparece no ambiente local, mas a aplicação ainda não o consulta. O readiness verifica o PostgreSQL, não pagamentos ou disponibilidade do ledger. A réplica local em modo development não representa um cluster de produção.

Comece pelos ADRs e pelo modelo de participantes; compare SettlementRoute com os testes de restrições no banco. Os links abaixo fixam a revisão analisada.

Para explorar localmente, clone o repositório e use a revisão indicada. São necessários Docker com Compose v2+ e, para os testes no host, .NET SDK 10.0.300 ou posterior da linha 10.0. Copie .env.example para .env e configure senhas locais antes dos comandos. O guia do repositório detalha os testes de integração. Não há demo pública verificada.