Proposta de Arquitetura Baseada em Domínios¶

1. Visão Geral¶

Esta proposta adota os princípios de Domain-Driven Design (DDD) e arquitetura de microsserviços para o ConectaFAPES. Cada domínio identificado no discovery torna-se um serviço independente, com seu próprio modelo de dados, API e ciclo de deploy.

O objetivo é alinhar os limites técnicos (bounded contexts) aos limites de negócio, garantindo autonomia de times, escalabilidade seletiva e conformidade regulatória por domínio.

2. Domínios → Serviços¶

Serviço	Domínio	Fase Principal	Responsabilidade Central
`grantor-service`	Grantor	Pré-Award / Award	Publicação de editais (FOA/RFP), avaliação, parametrização de modalidades e programas
`grantee-service`	Grantee Institution / Grantee	Award / Pós-Award	Gestão de instituições receptoras e coordenadores de projeto
`subrecipient-service`	Subrecipient	Pós-Award	Gestão de bolsistas, subawards e obrigações de equipe auxiliar
`financial-service`	Financial Management	Award / Pós-Award	Execução orçamentária, desembolsos e prestação de contas
`payments-service`	Payments	Pós-Award	Folha de bolsistas, controle de acúmulo e histórico de pagamentos
`compliance-service`	Compliance	Todas	Auditoria, relatórios regulatórios e regras de conformidade (TCU/CGE)
`identity-service`	IAM (Grantor)	Transversal	Autenticação via Acesso Cidadão (PRODEST) e autorização (AuthN/AuthZ)

3. Diagrama de Arquitetura¶

graph TB
    subgraph Portais de Acesso
        GP[Grantor Portal\nFAPES Admin]
        AP[Applicant Portal\nPesquisadores / Bolsistas]
    end

    subgraph API Gateway
        GW[API Gateway + PEP\nRoteamento / AuthZ]
    end

    subgraph Serviços de Domínio
        GR[grantor-service\nEditais · Avaliação · Programas]
        GE[grantee-service\nInstituições · Coordenadores]
        SR[subrecipient-service\nBolsistas · Subawards]
        FM[financial-service\nOrçamento · Prestação de Contas]
        PM[payments-service\nFolha · Desembolsos]
        CO[compliance-service\nAuditoria · Relatórios]
        ID[identity-service\nIAM · Acesso Cidadão]
    end

    subgraph Infraestrutura Compartilhada
        EB[Event Bus\nDomainEvents]
        DB1[(grantor-db)]
        DB2[(grantee-db)]
        DB3[(subrecipient-db)]
        DB4[(financial-db)]
        DB5[(payments-db)]
        DB6[(compliance-db)]
    end

    GP --> GW
    AP --> GW
    GW --> ID
    GW --> GR
    GW --> GE
    GW --> SR
    GW --> FM
    GW --> PM
    GW --> CO

    GR --> DB1
    GE --> DB2
    SR --> DB3
    FM --> DB4
    PM --> DB5
    CO --> DB6

    GR -- AwardCreated --> EB
    EB --> GE
    EB --> FM
    GE -- SubawardAllocated --> EB
    EB --> SR
    FM -- PaymentApproved --> EB
    EB --> PM
    PM -- PaymentExecuted --> EB
    EB --> CO

4. Princípios de Comunicação¶

4.1 Síncrona (REST/gRPC)¶

Usada para consultas e ações que exigem resposta imediata: - Portal → API Gateway → Serviço de domínio - identity-service é chamado sincronamente pelo Gateway em toda requisição

4.2 Assíncrona (Event Bus / Mensageria)¶

Usada para propagação de Domain Events entre serviços, garantindo desacoplamento total. Nenhum serviço chama diretamente outro via HTTP para comunicação orientada a eventos.

Evento	Produtor	Consumidores
`AwardCreated`	`grantor-service`	`grantee-service`, `financial-service`
`ProposalApproved`	`grantor-service`	`grantee-service`
`SubawardAllocated`	`grantee-service`	`subrecipient-service`
`BudgetReserved`	`financial-service`	`grantee-service`
`PaymentApproved`	`financial-service`	`payments-service`
`PaymentExecuted`	`payments-service`	`compliance-service`, `subrecipient-service`
`ReportSubmitted`	`grantee-service`	`compliance-service`
`ComplianceViolation`	`compliance-service`	`grantor-service`, `financial-service`
`UserSuspended`	`identity-service`	`grantor-service`, `grantee-service`, `payments-service`

4.3 Topologia de Mensageria Detalhada¶

Tecnologia: RabbitMQ com Exchanges por Domínio¶

