Protótipo de plataforma de gestão do Tribunal de Justiça do Espírito Santo
PythonFlaskVueBootstrapPostgreSQLDocker
>Contexto
O Tribunal de Justiça do Espírito Santo tem 20 projetos de modernização no programa Inovação a Serviço da Justiça, divididos em eixos e times diferentes. Eles nasceram separados, mas dividem peças caras: autenticação, perfis e auditoria, contratos, patrimônio e a própria cara das telas. Se cada time fizer a sua, a mesma peça sai várias vezes, e quem herda tudo no fim é a TI do Tribunal.
Sou engenheiro de software, com bolsa de pesquisa, no programa desde 01/10/2026; a primeira PoC da estrutura compartilhada saiu em 19/09, antes do início oficial. Desde 21/10 atuo em todos os eixos: cuido do design system e dos padrões de arquitetura dos 20 projetos e ajudo os times a ligar as pontas.
No eixo de Engenharia, sigo construindo o Projeto 19 (gestão de obras, contratos e serviços), para a Secretaria de Engenharia, e também estou no Projeto 20 (cadastro técnico imobiliário). Também escrevi a proposta de acesso técnico para a TI do Tribunal: como o programa trabalha sem conta nova, sem acesso a produção e sem dado real fora do Tribunal.
>Arquitetura (HLD)
Vai rodar na infraestrutura do Tribunal, no padrão que a TI definiu em 06/10: Python 3 com Flask, Vue com Bootstrap, PostgreSQL e Docker. Ninguém do programa tem acesso a produção. Hoje o P19 roda em desenvolvimento local: o Flask sobe numa porta e o Vite repassa as chamadas de /api para ele.
Uma requisição sai do navegador, passa pelo front-end em Vue 3 e chega à API Flask por REST. A rota só traduz HTTP para um caso de uso, e a raiz de composição escolhe qual adaptador atende cada porta. O orçamento chega pela porta de orçamento, com dois adaptadores: um cliente da API do sistema de orçamento, testado contra um transporte falso e ainda sem rodar contra o sistema real, e um arquivo de exemplo. O login fica no contexto de acesso, que ainda não tem código. O estado vai para o PostgreSQL; até lá, um repositório em memória ocupa a mesma porta. Não há fila nem job: importar um orçamento é uma chamada síncrona.
Todo push no repositório do programa, só com dados fictícios, roda a mesma checagem: ruff, mypy, xenon e pytest com cobertura no back-end; vue-tsc, ESLint, Vitest e build no front-end e no design system. O código é copiado para o GitLab do Tribunal, onde já deixei um pipeline com essa checagem, ainda não executado. Só a TI do Tribunal homologa e publica em produção.
Passe o mouse ou foque uma peça: ela acende com as ligações.
12 peças11 ligações4 áreas
Componentes
Design system compartilhado :: Pacote Vue 3 sobre Bootstrap 5.3, com tokens pelo método do Carbon da IBM e a marca do portal do Tribunal, de onde saem as telas do P19 e dos outros projetos.
Front-end Vue por projeto :: SPA em Vue 3 e Vite que monta as telas só com componentes do design system e chama a API do projeto por REST.
API Flask por contexto :: Back-end em Python 3.13 organizado em sete contextos, com domínio e casos de uso sem framework, banco nem I/O, e adaptadores HTTP, de banco e de sistemas externos na borda.
Porta de orçamento :: Traz o orçamento do sistema de orçamento por API ou de um arquivo de exemplo; a configuração escolhe o adaptador, e domínio e casos de uso não mudam.
Persistência :: PostgreSQL, o banco do padrão da TI; hoje um repositório em memória atende a mesma porta.
Suíte de arquitetura :: Contratos do import-linter e regras do dependency-cruiser rodam no make check a cada push e reprovam quem quebra a regra da dependência.
Fluxo de entrega :: Código no repositório do programa, só com dados fictícios, copiado para o GitLab do Tribunal; homologação e publicação em produção só pela TI do Tribunal.
>Trade-offs
Flask, Vue, Bootstrap e PostgreSQL, o padrão da TI do Tribunal.
Alternativa descartada: React e Node com TypeScript, a stack da primeira PoC, de 19/09.
Por quê: A TI apresentou o padrão do Tribunal em 06/10, e é ela quem mantém o código depois que o programa acaba. A decisão antiga ficou registrada como substituída.
Regras de arquitetura verificadas por teste.
Alternativa descartada: Regra escrita num documento e cobrada na revisão de código.
Por quê: Com vários times no mesmo padrão, a regra precisa reprovar sozinha. Trocar o arquivo de exemplo pela API real, ou a memória pelo PostgreSQL, vira trocar um adaptador na raiz; domínio e casos de uso não mudam.
Design system aprovado como protótipo antes de virar componente Vue.
Alternativa descartada: Escrever os componentes Vue direto e ajustar depois.
Por quê: Pedi a opinião da coordenação e dos times antes de fixar a forma de uso: o que falta para cada projeto e o que mudaria. Componente só entra no pacote com teste.
>Destaques
>Proposta de acesso com 4 compromissos: nenhuma conta nova no Tribunal para as soluções novas, zero acesso a produção, nenhum dado real fora do Tribunal e todo o código copiado no GitLab do Tribunal.
>4 contratos de arquitetura no back-end e 10 regras no front-end; no back-end, complexidade acima de 5, mais de 4 parâmetros ou cobertura abaixo de 90% reprovam a checagem.
>Protótipo do design system com 6 componentes documentados em Uso, Estilo, Código e Acessibilidade, tema claro e escuro e 3 telas clicáveis do P19.
>Curiosidades
*Em 19/09, 12 dias antes do início oficial, escrevi no grupo do squad que tinha ficado a manhã de bobeira e já tinha feito uma pequena PoC com uma estrutura compartilhada.
*O protótipo do design system abre sem internet: fontes, ícones e Bootstrap vêm dentro do pacote, nada de CDN.
*No P19, o domínio não pode importar nem os, json ou logging: o contrato io-free-domain reprova qualquer I/O.
*Código 100% em inglês e tela em português: um glossário numa ADR leva orçamento para budget, medição para measurement e diário de obra para site_diary.