tally

a maior parte dos sistemas que movimentam dinheiro trata a razão como uma coluna balance e um UPDATE. isso funciona até parar de funcionar, e quando para, não existe registro do porquê.

tally assume a posição oposta: a razão é um log append-only de fatos econômicos imutáveis e auto-consistentes, e todo saldo é derivado dele. não é uma ideia nova, é como a contabilidade funciona desde que Pacioli a codificou em 1494. mas tem consequências de engenharia reais, e trabalhar essas consequências com cuidado é o ponto do projeto.

as perguntas interessantes são do tipo: o que acontece quando duas transações são postadas concorrentemente contra a mesma conta? onde exatamente um pagamento retentado pode se duplicar? o que “exactly once” realmente significa quando existe um broker no meio? como você detecta que sua razão e seu processador de pagamento divergiram silenciosamente?

o modelo de ownership, o sistema de tipos e o tratamento explícito de erro permitem codificar invariantes financeiras de forma que violá-las seja um erro de compilação, não um incidente em produção.

a política de lint do crate proíbe aritmética de ponto flutuante em todo o projeto e liga checagem de overflow em builds release. Money são valores exatos em unidades menores como i64 mais a moeda, com aritmética falível que expõe overflow e incompatibilidade de moeda em vez de arredondar ou converter implicitamente.

Currency é um enum fechado que carrega seu código ISO 4217 e a escala decimal, com todas as três escalas reais representadas: JPY = 0, USD/EUR/GBP/BRL = 2, KWD = 3.

vale ser explícito: hoje existe o módulo domain com o modelo financeiro puro, Currency e Money. mais nada. o repositório declara isso na primeira tela e não faz nenhuma alegação de estar pronto para produção.

o projeto é construído em fases, e uma fase não começa antes da anterior estar sólida: domínio (contas, lançamentos, transações, validação de partidas dobradas, testes de propriedade) → persistência (postgresql, níveis de isolamento, postagem concorrente, diário imutável) → api → idempotência → eventos (transactional outbox) → reconciliação → engenharia de produção → performance medida.

a razão de listar o roadmap aqui em vez de escondê-lo é a mesma razão pela qual ele está no readme: um projeto sobre corretude financeira que exagera o próprio estado já falhou na premissa.