Macro Domain Proposal¶

1. Objetivo¶

Este documento apresenta uma proposta de macro-organizacao de dominios e capacidades para o ConectaFAPES em contexto de:

implantacao inicial aderente ao ambiente institucional
evolucao para produto SaaS multi-tenant
suporte futuro a white-label
necessidade de reduzir acoplamento entre times e entre schemas

O objetivo aqui nao e fechar arquitetura tecnica detalhada.

O objetivo e oferecer uma visao macro, visual e explicada para que um grupo multi-skill consiga:

entender a proposta
comparar com o discovery
discutir limites de responsabilidade
decidir se a organizacao e adequada para seguir para a proxima etapa

Ela deve ser lida como proposta candidata para avaliacao, e nao como estrutura definitiva.

2. Leitura da proposta¶

Esta proposta separa tres camadas:

control plane saas: operacao do produto enquanto servico
capacidades compartilhadas de plataforma: servicos transversais reutilizaveis
dominios de negocio do grant management: partes centrais do problema mapeado no discovery

Essa separacao e importante para evitar tres confusoes frequentes:

portal com dominio
plataforma com regra de negocio
modulo tecnico com ownership do problema

3. Fluxograma proposto¶

flowchart TB
  classDef business fill:#e8f0fe,stroke:#1a73e8,color:#111827,stroke-width:1px;
  classDef platform fill:#e6f7ee,stroke:#14804a,color:#0f172a,stroke-width:1px;
  classDef control fill:#0b4aa2,stroke:#08346f,color:#ffffff,stroke-width:1px;
  classDef item fill:#ffffff,stroke:#cbd5e1,color:#0f172a,stroke-width:1px;

  CP[SaaS Control Plane]:::control

  subgraph D1[Tenancy and Commercial]
    T1[Tenant lifecycle]:::item
    T2[Isolation per tenant]:::item
    T3[Entitlements plans modules features]:::item
    T4[White-label branding]:::item
    T5[Partners and resellers]:::item
  end
  class D1 platform;

  subgraph D2[Identity Access and Trust]
    I1[SSO federation OIDC SAML per tenant]:::item
    I2[Authorization RBAC ABAC]:::item
    I3[Audit trails]:::item
    I4[Secrets and keys per tenant]:::item
  end
  class D2 platform;

  subgraph D3[Shared Platform Capabilities]
    P1[Workflow and approvals]:::item
    P2[Forms and templates]:::item
    P3[Document management]:::item
    P4[Notifications]:::item
    P5[Integration hub APIs ETL webhooks]:::item
    P6[Master data and reference data]:::item
    P7[People and organization registry]:::item
    P8[Policy and configuration per tenant]:::item
  end
  class D3 platform;

  subgraph D4[Strategy Governance and Portfolio]
    S1[Strategic plan axes goals]:::item
    S2[Programs committees macro budget]:::item
    S3[Institutional governance and approvals]:::item
    S4[Portfolio dashboards and risk]:::item
  end
  class D4 business;

  subgraph D5[Planning and Funding Opportunities]
    A1[Calls campaigns opportunities]:::item
    A2[Eligibility rules and criteria]:::item
    A3[Publication and calendar]:::item
  end
  class D5 business;

  subgraph D6[Proposal Submission and Selection]
    B1[Submissions and evidence intake]:::item
    B2[Validation and habilitation]:::item
    B3[Review and selection]:::item
    B4[Results and appeals]:::item
  end
  class D6 business;

  subgraph D7[Award Formalization]
    F1[Term generation and contracting]:::item
    F2[Institutional and individual acceptance]:::item
    F3[Pending documents and conditions]:::item
    F4[Activation of the award]:::item
  end
  class D7 business;

  subgraph D8[Project Execution and Deliverables]
    E1[Grant or project administration]:::item
    E2[Deliverables outcomes milestones]:::item
    E3[Team roles scholars volunteers]:::item
    E4[Amendments extensions changes]:::item
    E5[Suspension closeout]:::item
  end
  class D8 business;

  subgraph D9[Finance and Disbursements]
    N1[Budgets rubrics and lines]:::item
    N2[Disbursements]:::item
    N3[Scholarships stipends benefits]:::item
    N4[Accounting mapping]:::item
    N5[Banking integration reconciliation]:::item
  end
  class D9 business;

  subgraph D10[Accountability Compliance and Audit]
    C1[Financial reporting and accountability]:::item
    C2[Document verification findings]:::item
    C3[Audit evidence support]:::item
    C4[Transparency and regulatory outputs]:::item
  end
  class D10 business;

  subgraph D11[Data and Intelligence]
    J1[Operational dashboards]:::item
    J2[Analytics KPIs impact]:::item
    J3[Data exports marts per tenant]:::item
  end
  class D11 platform;

  CP --> D1
  CP --> D2
  CP --> D3
  CP --> D11

  D4 --> D5
  D5 --> D6
  D6 --> D7
  D7 --> D8
  D7 --> D9
  D8 --> D9
  D8 --> D10
  D9 --> D10

  D2 --> D5
  D2 --> D6
  D2 --> D7
  D2 --> D8
  D2 --> D9
  D2 --> D10

  D3 --> D5
  D3 --> D6
  D3 --> D7
  D3 --> D8
  D3 --> D9
  D3 --> D10

  D11 --> D4
  D11 --> D5
  D11 --> D6
  D11 --> D7
  D11 --> D8
  D11 --> D9
  D11 --> D10