Cada serviço publica em seu próprio topic exchange. Os consumidores criam queues com bindings específicos, garantindo que cada domínio processe apenas os eventos de seu interesse.

graph LR
    subgraph grantor-service
        G_PUB[Publisher]
    end
    subgraph grantee-service
        GE_PUB[Publisher]
        GE_SUB[Consumer]
    end
    subgraph financial-service
        FM_PUB[Publisher]
        FM_SUB[Consumer]
    end
    subgraph payments-service
        PM_PUB[Publisher]
        PM_SUB[Consumer]
    end
    subgraph subrecipient-service
        SR_SUB[Consumer]
    end
    subgraph compliance-service
        CO_SUB[Consumer]
    end

    subgraph RabbitMQ Exchanges
        EX_GR[exchange: grantor.events\ntopic]
        EX_GE[exchange: grantee.events\ntopic]
        EX_FM[exchange: financial.events\ntopic]
        EX_PM[exchange: payments.events\ntopic]
        EX_ID[exchange: identity.events\ntopic]
    end

    subgraph Queues
        Q1[queue: grantee.from-grantor]
        Q2[queue: financial.from-grantor]
        Q3[queue: subrecipient.from-grantee]
        Q4[queue: financial.from-grantee]
        Q5[queue: payments.from-financial]
        Q6[queue: compliance.from-payments]
        Q7[queue: compliance.from-grantee]
        Q8[queue: all.from-identity]
    end

    G_PUB --> EX_GR
    GE_PUB --> EX_GE
    FM_PUB --> EX_FM
    PM_PUB --> EX_PM

    EX_GR -->|award.#| Q1
    EX_GR -->|award.#| Q2
    EX_GE -->|subaward.#| Q3
    EX_GE -->|report.#| Q4
    EX_FM -->|payment.approved| Q5
    EX_PM -->|payment.executed| Q6
    EX_GE -->|report.submitted| Q7
    EX_ID -->|user.#| Q8

    Q1 --> GE_SUB
    Q2 --> FM_SUB
    Q3 --> SR_SUB
    Q5 --> PM_SUB
    Q6 --> CO_SUB
    Q7 --> CO_SUB

Convenção de Routing Keys¶

{dominio}.{agregado}.{evento}

Exemplos:
  grantor.award.created
  grantor.proposal.approved
  grantee.subaward.allocated
  grantee.report.submitted
  financial.payment.approved
  payments.payment.executed
  compliance.violation.detected
  identity.user.suspended

4.4 Envelope de Mensagem (Message Schema)¶

Todos os eventos seguem um envelope padronizado para garantir rastreabilidade e idempotência:

{
  "messageId": "uuid-v4",
  "correlationId": "uuid-v4",
  "eventType": "grantor.award.created",
  "occurredAt": "2026-03-01T21:00:00Z",
  "producedBy": "grantor-service",
  "version": "1.0",
  "payload": {
    "awardId": "AWARD-2026-0042",
    "granteeInstitutionId": "UFES-001",
    "coordinatorId": "USER-99",
    "totalAmount": 150000.00,
    "currency": "BRL",
    "startDate": "2026-04-01",
    "endDate": "2028-03-31"
  }
}

Campo	Obrigatório	Descrição
`messageId`	✅	ID único da mensagem (usado para idempotência)
`correlationId`	✅	ID da transação de negócio rastreável entre serviços
`eventType`	✅	Routing key no formato `dominio.agregado.evento`
`occurredAt`	✅	Timestamp UTC do evento de domínio
`producedBy`	✅	Serviço produtor
`version`	✅	Versão do schema do payload
`payload`	✅	Dados específicos do evento

4.5 Padrões de Confiabilidade¶

Outbox Pattern (Garantia de Entrega)¶

Cada serviço persiste o evento na própria base de dados antes de publicar no broker, eliminando o risco de perda em caso de falha:

sequenceDiagram
    participant App as grantor-service
    participant DB as grantor-db
    participant Relay as Outbox Relay
    participant MQ as RabbitMQ

    App->>DB: BEGIN TRANSACTION
    App->>DB: INSERT award (tabela awards)
    App->>DB: INSERT event (tabela outbox)
    App->>DB: COMMIT
    Relay-->>DB: Polling / CDC (a cada 1s)
    Relay->>MQ: Publish event
    Relay->>DB: Mark event as published

Idempotência no Consumidor¶

Todo consumidor verifica o messageId antes de processar: 1. Busca messageId na tabela processed_messages 2. Se já existe → descarta silenciosamente 3. Se não existe → processa e registra o messageId

Dead Letter Queue (DLQ)¶

Mensagens que falham após 3 tentativas com backoff exponencial (1s → 2s → 4s) são enviadas para a DLQ do domínio:

