Current Landscape and Convergence¶

1. Objetivo¶

Este documento descreve como o estado atual dos componentes se relaciona com a macro-organizacao proposta.

O objetivo e apoiar a discussao sobre:

reaproveitamento
refatoracao
extracao de responsabilidades
substituicao de componentes

2. Paisagem atual observada¶

2.1 API Admin¶

O repositorio leds-conectafapes-backend-admin concentra hoje um conjunto amplo de responsabilidades:

cadastros administrativos
usuarios e papeis
editais
projeto, pessoa e dados bancarios
planejamento de alocacao
tabelas de referencia

Tambem ha sobreposicao com o universo de pagamento, inclusive com ocorrencias de PagamentoBolsista no modelo.

Isso sugere que o componente atual opera mais como schema owner central do que como contexto bem delimitado.

2.2 API Pagamento Bolsistas¶

O repositorio leds-conectafapes-backend-pagamento-bolsistas concentra:

folha
pagamento de bolsistas
remessas
guias de liberacao
decisoes operacionais
jobs e processamento em background

Ao mesmo tempo, depende de varias entidades lidas por view ou referencias equivalentes, como:

projeto
edital
pessoa
alocacao de bolsista
modalidades e niveis

Isso confirma acoplamento forte com o modelo compartilhado atual.

2.3 API Prestacao de Contas¶

O repositorio leds-conectafapes-prestacao-de-contas esta mais proximo de um contexto proprio.

Ele concentra tabelas e regras associadas a:

prestacao
orcamento
conta contabil
conta bancaria
transacao financeira
documento fiscal
justificativas

As dependencias externas observadas sao mais contidas, principalmente por referencias a:

projeto
alocacao de bolsista

2.4 API Portal¶

O repositorio correto de portal ainda nao foi confirmado na verificacao estrutural.

Mesmo sem essa confirmacao, pelo relato do time ha indicio de que ele misture:

experiencias administrativas
experiencias publicas
modelos parcialmente compartilhados

Se isso se confirmar, o portal deve ser tratado com cautela para nao ser tomado como dominio central.

3. Tensoes principais do estado atual¶

As evidencias atuais apontam quatro tensoes estruturais:

3.1 Ownership difuso de dados¶

Varios componentes parecem depender do mesmo conjunto de tabelas ou de visoes derivadas do mesmo schema principal.

Isso dificulta:

governanca
evolucao em paralelo
isolamento de responsabilidades

3.2 Modulos maiores que seus contextos¶

Especialmente no caso de admin, o componente atual parece concentrar mais responsabilidades do que seria desejavel em um desenho orientado a dominios.

3.3 Dependencia de leitura cruzada como base do modelo¶

O uso recorrente de ToView ou referencias cruzadas mostra que varios componentes dependem do mesmo modelo estrutural para operar.

Isso pode ser util como transicao, mas nao e uma boa base permanente para SaaS governavel.

3.4 Risco de confundir experiencia com dominio¶

Se portal estiver centralizando regra de negocio ou ownership de dados, isso reforca um problema conceitual:

interface ou experiencia de uso nao deve definir o dominio do produto

4. Convergencia com a macro-organizacao proposta¶

4.1 Direcao geral¶

O caminho mais coerente nao parece ser:

recomeçar tudo do zero

Tambem nao parece ser:

manter os componentes atuais como estao e apenas reorganizar nomes

A direcao mais defensavel e:

reaproveitar onde ja existe nucleo de negocio claro
refatorar onde ha acoplamento estrutural forte
extrair responsabilidades onde o componente atual esta largo demais
reposicionar portais como camada de experiencia

4.2 Leitura por componente¶

Componente atual	Leitura frente a proposta	Direcao recomendada
`API Admin`	concentrador de responsabilidades heterogeneas	extrair e redistribuir responsabilidades
`API Pagamento`	nucleo operacional de desembolso com forte acoplamento estrutural	reaproveitar com refatoracao significativa
`API Prestacao de Contas`	mais proximo de um bounded context proprio	evoluir como frente de negocio mais autonoma
`API Portal`	provavel camada de experiencia misturada com regra	reposicionar como experiencia/BFF, nao como dominio

5. Recomendacoes objetivas¶

5.1 API Admin¶

Nao deve permanecer como dono central do modelo de negocio.

A recomendacao e usar esse componente como fonte de:

regras reaproveitaveis
cadastros e referenciais a redistribuir
insumos para futura definicao de ownership

5.2 API Pagamento¶

Pode continuar relevante no dominio Finance and Disbursements, principalmente onde ja existe logica de:

remessa
folha
liberacao
processamento operacional

Mas precisa reduzir dependencia estrutural do schema compartilhado.

5.3 API Prestacao de Contas¶

E o melhor candidato atual para evolucao como contexto mais autonomo.

Sua estrutura esta mais alinhada ao tipo de fronteira que a proposta macro sugere.

5.4 API Portal¶

Deve ser avaliada principalmente como:

camada de experiencia
composicao
adaptacao por perfil ou canal

Nao como dono principal de dominio.

6. Implicacoes para dados e governance¶

O problema atual nao e apenas quantos repositorios existem.

O problema central e a combinacao de:

schema principal compartilhado
ownership difuso
multiplos times alterando a mesma base
fronteiras fracas entre leitura e escrita

Para convergir com a proposta macro, sera necessario discutir na proxima etapa:

ownership logico de dados por contexto
quem escreve cada agregado
quem apenas referencia
como suportar leitura cross-domain sem posse compartilhada do mesmo agregado

Isso nao obriga imediatamente um banco fisico por servico.

Mas exige, no minimo, ownership logico muito mais claro.

7. Proximo passo recomendado¶

Depois da validacao da proposta macro pelo time, os artefatos mais uteis para seguir sao:

candidate bounded contexts
ownership map de dados
current-to-target mapping
decisao por componente: adapt, extract, replace