/projects/ulbra-admin
← Todos os projetosUlbra Admin
Os números com que a diretoria conduz a universidade.
Head de Tecnologia — design & implementação · Ago 2026 – Atual
Visão geral
Os dashboards que a presidência e a diretoria usam para conferir os números da universidade. Uma API em .NET 10 e um front-end React 19 que leem dois sistemas que não lhes pertencem: dados de captação vindos do CRM e matrícula confirmada da plataforma Oracle legada, por um cliente HTTP tipado e não por conexão de banco.
O que eu fiz
Construí de ponta a ponta — a API, as integrações, o front-end e o deploy.
- A integração somente-leitura com a base do CRM.
- O cliente tipado que fica à frente do sistema legado de matrícula.
- Os próprios dashboards e o front-end React.
- Autenticação e o deploy em Swarm.
O problema
Quem responde pelos números da universidade não conseguia vê-los sem pedir. A matrícula ficava numa plataforma legada, a captação no CRM, e cruzar as duas significava um chamado para a TI e uma planilha que já chegava desatualizada. A pergunta não era complicada; a resposta é que nunca estava à mão.
Arquitetura
Duas fontes, nenhuma delas própria deste sistema, atrás de uma API.
- CRM storeDados de captação e funil, somente leitura.
- Enrollment APIUm cliente HTTP tipado sobre a plataforma legada — nunca o banco diretamente.
- Admin APIJunta as duas e serve os dashboards.
- DashboardsO que a diretoria de fato olha.
O que faz
- Números de captação e de matrícula lado a lado, vindos dos dois sistemas que os detêm.
- Lê a base do CRM estritamente em modo leitura — os dashboards não têm como corromper o sistema de origem.
- Login único, então o acesso segue as contas que a universidade já administra.
- Os mesmos design tokens do service desk, para que seis sistemas leiam como uma plataforma só.
Decisões de engenharia
Deliberadamente a arquitetura mais simples do grupo
Projeto único, sem módulos, sem DDD — escrito no código como regra, numa casa cujo service desk é um monólito modular. Este sistema quase não tem domínio próprio: ele lê dois outros sistemas e desenha gráficos. Dar-lhe agregados e contextos delimitados seria cerimônia em volta de uma consulta. A arquitetura é escolhida por problema, e a resposta honesta aqui era "menos".
Nunca consultar o banco legado diretamente
A matrícula poderia ser lida direto do banco da plataforma legada, e teria sido mais rápido de escrever. Ela passa por uma API tipada, para que a definição de "aluno matriculado" viva em um lugar só em vez de ser reimplementada numa consulta SQL — e para que, no dia em que a plataforma legada for substituída, mude um cliente e não todos os consumidores.
Somente leitura por construção
A conexão com a base do CRM é somente leitura, não por convenção mas pelas credenciais que ela carrega. Um sistema de relatórios capaz de escrever no sistema de origem está a um bug de corromper os números que existe para reportar.