queue: {dominio}.dlq
Ex:  financial.dlq
     payments.dlq

Alertas automáticos são disparados via Grafana quando a DLQ acumula mensagens, notificando o time responsável.

4.6 Fluxo Completo: Award → Pagamento¶

Exemplo end-to-end mostrando a comunicação por mensageria:

sequenceDiagram
    actor Admin as FAPES Admin
    participant GR as grantor-service
    participant MQ as RabbitMQ
    participant GE as grantee-service
    participant FM as financial-service
    participant PM as payments-service
    participant CO as compliance-service

    Admin->>GR: Publica resultado do edital
    GR->>GR: Cria Award no banco
    GR->>MQ: grantor.award.created
    MQ-->>GE: Recebe AwardCreated
    GE->>GE: Cria projeto e vincula coordenador
    GE->>MQ: grantee.subaward.allocated
    MQ-->>FM: Recebe SubawardAllocated
    FM->>FM: Reserva orçamento
    FM->>MQ: financial.payment.approved
    MQ-->>PM: Recebe PaymentApproved
    PM->>PM: Executa desembolso na folha
    PM->>MQ: payments.payment.executed
    MQ-->>CO: Recebe PaymentExecuted
    CO->>CO: Registra trilha de auditoria

5. Alinhamento com o Ciclo de Vida do Grant¶

PRÉ-AWARD          │  AWARD                   │  PÓS-AWARD
───────────────────┼──────────────────────────┼──────────────────────────
grantor-service    │  grantor-service          │  financial-service
identity-service   │  grantee-service          │  payments-service
                   │  financial-service        │  subrecipient-service
                   │  identity-service         │  compliance-service
                   │                           │  identity-service

6. Autonomia de Times (Team Topology)¶

Time	Serviço(s)	Fase
Time Fomento	`grantor-service`	Pré-Award
Time Pesquisadores	`grantee-service` + `subrecipient-service`	Award / Pós-Award
Time Financeiro	`financial-service` + `payments-service`	Pós-Award
Time Governança	`compliance-service`	Todas
Time Plataforma	`identity-service` + API Gateway + Event Bus	Transversal

7. Stack Tecnológica Sugerida¶

Camada	Tecnologia
APIs	REST (OpenAPI 3.x) ou gRPC
Autenticação	Acesso Cidadão (PRODEST) + OAuth2/OIDC
Autorização	OpenFGA (RBAC/ReBAC)
Event Bus	RabbitMQ ou Kafka
Banco de Dados	PostgreSQL por serviço (isolamento total)
Observabilidade	OpenTelemetry + Grafana
Deploy	Kubernetes (por namespace de domínio)

8. Considerações de Evolução¶

Fase 1 (MVP): Iniciar com grantor-service + grantee-service + identity-service como monólito modular, separando gradualmente.
Fase 2: Extrair financial-service e payments-service à medida que o volume de transações crescer.
Fase 3: compliance-service dedicado para atender auditoria do TCU/CGE com trilhas de auditoria completas.

9. Garantia de Entrega e Observabilidade de Eventos¶

Como saber que um evento saiu? Chegou? Foi processado com sucesso?

9.1 Ciclo de Vida de um Evento¶

stateDiagram-v2
    [*] --> PENDING : Evento criado na outbox
    PENDING --> PUBLISHED : Relay publicou no broker
    PUBLISHED --> DELIVERED : Broker confirmou (ack)
    DELIVERED --> PROCESSING : Consumidor recebeu
    PROCESSING --> PROCESSED : Consumidor processou com sucesso
    PROCESSING --> FAILED : Erro no processamento
    FAILED --> PROCESSING : Retry (backoff exponencial)
    FAILED --> DEAD : Esgotou tentativas → DLQ
    DEAD --> [*] : Alerta + intervenção manual

Cada transição de estado é persistida na tabela outbox do serviço produtor e na tabela processed_messages do consumidor, formando uma trilha auditável completa.

9.2 Tabela Outbox (Produtor)¶

CREATE TABLE outbox (
    id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    message_id  UUID NOT NULL UNIQUE,          -- idempotência
    event_type  TEXT NOT NULL,                 -- ex: grantor.award.created
    payload     JSONB NOT NULL,
    status      TEXT NOT NULL DEFAULT 'PENDING', -- PENDING | PUBLISHED | DELIVERED
    created_at  TIMESTAMPTZ NOT NULL DEFAULT now(),
    published_at TIMESTAMPTZ,
    attempts    INT NOT NULL DEFAULT 0
);

9.3 Tabela Processed Messages (Consumidor)¶