4. Explicacao dos elementos¶

4.1 SaaS Control Plane¶

O SaaS Control Plane nao representa o ciclo de grant.

Ele representa a operacao do produto enquanto servico, incluindo:

cadastro e ciclo de vida de tenants
provisionamento
planos e habilitacao de modulos
operacao white-label
administracao comercial e de parceiros

Em uma implantacao apenas institucional, parte dessa camada pode nascer minima.

Em uma estrategia SaaS, essa camada e essencial para separar:

o que e operacao do produto
do que e operacao do grant management em cada cliente

4.2 Tenancy and Commercial¶

Este bloco organiza capacidades que permitem existir mais de uma instituicao cliente no mesmo produto, com governanca economica e operacional.

Inclui:

ciclo de vida do tenant
isolamento
limites e quotas
modulos contratados
branding
canais indiretos como parceiros e revendedores

Ele atende diretamente a tensao do discovery entre:

entrega inicial para um contexto institucional
e evolucao sustentavel para outras fundacoes ou operadores do mercado

4.3 Identity Access and Trust¶

Este bloco concentra confianca, identidade e acesso.

Inclui:

federacao de identidade por tenant
autorizacao baseada em papeis e atributos
trilhas de auditoria
secrets e chaves por tenant

Ele nao e um dominio de grant management, mas atravessa todos os dominios de negocio.

Sem esse bloco explicito, a solucao tende a misturar:

cadastro de usuario com regras do negocio
permissao de acesso com ownership de tabelas
auditoria de seguranca com auditoria de negocio

4.4 Shared Platform Capabilities¶

Este bloco concentra capacidades compartilhadas que viabilizam configurabilidade e reuso entre dominios.

Inclui:

workflow e aprovacoes
formularios e templates
gestao documental
notificacoes
hub de integracoes
dados mestres e referenciais
cadastro de pessoas e organizacoes
politicas e configuracoes por tenant

A importancia desse bloco no contexto SaaS e alta porque ele absorve variacao sem obrigar cada dominio a reinventar:

telas e formularios
motores de aprovacao
templates de documentos
conectores externos

Mesmo assim, ele deve ser lido como capacidade compartilhada, nao como substituto dos dominios de negocio.

4.5 Strategy Governance and Portfolio¶

Este bloco une tres preocupacoes que hoje aparecem como tensao forte no discovery:

estrategia do grantor
governanca institucional
visao consolidada de portfolio e risco

Inclui:

planejamento estrategico
programas, comites e orcamento macro
aprovacoes internas e responsabilidades institucionais
dashboards de portfolio e risco

Ele atende principalmente o dominio de discovery Institutional Governance and Portfolio, mas tambem sustenta o nascimento das oportunidades de fomento.

Esse bloco evita que a proposta fique enviesada apenas para:

o ponto de vista do grantor
ou apenas para a execucao operacional do projeto

4.6 Planning and Funding Opportunities¶

Este bloco organiza a criacao da oportunidade de fomento.

Inclui:

chamadas, campanhas e oportunidades
regras de elegibilidade
criterios
calendario e publicacao

Ele corresponde diretamente ao dominio de discovery Planning and Funding Opportunities.

A logica aqui e responder:

o que vai ser aberto
para quem
em qual calendario
com quais regras publicas

4.7 Proposal Submission and Selection¶

Este bloco cobre a entrada das propostas e sua transformacao em decisoes defensaveis.

Inclui:

submissao
validacao
habilitacao
avaliacao
selecao
publicacao de resultados e recursos

Ele corresponde diretamente ao dominio Proposal Submission and Selection.

Esse dominio termina na decisao de aprovar, reprovar ou manter suplencia.

Ele ainda nao formaliza a concessao.

4.8 Award Formalization¶

Este bloco foi explicitado de forma separada porque no discovery ele aparece como dominio proprio e concentra responsabilidades que nao cabem nem em selecao nem em execucao.

Inclui:

geracao do termo
aceite institucional e individual
pendencias documentais
condicoes de inicio
ativacao formal da concessao

Ele faz a ponte entre:

a decisao de apoio
e o inicio de uma concessao executavel, auditavel e desembolsavel

No modelo alvo, este bloco e critico porque ele deve virar um limite de responsabilidade claro para:

regras de ativacao
status juridico-operacional do award
gatilhos para execucao e desembolso

4.9 Project Execution and Deliverables¶

Este bloco cobre o acompanhamento da vida do projeto apoiado.

Inclui:

administracao do grant ou projeto
entregas, marcos e resultados
gestao de equipe
alteracoes, prorrogacoes e ajustes
suspensao e encerramento

Ele corresponde ao dominio Project Execution and Deliverables.

A logica aqui e acompanhar o que acontece durante a vida do apoio, incluindo mudancas e evidencias tecnicas.

4.10 Finance and Disbursements¶

Este bloco concentra a gestao financeira operacional do apoio.

Inclui:

rubricas e linhas orcamentarias
desembolsos
bolsas e beneficios
mapeamento contabil
integracao bancaria e conciliacao

Ele corresponde ao dominio Resource Disbursement and Benefits.

No cenario atual do produto, este e um dos pontos mais sensiveis, porque concentra:

varias integracoes
impacto operacional direto
compartilhamento atual de tabelas entre modulos

Por isso, ele precisa existir como dominio explicito e nao como prolongamento informal de outros modulos administrativos.

4.11 Accountability Compliance and Audit¶

Este bloco organiza a comprovacao do uso correto do recurso e a capacidade de responder a controle e auditoria.

Inclui:

prestacao de contas financeira
verificacao documental
apontamentos e findings
evidencias de auditoria
saidas de transparencia e obrigacoes regulatorias

Ele corresponde ao dominio Accountability, Compliance and Audit.

No contexto SaaS, esse bloco tambem precisa suportar variacao por tenant em:

regras
formatos de evidencia
outputs regulatorios
criterios de conformidade

4.12 Data and Intelligence¶

Este bloco consolida consumo analitico e produtos de dados.

Inclui:

dashboards operacionais
analytics e KPIs
exportacoes e data marts por tenant

Ele nao substitui os dominios transacionais.

Ele consome os dominios para:

ampliar visibilidade
apoiar governanca
suportar transparencia
atender demandas analiticas sem contaminar o modelo transacional

5. Macro-relacoes entre os blocos¶

5.1 Fluxo principal do ciclo de grant¶

O fluxo central proposto e:

Strategy Governance and Portfolio -> Planning and Funding Opportunities -> Proposal Submission and Selection -> Award Formalization -> Project Execution and Deliverables -> Finance and Disbursements -> Accountability Compliance and Audit

Esse fluxo nao significa sequencia tecnica obrigatoria.

Ele representa dependencias principais de negocio.

5.2 Relacoes mais importantes¶

Strategy Governance and Portfolio -> Planning and Funding Opportunities¶

O planejamento estrategico e institucional alimenta a abertura de oportunidades.

Sem isso, o edital vira artefato isolado.

Proposal Submission and Selection -> Award Formalization¶

A selecao decide quem pode receber apoio.

A formalizacao transforma essa decisao em compromisso executavel.

Award Formalization -> Project Execution and Deliverables¶

O projeto nao deve ser tratado como plenamente ativo antes da concessao estar formalizada e ativada.

Award Formalization -> Finance and Disbursements¶

O desembolso nao deve depender apenas de execucao.

Ele depende da concessao estar validamente formalizada, aceita e ativa.

Project Execution and Deliverables -> Finance and Disbursements¶

A execucao produz eventos, marcos e condicoes que podem influenciar desembolso, continuidade e alteracoes financeiras.

Project Execution and Deliverables -> Accountability Compliance and Audit¶

Prestacao de contas nao nasce apenas do financeiro.

Ela precisa correlacionar tecnico, documental e financeiro.

