/projects/ulbra-one

← Todos os projetos

Ulbra One

O ERP que está sendo construído para tirar a universidade do Senior.

Head de Tecnologia · Jun 2026 – Atual

.NET 10PostgreSQL 17EF CoreReactTailwindshadcn/ui
Privado
Captura de tela de Ulbra One

Visão geral

Um ERP interno construído para tirar a universidade dos sistemas legados — um monólito modular em .NET 10 sobre PostgreSQL 17 com front-end em React, cobrindo as operações internas centrais. Está em teste, antes do lançamento, então o que segue descreve o que foi construído, não o que está em produção.

O que eu fiz

Defini a arquitetura e as convenções e construí junto com um engenheiro que toca o dia a dia deste código.

  • As fronteiras entre módulos e as convenções trazidas do service desk.
  • O schema PostgreSQL e o caminho de migrations code-first.
  • Revisão de toda mudança que entra no código.

Um engenheiro cuida deste código no dia a dia; boa parte da implementação é dele.

O problema

A universidade opera seus processos internos sobre sistemas legados licenciados em que nem os dados nem os processos se encaixam bem. O Ulbra One é a plataforma que deve substituí-los, construída em casa para que as regras de negócio fiquem onde o time pode mudá-las.

O que faz

  • Um monólito modular organizado por domínio de negócio, não por camada técnica.
  • PostgreSQL via EF Core, code-first, com nomenclatura snake_case aplicada por convenção e não por atributo.
  • Front-end React e Tailwind compartilhando os design tokens do service desk.
  • As migrations rodam na inicialização, então nenhum ambiente fica um passo manual atrás do código.

Decisões de engenharia

  • As mesmas convenções do service desk, de propósito

    Formato de endpoint, tipo de retorno e estratégia de migration são copiados do Ulbra Atende em vez de repensados. Com três engenheiros para seis sistemas, quem troca de código não deveria estar aprendendo um segundo conjunto de regras — a consistência vale mais do que qualquer melhoria local que um dos dois pudesse ter feito sozinho.

  • Um monólito modular, não serviços

    Um ERP é um conjunto de domínios fortemente relacionados que transacionam juntos. Quebrá-lo em serviços compraria deploy independente ao custo de transações distribuídas entre módulos que realmente precisam de consistência — e não há time aqui para operar isso. Os módulos dão as fronteiras; o processo único mantém as transações.