CREATE TABLE processed_messages (
    message_id   UUID PRIMARY KEY,
    event_type   TEXT NOT NULL,
    processed_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    consumer     TEXT NOT NULL               -- ex: financial-service
);

Se message_id já existe → descarta silenciosamente (idempotência garantida).

9.3b Tabela Inbox (Consumidor — Serviços Críticos)¶

O inbox é o equivalente do outbox no lado do consumidor. Em vez de processar a mensagem diretamente ao receber do broker, o consumidor primeiro persiste na tabela inbox e só então processa. Isso elimina a janela de falha entre o ACK e o processamento.

Problema que resolve:

Sem inbox:
  Broker → Consumer recebe → ACK ✅ → 💥 CRASH → mensagem perdida para sempre

Com inbox:
  Broker → Consumer persiste na inbox (na mesma transação) → ACK ✅
  Worker interno lê da inbox → Processa → Marca como PROCESSED
  (Se crashar antes de processar, o worker reprocessa na próxima subida)

CREATE TABLE inbox (
    id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    message_id   UUID NOT NULL UNIQUE,          -- idempotência
    event_type   TEXT NOT NULL,
    payload      JSONB NOT NULL,
    status       TEXT NOT NULL DEFAULT 'RECEIVED', -- RECEIVED | PROCESSING | PROCESSED | FAILED
    received_at  TIMESTAMPTZ NOT NULL DEFAULT now(),
    processed_at TIMESTAMPTZ,
    attempts     INT NOT NULL DEFAULT 0
);

Fluxo com inbox:

sequenceDiagram
    participant MQ as RabbitMQ
    participant C as Consumer Handler
    participant DB as inbox (DB)
    participant W as Worker Interno

    MQ->>C: Entrega mensagem
    C->>DB: INSERT INTO inbox (RECEIVED)
    C->>MQ: ACK ✅
    W-->>DB: Polling inbox WHERE status = RECEIVED
    W->>W: Processa lógica de negócio
    W->>DB: UPDATE inbox SET status = PROCESSED

Quando usar cada abordagem:

Serviço	Padrão recomendado	Justificativa
`grantor-service`	`processed_messages`	Operações reversíveis
`grantee-service`	`processed_messages`	Operações reversíveis
`financial-service`	`inbox`	Reservas de orçamento são irreversíveis
`payments-service`	`inbox`	Pagamentos de bolsistas são críticos
`compliance-service`	`processed_messages`	Auditoria apenas (sem efeito financeiro)

O correlationId é criado no ponto de origem (ex: quando o Admin publica o edital) e propagado em todos os eventos subsequentes da mesma transação de negócio:

sequenceDiagram
    actor Admin
    participant GR as grantor-service
    participant GE as grantee-service
    participant FM as financial-service

    Admin->>GR: POST /awards  [correlationId: abc-123]
    GR->>GR: outbox: {correlationId: abc-123, event: AwardCreated}
    GR-->>GE: AwardCreated {correlationId: abc-123}
    GE->>GE: outbox: {correlationId: abc-123, event: SubawardAllocated}
    GE-->>FM: SubawardAllocated {correlationId: abc-123}

Com isso, qualquer log ou trace com correlationId: abc-123 no Grafana/Jaeger mostra toda a cadeia de eventos de ponta a ponta.

9.5 Dashboard de Observabilidade (Grafana)¶

Painel	Métrica	Alerta
Eventos publicados/min	`outbox.published_count`	—
Eventos pendentes (backlog)	`outbox{status=PENDING} > 5min`	🔴 Crítico
Taxa de falha por serviço	`processed_messages.failed_rate`	> 5% → 🟡 Warning
DLQ acumulada	`dlq.message_count > 0`	🔴 Crítico
Latência produtor → consumidor	`event.e2e_latency_ms`	> 30s → 🟡 Warning

9.6 Saga Pattern para Transações Distribuídas¶

Quando um fluxo envolve múltiplos serviços e pode falhar no meio, utiliza-se o padrão Choreography-based Saga com eventos compensatórios:

sequenceDiagram
    participant GR as grantor-service
    participant FM as financial-service
    participant PM as payments-service

    GR->>FM: AwardCreated (reservar orçamento)
    FM-->>GR: BudgetReserved ✅

    FM->>PM: PaymentApproved (executar pagamento)
    PM--xFM: ❌ Falha (conta bloqueada)

    PM->>FM: PaymentFailed (compensação)
    FM->>FM: Libera orçamento reservado
    FM->>GR: BudgetReleased (compensação)
    GR->>GR: Marca Award como suspenso

Evento Compensatório	Triggered por	Ação
`PaymentFailed`	`payments-service`	`financial-service` libera orçamento
`BudgetReleased`	`financial-service`	`grantor-service` suspende Award
`SubawardRevoked`	`grantee-service`	`subrecipient-service` encerra bolsista