Finance and Disbursements -> Accountability Compliance and Audit¶

Os registros financeiros e de beneficio alimentam analise, conciliacao e comprovacao.

5.3 Relacoes transversais¶

Identity Access and Trust¶

Todos os dominios precisam de:

autenticacao
autorizacao
rastreabilidade
confianca

Shared Platform Capabilities¶

Todos os dominios operacionais usam:

workflow
formularios
documentos
notificacoes
integracoes
configuracoes

Data and Intelligence¶

Todos os dominios podem gerar produtos de dados para:

operacao
decisao
transparencia
intelligence por tenant

6. Como a proposta atende o discovery¶

6.1 Correspondencia principal¶

Discovery	Bloco da proposta
Planning and Funding Opportunities	`Planning and Funding Opportunities`
Proposal Submission and Selection	`Proposal Submission and Selection`
Grant Award Formalization	`Award Formalization`
Project Execution and Deliverables	`Project Execution and Deliverables`
Resource Disbursement and Benefits	`Finance and Disbursements`
Accountability, Compliance and Audit	`Accountability Compliance and Audit`
Institutional Governance and Portfolio	`Strategy Governance and Portfolio`

6.2 Restricoes estrategicas do discovery refletidas aqui¶

Esta proposta tambem tenta responder as restricoes registradas em context-and-strategy.md:

implantacao inicial viavel em ambiente institucional
necessidade de evolucao para produto replicavel
necessidade de configurabilidade
necessidade de separacao entre contexto local e capacidades gerais do produto

Por isso, a proposta separa explicitamente:

o que e produto SaaS
o que e capacidade transversal
o que e dominio do grant management

7. Como a proposta ajuda no cenario SaaS¶

7.1 Reducao de acoplamento¶

Ao explicitar dominios e capacidades compartilhadas, a proposta prepara terreno para:

ownership mais claro por contexto
menos alteracao concorrente no mesmo schema
menor dependencia entre times

7.2 Multi-tenant real¶

Multi-tenant nao e apenas colocar tenant_id em tabelas.

Exige tratar explicitamente:

identidade por tenant
configuracao por tenant
branding por tenant
integracoes por tenant
exports e analytics por tenant
isolamento e limites operacionais por tenant

Esses elementos aparecem fora dos dominios de grant porque pertencem ao produto SaaS, nao ao grant em si.

7.3 White-label¶

White-label exige separar:

identidade visual
configuracoes
textos e documentos
experiencia por tenant

Essa separacao fica mais facil quando Shared Platform Capabilities e Tenancy and Commercial ja existem como partes explicitas da proposta.

7.4 Portabilidade entre Prodest e nuvem publica¶

A proposta ainda nao define tecnologia, mas ela ajuda a diferenciar:

partes mais locais da implantacao inicial
partes que precisam nascer mais portaveis

Isso sera importante quando a inception passar para:

componentes
contratos
topologia de dados
seguranca

8. Limites importantes desta proposta¶

Esta proposta ainda nao define:

numero final de servicos
separacao final de bancos fisicos
contratos de API
mensageria
estrategia de deploy
escolha de frameworks

Ela define apenas uma organizacao macro para orientar a proxima etapa.

9. Perguntas que o grupo deve responder ao revisar esta proposta¶

a separacao entre control plane, shared capabilities e business domains esta clara o suficiente
Award Formalization deve ser mesmo um dominio proprio
Strategy Governance and Portfolio cobre bem a governanca institucional e do grantor
existe algum dominio do discovery que continua mal representado
quais blocos precisam nascer no primeiro recorte institucional
quais blocos podem ser simplificados no inicio sem comprometer a evolucao para SaaS

10. Criterios minimos para considerar a proposta robusta o suficiente¶

Antes de avancar para componentes e tecnologia, o grupo deve considerar se a proposta:

cobre os dominios do discovery sem depender da organizacao atual por modulos
separa com clareza dominio de negocio, capacidade transversal e operacao SaaS
cria um bom ponto de partida para discutir ownership de dados
permite um recorte institucional inicial sem bloquear a evolucao para SaaS
ajuda a reduzir a chance de novos acoplamentos por schema compartilhado

11. Proximo passo sugerido¶

Se o grupo validar esta macro-organizacao, o proximo documento de inception deve derivar dela:

candidate bounded contexts
ownership map de dados
current-to-target mapping dos modulos atuais
criterios para adaptacao, extracao ou substituicao