> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Arquitetura do Lender

> As partes que formam o Lender: oito domínios, o perfil de jurisdição que fornece cada regra de mercado, o pipeline de requisições e o outbox que leva dinheiro até o ledger.

O Lender é um serviço só. Dentro dele, oito 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.

## Oito domínios, um serviço

***

| Domínio | O que ele possui | Onde ele para |
| - | - | - |
| **Produtos** | Produtos de empréstimo, versões de produto, templates de encargo, tabelas de taxa flutuante. | Uma versão nunca muda. Termos novos são uma versão nova. |
| **Originação** | O ciclo de vida da proposta, e o cronograma que o desembolso produz. | Ele registra a intenção de contabilizar. Ele não grava no ledger. |
| **Gestão da carteira** | A conta de empréstimo ativa: versões do cronograma, pagamentos, pagamentos antecipados, reprogramações, correções. | Ele nunca edita o histórico. Uma correção é uma transação nova. |
| **Contabilidade** | Perfis contábeis, regras de lançamento, intenções de lançamento, rodadas de apropriação, referências de diário. | Ele monta lançamentos balanceados. O relay entrega esses lançamentos. |
| **Auditoria** | A trilha do que aconteceu com uma conta de empréstimo. | Apenas acréscimo. Nada reescreve um evento. |
| **Cessão** | Fundos, conjuntos de recebíveis cedidos a eles, os documentos e os fatos da cessão. | Ele registra fatos externos como evidência de cada etapa. |
| **Emissão** | Os instrumentos de crédito que evidenciam uma proposta. | Um instrumento evidencia uma proposta que já existe. |
| **Carteira** | O painel da carteira e as leituras de inadimplência. | Ele lê. Ele não muda uma conta de empréstimo. |

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. 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. Um perfil de jurisdição fornece capacidades específicas de mercado, entre elas:

* 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. Vêm dois: **BR** para o Brasil e **XX**, a base genérica, que não registra crédito. 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](https://docs.lerian.studio/pt/products/lender/jurisdictions.md).

## Como uma requisição é resolvida

***

Uma requisição passa por até três controles antes de um handler rodar.

**1. Autenticação**

O Lender espera um JWT bearer. As duas leituras de descoberta de jurisdição são as únicas operações públicas.

**2. Resolução do tenant**

O tenant nunca é um header, um campo de corpo ou um parâmetro de caminho, então um chamador não consegue escolher um tenant.

**3. Resolução da jurisdição**

O Lender lê os vínculos de jurisdição do tenant na chave de configuração em tempo de execução `lender.jurisdictions/tenant_bindings` e coloca o perfil correspondente no contexto da requisição. Um tenant que a chave não lista responde 403 em toda rota `/api/v1/br/*`.

Vincule cada tenant a uma jurisdição antes de ele mandar tráfego.

## O dinheiro sai pelo outbox

***

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

1. Um evento de dinheiro, como um desembolso, um pagamento ou uma apropriação de juros, grava 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](https://docs.lerian.studio/pt/products/lender/lender-in-the-platform.md) cobre o caminho completo, incluindo o que o perfil contábil acrescenta a ele.

## O que o serviço expõe

***

| Superfície | Objetivo |
| - | - |
| `/api/v1/...` | Toda a API do produto, descrita por um documento OpenAPI. |
| `/health`, `/readyz`, `/version` | Liveness, readiness das dependências e metadados de build. Os três respondem antes da autenticação. |
| `/api/v1/streaming/manifest` | O catálogo de eventos que este deploy publica. |
| `/api/v1/systemplane/...` | Administração da configuração em runtime. |

Leia a [referência de health e readiness](https://docs.lerian.studio/pt/reference/health-and-readiness.md) para o contrato de probe compartilhado entre os produtos Lerian.

## Armazenamentos

***

| Dependência | Papel |
| - | - |
| PostgreSQL | Cada tabela de domínio, e o outbox. Aplica-se um conjunto de migrations. |
| Valkey ou Redis | Registros de idempotência, cache e limitação de taxa. |
| RedPanda | Eventos de ciclo de vida. O serviço não inicia sem ele. |
| Midaz | O destino de cada lançamento e o CRM que guarda o registro de titular de cada tomador. |

[Configuração e deploy](https://docs.lerian.studio/pt/products/lender/configuration-and-deploy.md) lista os ajustes por trás de cada um.

## Trabalho disparado por tempo

***

A rodada de apropriação também roda como job agendado. Cada job tem o próprio padrão de ligado ou desligado e o próprio agendamento, e você pode sobrescrever os dois. Veja [Contabilidade e rodadas de apropriação](https://docs.lerian.studio/pt/products/lender/accounting-and-accrual-runs.md).

## Próximos passos

***

> [card] [Como funciona a originação](https://docs.lerian.studio/pt/products/lender/how-origination-works.md)
>
> Uma proposta de enviada até desembolsada, e a transação que faz o trabalho.

> [card] [Conceitos centrais](https://docs.lerian.studio/pt/products/lender/core-concepts.md)
>
> O vocabulário que o produto inteiro compartilha.

> [card] [O Lender na plataforma](https://docs.lerian.studio/pt/products/lender/lender-in-the-platform.md)
>
> O caminho de lançamento, o catálogo de eventos e o isolamento entre tenants.

> [card] [Configuração e deploy](https://docs.lerian.studio/pt/products/lender/configuration-and-deploy.md)
>
> Dependências, o container e os ajustes que moldam um deploy.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.