10. Relação de Entidades Entre Domínios¶

Como um serviço referencia entidades de outro domínio sem criar acoplamento?

10.1 Princípio: Referência por ID, Não por Objeto¶

Cada domínio mantém apenas o ID canônico de entidades externas. Nunca importa o objeto completo de outro serviço — apenas o identificador globalmente único.

grantor-service → emite AwardId
grantee-service → armazena AwardId como referência
financial-service → armazena AwardId + GranteeId como referências
payments-service → armazena SubrecipiendId + AwardId como referências

10.2 Mapa de IDs Canônicos por Domínio¶

ID Canônico	Dono (Produtor)	Quem Referencia
`AwardId`	`grantor-service`	`grantee-service`, `financial-service`, `compliance-service`
`FoaId` (EditalId)	`grantor-service`	`grantee-service`
`GranteeInstitutionId`	`grantee-service`	`grantor-service` (read-only), `financial-service`
`ProjectId`	`grantee-service`	`subrecipient-service`, `financial-service`
`SubrecipiendId`	`subrecipient-service`	`payments-service`
`PaymentOrderId`	`financial-service`	`payments-service`, `compliance-service`
`UserId`	`identity-service`	Todos os serviços

10.3 Local Cache / Read Model¶

Quando um serviço precisa exibir dados de outro domínio (ex: nome do coordenador no relatório financeiro), ele mantém um read model local atualizado via eventos:

graph LR
    GE[grantee-service] -- "CoordinatorUpdated\n{userId, name, email}" --> MQ[RabbitMQ]
    MQ --> FM_RM[(financial-service\nread_model: coordinators)]
    MQ --> CO_RM[(compliance-service\nread_model: coordinators)]

O financial-service nunca chama a API do grantee-service para buscar o nome do coordenador. Ele lê do seu próprio read model, que é atualizado de forma assíncrona. Isso garante: - Autonomia de deploy (sem dependência em tempo de execução) - Resiliência (funciona mesmo se grantee-service estiver fora do ar) - Performance (leitura local, sem latência de rede extra)

10.4 Anti-Corruption Layer (ACL)¶

Quando dados externos precisam ser transformados para o modelo interno do domínio, usa-se uma camada de Anti-Corruption:

Evento externo recebido
        ↓
   ACL / Translator         ← Traduz para o modelo do domínio
        ↓
 Modelo interno do domínio
        ↓
    Lógica de negócio

Exemplo: financial-service recebe AwardCreated do grantor-service. O evento usa o modelo do Grantor. A ACL do Financial traduz para BudgetAllocationRequested, com os campos específicos do domínio financeiro.

10.5 Resumo: Regras de Ouro entre Domínios¶

✅ Permitido	❌ Proibido
Referenciar entidade externa por ID	Importar model class de outro serviço
Manter read model local via eventos	Chamar API de outro domínio para ler dado de suporte
Publicar evento com dados suficientes para consumidores	Fazer JOIN entre bancos de dados de domínios distintos
Usar ACL para traduzir eventos externos	Compartilhar banco de dados entre serviços
Saga com eventos compensatórios	Transação distribuída síncrona (2PC)

11. Portais e sua Relação com os Serviços¶

Os portais são frontends especializados por papel no ciclo de Grant Management. Cada portal se comunica exclusivamente com o API Gateway — nunca diretamente com os serviços de domínio.

11.1 Visão Geral dos Portais¶

Portal	Usuários	Fase Predominante
Grantor Portal	Servidores FAPES, gestores, revisores	Pré-Award + Award + supervisão Pós-Award
Grantee Portal	Instituições, coordenadores, bolsistas	Award + Pós-Award

11.2 Diagrama Completo: Portais → Gateway → Serviços¶

graph TB
    subgraph Grantor Portal
        GP1[Gestão de Editais]
        GP2[Avaliação de Propostas]
        GP3[Aprovação de Pagamentos]
        GP4[Relatórios e KPIs]
        GP5[Gestão de Usuários]
    end

    subgraph Grantee Portal
        AP1[Submissão de Propostas]
        AP2[Acompanhamento do Projeto]
        AP3[Gestão de Bolsistas]
        AP4[Prestação de Contas]
        AP5[Extrato de Pagamentos]
    end

    subgraph API Gateway + BFF
        GW[API Gateway\nAuthn · AuthZ · Rate Limit]
        BFF_G[BFF Grantor\nagrupa chamadas]
        BFF_A[BFF Grantee\nagrupa chamadas]
    end

    subgraph Serviços de Domínio
        GR[grantor-service]
        GE[grantee-service]
        SR[subrecipient-service]
        FM[financial-service]
        PM[payments-service]
        CO[compliance-service]
        ID[identity-service]
    end

    GP1 & GP2 & GP3 & GP4 & GP5 --> GW
    AP1 & AP2 & AP3 & AP4 & AP5 --> GW

    GW --> ID
    GW --> BFF_G
    GW --> BFF_A

    BFF_G --> GR
    BFF_G --> FM
    BFF_G --> CO
    BFF_G --> GE

    BFF_A --> GE
    BFF_A --> SR
    BFF_A --> PM
    BFF_A --> FM

