Arquitetura do Lender

O Lender é um serviço só. Dentro dele, cinco domínios cuidam da jornada de crédito, um perfil de jurisdição fornece cada regra específica de mercado, e o dinheiro chega ao ledger por uma fila durável em vez de uma chamada inline.

​

Cinco domínios, um serviço

---

Cada domínio possui as próprias tabelas e as próprias operações. O identificador da conta de empréstimo é a chave que junta os domínios. O Lender não gera esse identificador. Você fornece o identificador no desembolso, e cada domínio endereça o empréstimo por ele daí em diante.

​

O encaixe da jurisdição

---

As regras de crédito mudam conforme o mercado, então nenhum domínio nomeia um mercado. Tudo que é específico de mercado chega por um perfil de jurisdição, que fornece um conjunto fixo de capacidades:

• O motor de tributos que calcula retenções no desembolso e tributos sobre receita na apropriação.
• O calendário de feriados e a convenção de contagem de dias.
• O método de custo efetivo por trás da divulgação de custo.
• O registro de tetos que guarda os limites regulados de taxa e de tarifa.
• As divulgações que o mercado exige.
• O pipeline de desembolso que roda dentro da transação de desembolso.
• O validador de produto e a extensão de prévia do cronograma.
• As políticas de ator que decidem quem pode aprovar e quem pode desembolsar.

Os perfis são compilados no serviço em vez de configurados em runtime. Dois vêm hoje: BR para o Brasil e XX, uma base genérica sem tributos e sem tetos. A tabela de jurisdições no banco de dados é uma projeção do que o serviço carrega, então nenhuma chamada de API cria uma jurisdição. Veja Jurisdições.

​

Como uma requisição é resolvida

---

Cada requisição passa pelos mesmos três controles antes de um handler rodar. Vincule cada tenant a uma jurisdição antes de ele mandar tráfego. O Lender recusa uma requisição de um tenant sem vínculo.

​

O dinheiro sai pelo outbox

---

O Lender nunca lança no ledger durante a sua requisição. O caminho tem quatro propriedades:

1. Um desembolso, uma apropriação de juros e uma cotação brasileira de pagamento antecipado liquidada gravam, cada um, uma intenção de lançamento na mesma transação de banco de dados da linha de negócio. Uma queda entre as duas coisas não é possível.
2. Um dispatcher lê a intenção no outbox e a repassa ao Midaz.
3. Cada intenção carrega uma chave de idempotência determinística, então um repasse repetido colapsa em uma transação só no ledger.
4. O roteamento falha fechado. Um lançamento é contabilizado na organização e no ledger que o perfil contábil resolve, e um deploy single-tenant pode recorrer ao padrão configurado dele. Quando nenhum destino é resolvido, o Lender não lança nada.

Configure o endpoint do ledger e as credenciais dele antes de esperar contabilizações. Enquanto eles não resolvem, as intenções esperam no outbox e nada chega ao ledger. O Lender na plataforma cobre o caminho completo, incluindo o que o perfil contábil acrescenta a ele.

​

O que o serviço expõe

---

Leia a referência de health e readiness para o contrato de probe compartilhado entre os produtos Lerian.

​

Armazenamentos

---

Configuração e deploy lista os ajustes por trás de cada um.

​

Trabalho disparado por tempo

---

Nem tudo começa com uma requisição. A rodada de apropriação também roda como job agendado. Cada job fica desligado até você habilitar, e você define o agendamento dele. Veja Contabilidade e rodadas de apropriação.

​

Próximos passos

---