11.3 Grantor Portal — Telas × Serviços¶

Tela / Funcionalidade	Serviços Chamados	Tipo
Login / Autenticação	`identity-service`	Síncrono
Criar / publicar Edital (FOA)	`grantor-service`	Síncrono
Listar propostas submetidas	`grantor-service`	Síncrono
Distribuir para revisores (Ad-Hoc)	`grantor-service`	Síncrono
Registrar parecer de mérito	`grantor-service`	Síncrono
Publicar resultado / gerar Award	`grantor-service` → evento `AwardCreated`	Síncrono + Evento
Dashboard financeiro do award	`financial-service` + `payments-service`	Síncrono (BFF agrega)
Aprovar pagamento em lote	`financial-service` → evento `PaymentApproved`	Síncrono + Evento
Relatório de conformidade	`compliance-service`	Síncrono
Suspender usuário inadimplente	`identity-service` → evento `UserSuspended`	Síncrono + Evento

11.4 Grantee Portal — Telas × Serviços¶

Tela / Funcionalidade	Serviços Chamados	Tipo
Login / Autenticação	`identity-service`	Síncrono
Submeter proposta	`grantor-service`	Síncrono
Acompanhar status da proposta	`grantor-service`	Síncrono
Visualizar Award e termos	`grantee-service`	Síncrono
Alocar bolsistas (subaward)	`grantee-service` → evento `SubawardAllocated`	Síncrono + Evento
Gerenciar equipe (bolsistas)	`subrecipient-service`	Síncrono
Extrato de pagamentos do bolsista	`payments-service`	Síncrono
Submeter relatório de progresso	`grantee-service` → evento `ReportSubmitted`	Síncrono + Evento
Prestação de contas financeira	`financial-service`	Síncrono
Histórico de auditoria	`compliance-service` (read-only)	Síncrono

11.5 Padrão BFF (Backend for Frontend)¶

Cada portal tem seu próprio BFF responsável por: - Agregar chamadas a múltiplos serviços em uma única resposta - Adaptar o payload para o formato exato que a tela consome - Evitar que o frontend faça múltiplas chamadas para montar uma tela

Exemplo — Tela "Dashboard do Award" no Grantor Portal:

sequenceDiagram
    participant GP as Grantor Portal
    participant BFF as BFF Grantor
    participant GR as grantor-service
    participant FM as financial-service
    participant PM as payments-service

    GP->>BFF: GET /dashboard/award/{awardId}
    BFF->>GR: GET /awards/{awardId}
    BFF->>FM: GET /budgets/{awardId}
    BFF->>PM: GET /payments/summary/{awardId}
    BFF-->>GP: Resposta consolidada em um único JSON

Sem BFF, o Grantor Portal precisaria fazer 3 chamadas separadas e montar os dados no frontend. Com BFF, 1 chamada retorna tudo pronto.

11.6 Autorização por Portal¶

O identity-service (AuthZ via OpenFGA) garante que cada usuário acessa apenas o que lhe é permitido:

Perfil	Portal	Permissões
Servidor FAPES	Grantor Portal	CRUD editais, aprovação, relatórios
Revisor Ad-Hoc	Grantor Portal	Read-only propostas + submeter parecer
Coordenador	Grantee Portal	Gerenciar projeto, alocar bolsistas, submeter relatório
Bolsista	Grantee Portal	Read-only: próprio extrato de pagamentos
Gestor Institucional	Grantee Portal	Visão agregada de todos os projetos da instituição

12. Feature List por Portal (baseado nos Backlogs de Domínio)¶

12.1 Grantor Portal¶

Portal usado por servidores FAPES, gestores de programa e revisores. Concentra as funcionalidades dos domínios Grantor, Grantee Institution, Financial Management, Payments e Compliance.

🏛️ IAM / Gestão de Acesso (`grantor-service`)¶

Feature	Domínio Origem
Login via Acesso Cidadão (PRODEST)	Grantor
Cadastro automático de perfil (back-office)	Grantor
Sincronização com organograma estadual	Grantor
Suspender perfil de usuário inadimplente	Grantor

📋 Parâmetros e Configurações (`grantor-service`)¶

Feature	Domínio Origem
Cadastrar Área Técnica	Grantor
Cadastrar Cidades e Regiões	Grantor
Cadastrar Áreas de Conhecimento (CNPq/CAPES)	Grantor
Cadastrar Modalidade de Fomento	Grantor
Cadastrar Nível de Bolsa (Mestrado, Doutorado, PQ)	Grantor
Atualizar tabela de valores de bolsas	Grantor
Cadastrar Resoluções e base legal	Grantor
Cadastrar Requisitos de Elegibilidade	Grantor

🗂️ Planejamento Estratégico e Programas (`grantor-service`)¶

Feature	Domínio Origem
Cadastrar Plano Estratégico (quadrienal)	Grantor
Cadastrar Eixo Estratégico	Grantor
Registrar Objetivos Estratégicos	Grantor
Configurar Indicadores de Impacto	Grantor
Cadastrar Programa de Fomento	Grantor
Associar Programa a Eixo Estratégico	Grantor
Cadastrar Comitê Gestor	Grantor
Adicionar Recursos Financeiros ao Programa	Grantor
Visualizar volume de propostas por programa	Grantor

📢 Gestão de Editais / Capitação (`grantor-service`)¶

Feature	Domínio Origem
Criar e configurar Edital (FOA/RFP)	Grantor
Gerir Templates dinâmicos de formulário	Grantor
Configurar etapas, datas e critérios de pontuação	Grantor
Instanciar / abrir Edital para submissões	Grantor
Associar Edital ao Programa	Grantor
Associar regras e documento oficial (FOA)	Grantor
Cadastrar e gerir Revisores Ad-Hoc	Grantor
Gerir filas de review e prazos	Grantor
Sugestão automática de avaliadores (Lattes keywords)	Grantor
Realizar Avaliação de Habilitação documental	Grantor
Realizar Avaliação de Mérito	Grantor
Avaliar qualidade dos pareceres dos revisores	Grantor
Publicar resultado (aprovados e suplentes)	Grantor
Receber e gerir recursos administrativos	Grantor
Gerar Award Agreement automaticamente	Grantor
Mudar status da proposta para "Contratada"	Grantor
Cadastrar Review Panels (Câmaras de Assessoramento)	Grantor
Vincular membros e histórico dos Panels	Grantor
Emitir certificados de participação em painéis	Grantor

🏢 Gestão de Instituições Beneficiárias (`grantee-service`)¶

Feature	Domínio Origem
Cadastrar Grantee Institution (Universidade / Empresa)	Grantee Institution
Cadastrar Unidades e Subunidades	Grantee Institution
Cadastrar Reitor e Responsáveis Legais	Grantee Institution
Vincular Responsável Legal à instituição	Grantee Institution
Portal executivo para Reitores/Diretores	Grantee Institution

💰 Gestão Financeira (`financial-service`)¶

Feature	Domínio Origem
Cadastrar Contas Contábeis (rubricas)	Financial Management
Associar Contas Contábeis a Editais/Convênios	Financial Management
Cadastrar Management Units (UGs)	Financial Management
Cadastrar Fontes de Recurso (Tesouro, FUNCITEC)	Financial Management
Cadastrar Subcontas	Financial Management
Cadastrar Saldo Inicial por subconta	Financial Management
Cadastrar Allocation Plans (cronograma de desembolso)	Financial Management
Definir divisão e tetos de gastos por modalidade	Financial Management
Relatório de Fluxo de Caixa	Financial Management
Monitoramento de Saldo em tempo real (Orçado × Empenhado × Pago)	Financial Management

💳 Pagamentos e Folha (`payments-service`)¶

Feature	Domínio Origem
Gerir Marcos de Pagamento (milestones)	Payments
Aprovar parcelas antes do envio ao banco	Payments
Execução de pagamento de parcelas	Payments
Emissão de Guias de autorização de saque	Payments
Geração automática da Folha mensal de bolsistas	Payments
Indexação de gastos de bolsas por edital	Payments
Alertas antecipados de prazos de vigência	Payments
Monitorar status da folha no processamento bancário	Payments
Integração @-EDI com Banestes e Bandes	Payments
Verificação automática de adimplência (SEFAZ/RFB)	Payments
Bloqueio automático por certidão vencida	Payments

🔍 Compliance e Auditoria (`compliance-service`)¶

Feature	Domínio Origem
BI simplificado para tomada de decisão	Compliance
Análise de Resultados (metas × alcançado)	Compliance
Dashboard do Programa (execução financeira pública)	Compliance
Dashboard de Iniciativas (mapa de calor)	Compliance
Dashboard Unitário de saúde financeira do grant	Compliance
Analisar Prestação de Contas	Compliance
Geração de Relatórios para TCU/SIGEF	Compliance
Rule Engine (bloqueio de remanejamentos proibidos)	Compliance
Detecção de Plágio em propostas e relatórios	Compliance
Verificador de Overlap / acúmulo de bolsas	Compliance
Validação automática de certidões	Compliance
Serviço de Importação de dados legados (SIGFAPES)	Compliance

12.2 Grantee Portal¶

Portal usado por coordenadores de projeto (Grantee), bolsistas (Subrecipient) e gestores institucionais. Concentra as funcionalidades dos domínios Grantee, Subrecipient, Payments e leitura do Compliance.

🔐 Acesso e Perfil (`identity-service`)¶

Feature	Domínio Origem
Login via Acesso Cidadão (PRODEST)	Grantor / IAM
Cadastro automático no primeiro login (front-office)	Grantor / IAM
Atualização de dados cadastrais e Lattes	Grantee
Alternar idioma da interface	Grantee
Ajuda contextual e base de conhecimento	Grantee

📝 Pré-Award — Submissão de Proposta (`grantor-service`)¶

Feature	Domínio Origem
Submeter Proposal (técnica + orçamento + cronograma)	Grantee
Upload de anexos com labeling por categoria	Grantee
Alertas e validação em tempo real do formulário	Grantee
Acompanhar status da proposta submetida	Grantee
Visualizar resultado da avaliação	Grantee

📂 Post-Award — Gestão da Iniciativa (`grantee-service`)¶

Feature	Domínio Origem
Overview das Iniciativas (dashboard central)	Grantee
Assinar Award Agreement (assinatura digital)	Grantee
Abrir conta do projeto (integração Banestes)	Grantee
Timeline visual do workflow do projeto	Grantee
Alerta automático ao atingir 60% de execução	Grantee
Solicitar mudanças em metas, prazos ou equipe	Grantee
Submeter resultados (artigos, protótipos, relatórios)	Grantee
Solicitar Suspensão do Projeto	Grantee
Cancelar Suspensão	Grantee
Solicitar Finalização do Projeto	Grantee
Cancelar Finalização	Grantee

💰 Gestão Financeira do Projeto (`financial-service` + `grantee-service`)¶

Feature	Domínio Origem
Solicitar adição orçamentária	Grantee
Solicitar nova Conta Contábil (rubrica)	Grantee
Solicitar Remanejamento de Orçamento	Grantee
Leitura automática de extrato bancário	Grantee
Submeter Reporting (prestação de contas)	Grantee
Contestar Reporting (recurso contra glosas)	Grantee
Assinatura digital de documentos financeiros	Grantee
Solicitar Pagamento de parcela	Payments
Upload de evidências via mobile (fotos/vídeos)	Grantee

👥 Gestão de Equipe (`grantee-service` + `subrecipient-service`)¶

Feature	Domínio Origem
Solicitar Grant (indicar novo bolsista)	Grantee
Criar Plano de Trabalho individual por bolsista	Grantee
Remanejar tipo de bolsa dentro da equipe	Grantee
Cancelar solicitação de bolsa	Grantee
Suspender solicitação de bolsa	Grantee
Gerir Voluntários (sem remuneração FAPES)	Grantee
Gerir Administrador (delegar gestão orçamentária)	Grantee
Workflow simplificado para envio de frequências	Grantee
Notificações automáticas de aceite para novos membros	Grantee
Dashboard institucional (todos os projetos da IES)	Grantee Institution

🎓 Visão do Bolsista / Subrecipient (`subrecipient-service` + `payments-service`)¶

Feature	Domínio Origem
Submeter documentos pessoais e acadêmicos (implementação)	Subrecipient
Assinar Termos digitalmente	Subrecipient
Visualizar status da indicação pelo coordenador	Subrecipient
Visualizar datas e status de pagamentos mensais	Subrecipient
Histórico consolidado de Disbursements	Subrecipient
Emissão de Informe de Rendimentos (IR)	Subrecipient
Enviar Relatórios e Frequências mensais	Subrecipient
Visualizar Plano de Trabalho individual	Subrecipient
Assinatura digital do aceite da grant (onboarding)	Subrecipient
Instruções guiadas de contratação (onboarding)	Subrecipient
Ofício automático de abertura de conta bancária	Subrecipient

📊 Transparência e Auditoria (read-only, `compliance-service`)¶

Feature	Domínio Origem
Consultar histórico de auditoria do projeto	Compliance
Visualizar Dashboard Unitário do projeto	Compliance