Arquitetura de Software
O E-Docs é um sistema complexo, possuindo muitos módulos em sua arquitetura de software para permitir sua escalabilidade. O início de seu desenvolvimento se deu num formato mais monolítico, mas conforme cresceu sua utilização, foi necessário segmentar sua execução em vários serviços diferentes. Atualmente, o sistema passa por uma revisão de sua arquitetura, aproveitando os anos de experiência neste e em outros projetos para simplificar decisões arquiteturais e trazer uma estrutura mais simples e fácil de manter, com foco em desempenho e escalabilidade.
Diagrama de referência:
Clique no diagrama para abrir em alta resolução em uma nova aba.
O diagrama traz uma visão geral do sistema, mostrando:
- App Web e API Pública, parte do E-Docs Clássico (IIS), que funcionam como porta de entrada dos usuários e integradores;
- Todos os serviços da E-Docs Next-Gen Architecture (E-Docs NA), organizados nos quatro agrupamentos (Primários, Auxiliares, Dependências Tecnológicas e Especialistas);
- A plataforma tecnológica de hardware e infraestrutura sobre a qual o sistema é executado, detalhada em Arquitetura de Hardware;
- O ecossistema de integrações e dependências externas, como Acesso Cidadão, Organograma, Lotação, E-Flow, Cyclus, Tramita, Permissão e Notifica, detalhado em Integrações.
Este artigo é focado na arquitetura de software. Assim, as próximas seções detalham cada um dos módulos do E-Docs Clássico e do E-Docs NA.
E-Docs Clássico
Projeto inicial do E-Docs, cuja primeira versão data de 2018. Os sistemas deste conjunto são construídos em .NET 5 e executados em ambiente IIS.
Web
Aplicação Web do E-Docs, acessível em https://e-docs.es.gov.br. É a interface do usuário no navegador, responsável pela autenticação e por operações como captura de documentos, autuação de processos e encaminhamento. Possui interface responsiva, o que permite o uso do E-Docs tanto no desktop quanto em dispositivos móveis.
API Pública
API pública do E-Docs, acessível em https://api.e-docs.es.gov.br. Permite a integração de outros sistemas com o E-Docs para operações de consulta de metadados públicos, captura e encaminhamento de documentos, além de atos processuais como autuação, despacho e entranhamento.
Background Jobs
Executa tarefas agendadas ou em segundo plano, que independem da conectividade do usuário no momento da execução. Exemplos: envio de notificações, credenciamento e geração de Documentos-Elo.
Process Jobs
Sistema de filas do E-Docs, baseado no padrão Outbox. Distribui e equilibra o processamento de tarefas pesadas como capturas, encaminhamentos e despachos.
Gerador de PDF
API de manipulação de arquivos PDF do E-Docs. Realiza operações como carimbar, mesclar e gerar arquivos a partir de templates HTML.
Certificado
Valida certificados digitais ICP-Brasil antes da captura de documentos assinados, garantindo que o certificado estava válido e não revogado no momento da assinatura.
Certificado Outbound
Componente que faz o acesso externo (outbound) à internet em nome da API de Certificado, para consultas de cadeias de certificação e listas de revogação.
DevArea
Aplicação de suporte do E-Docs, que permite aos desenvolvedores consultar dados e executar operações para diagnosticar e corrigir falhas ou comportamentos inesperados.
Test Area
Ambiente isolado utilizado pela equipe de desenvolvimento para validar funcionalidades do E-Docs.
E-Docs Next-Gen Architecture (E-Docs NA)
Projeto de modernização do E-Docs. Tem como intuito principal reescrever o back-end de todas as funcionalidades do sistema, de forma modular. Usa o conceito de serviços distribuídos e conectados via APIs REST, agrupados em funções especializadas por tarefa, tecnologia ou conceito.
Todos os sistemas deste conjunto são construídos em .NET 10 e executados de forma containerizada no OCP (OpenShift).
A arquitetura se inspira em microsserviços, mas evita a comunicação excessiva entre os serviços: cada chamada às APIs busca resolver casos de uso específicos, garantindo eficiência e desempenho.
Este artigo descreve o que são os módulos do E-Docs NA. Para entender por que essa arquitetura foi adotada (a motivação, os padrões de projeto como CQRS e Outbox, a estratégia de migração com feature flags e os números de operação do sistema), consulte E-Docs Next-Gen Architecture.
Serviços Primários de Negócio
São os serviços responsáveis pela execução direta dos casos de uso do sistema. Adotam o padrão CQRS, separando operações de leitura (Query) das de escrita (Command), além de um padrão Dispatch/Process para os casos de uso mais pesados.
ENQ - E-Docs Negócio Query
Abriga todos os casos de uso de leitura (query) do sistema, seguindo a filosofia do CQRS. Inclui contadores, listagens, detalhes e dashboards. A partir desta API são construídas várias páginas do sistema, como caixas de processos, caixas de encaminhamentos e contadores da tela inicial. O objetivo é prover informações de forma rápida e eficiente, sem processamento adicional.
Contém consultas de praticamente todos os módulos de negócio do E-Docs: Documentos (capturados, para assinar, em elaboração), Encaminhamentos, Processos e seus atos (autuação, despacho e outros), credenciamento de documentos e de processos, entre outras.
Acessa o banco de dados do E-Docs.
ENC - E-Docs Negócio Command
Executa os casos de uso de escrita do sistema, sendo a parte Command do padrão CQRS, contraponto ao ENQ. Concentra as operações de inserção, atualização e exclusão de dados, como marcar encaminhamentos como lidos ou incluir e remover processos de pastas. As funcionalidades que utilizam o padrão Dispatch/Process ficam em serviços dedicados.
Suas rotinas podem realizar consultas necessárias para a execução das escritas, como buscar informações para aplicar validações.
Executa operações em nome do usuário logado, exigindo um token de usuário válido oriundo do Acesso Cidadão, de forma a garantir a autoria das ações. Acessa o banco de dados do E-Docs.
ENB - E-Docs Negócio Base
Centraliza regras de negócio comuns a vários módulos do sistema, evitando duplicação de código e reduzindo o risco de versões divergentes da mesma regra.
Em relação a documentos, abriga a lógica de acesso aos documentos do E-Docs. Suas principais funcionalidades são o PodeVer (calcula se o usuário tem permissão para visualizar o conteúdo de um documento capturado) e o PodeUsar (define se o usuário pode usar um documento em encaminhamentos e processos). Com base nessas informações, também gerencia a obtenção da URL de visualização dos documentos capturados.
Em relação a processos, possui a lógica de cálculo do ProcessoStatus, um objeto contendo informações críticas ao processo, como custódia atual, situação (encerrado ou não), último ato e último ato de movimentação. Usado em vários pontos do sistema onde se lida com processos administrativos.
Também abriga a lógica de permissionamento das principais funções do sistema, tratando de documentos, encaminhamentos e processos.
Como apoio a todos os cálculos citados acima, o ENB gerencia o UsuarioLogadoCache, um objeto carregado no momento do login do usuário, contendo várias informações suas: papéis que possui, grupos onde é membro, locais onde é gestor, locais com delegação e permissões explícitas. Esse objeto é mantido em cache, permitindo que os cálculos sejam feitos da forma mais rápida possível.
Acessa o banco de dados do E-Docs.
END - E-Docs Negócio Dispatch
Concentra todas as funcionalidades do E-Docs que dependem do padrão Dispatch/Process, como captura, encaminhamento e atos processuais. Realiza a fase de Dispatch, fazendo validações e preparando os dados que serão usados na fase de Process, e enfileirando os eventos de processamento.
Executa operações em nome do usuário logado, exigindo um token de usuário válido. Acessa o banco de dados do E-Docs.
Para um exemplo concreto desta fase aplicada a um caso de uso real, consulte o estudo de caso do fluxo de captura de documentos.
ENP - E-Docs Negócio Process
Realiza a parte de processamento de todas as funcionalidades do E-Docs que dependem do padrão Dispatch/Process. Consome as execuções enfileiradas pelo END e, ao final, atualiza a situação do evento de processamento e dispara as tarefas de pós-processamento (como indexação dos dados, credenciamento de acessos e envio de notificações).
Executa em um Hangfire dedicado, com base de dados própria, trabalhando com conceito de fila seguindo o Outbox Pattern. Adicionalmente, acessa o banco de dados do E-Docs.
Para um exemplo concreto desta fase aplicada a um caso de uso real, consulte o estudo de caso do fluxo de captura de documentos.
ENT - E-Docs Negócio Tasks
Executa tarefas agendadas ou em segundo plano, que independem da conectividade do usuário no momento da execução. Exemplos: credenciamento de documentos, geração de Documentos-Elo.
Executa em um Hangfire dedicado, com base de dados própria.
Serviços Auxiliares de Negócio
São serviços de apoio que fornecem dados e funcionalidades complementares aos serviços primários. Concentram responsabilidades específicas para garantir padronização e reuso.
EAQ - E-Docs Agente Query
Centraliza e padroniza a obtenção de agentes no E-Docs. Também traz consultas de permissões de usuário e outras informações correlatas.
Um agente no E-Docs possui seis tipos possíveis: Órgão, Unidade, Grupo, Servidor, Cidadão e Sistema. Para mais detalhes sobre o conceito, consulte o artigo Agente.
A entrega das informações ocorre por meio do objeto AgenteDto, estrutura de dados unificada e transversal a toda a arquitetura, cuja montagem é responsabilidade do EAC.
Acessa o banco de dados próprio de agentes e, em alguns casos, também o banco de dados do E-Docs.
EAC - E-Docs Agente Carga
Realiza as cargas de dados que alimentam o Agente Query, mantendo a base sincronizada com as fontes originais. As informações têm três origens: o sistema Organograma (Órgãos e Unidades), o Acesso Cidadão (Cidadãos e Sistemas) e o Lotação (Papéis e Grupos/Comissões).
A partir dessas três fontes, o EAC monta o objeto AgenteDto, uma estrutura de dados unificada e transversal a toda a arquitetura, que padroniza a representação de um agente. Essa consolidação leva em consideração questões de negócio do E-Docs, como, por exemplo, se o patriarca está habilitado para usar o sistema.
Executa em um Hangfire dedicado, com base de dados própria (a base de agentes). Eventualmente, também acessa o banco de dados do E-Docs.
EUM - E-Docs Usuário Manager
Gerencia funções personalizadas dos usuários, como papel preferencial, delegação de acesso e processos e encaminhamentos favoritos.
Executa operações em nome do usuário logado, exigindo um token de usuário válido oriundo do Acesso Cidadão, de forma a garantir a autoria das ações. Possui base de dados própria.
ENO - E-Docs Notificação Composer
Compõe e envia as notificações do sistema. Dado um tipo de notificação (captura, assinatura, encaminhamento, despacho, entre outros), define quais agentes serão notificados, monta a mensagem e aciona a API do sistema estruturante de Notificações do Prodest, que cuida da entrega.
Possui uma API para envio das notificações, cuja única função é disparar um job fire-and-forget com retry no Hangfire. No futuro, avalia-se a conversão dessa lógica para passar a usar o padrão Outbox.
Executa em um Hangfire dedicado, com base de dados própria. Também acessa o banco de dados do E-Docs.
ECQ - E-Docs Classificação Query
Abrange os casos de uso de leitura (query) de dois módulos do sistema: Classificação Documental e Classificação da Informação.
A Classificação Documental trata de Plano de Classificação e Classes Documentais, e a manutenção desses dados é de responsabilidade do APEES (Arquivo Público do Estado do Espírito Santo).
A Classificação da Informação trata de aspectos da Lei de Acesso à Informação, como Fundamentos Legais para sigilo e informações classificadas (de nível reservado, secreto e ultrassecreto). A manutenção desses dados é de responsabilidade da SECONT (Secretaria de Controle e Transparência).
Acessa o banco de dados do E-Docs. Será descontinuado em breve, ainda em 2026.
EDA - E-Docs Document Analyzer
Contém a lógica de extração e sanitização do conteúdo de documentos PDF. Importante para cenários de busca e para uso futuro de IA no E-Docs.
Executa em um Hangfire dedicado, com base de dados própria. Trabalha com conceito de fila seguindo o Outbox Pattern. Também acessa o banco de dados do E-Docs.
Serviços de Dependências Tecnológicas
São serviços que concentram e padronizam a comunicação do E-Docs com tecnologias específicas, como bancos de dados orientados a documentos e armazenamento de objetos.
EEI - E-Docs Elastic Index 7
Responsável por incluir, alterar e excluir dados no índice do Elasticsearch 7, processo conhecido como indexação. Transforma os dados persistidos no banco de dados em um modelo de pesquisa e os envia ao Elasticsearch.
Não possui regras de negócio explícitas e não depende de outros serviços da arquitetura, apenas dos servidores Elasticsearch. Será substituído pelo EEI9 ainda em 2026.
EEQ - E-Docs Elastic Query 7
Concentra e encapsula toda a lógica de consulta ao Elasticsearch 7 em um único ponto da arquitetura. Contém todas as queries específicas no formato que o Elasticsearch entende, escritas com a biblioteca Nest, e é responsável por sua execução. O retorno é composto por primitivas ou por objetos que representam a estrutura de dados indexada no Elasticsearch.
Não possui regras de negócio explícitas e não depende de outros serviços da arquitetura, apenas dos servidores Elasticsearch, por isso precisa receber todos os parâmetros necessários para execução das queries. Será substituído pelo EEQ9 ainda em 2026.
EEI9 - E-Docs Elastic Index 9
Responsável por incluir, alterar e excluir dados no índice do Elasticsearch 9, processo conhecido como indexação. Transforma os dados persistidos no banco de dados em um modelo de pesquisa e os envia ao Elasticsearch.
Não possui regras de negócio explícitas e não depende de outros serviços da arquitetura.
Executa em um Hangfire dedicado, com base de dados própria. Trabalha com conceito de fila seguindo o Outbox Pattern. Acessa também o banco de dados do E-Docs, de onde lê os dados a serem indexados.
EEQ9 - E-Docs Elastic Query 9
Concentra e encapsula toda a lógica de consulta ao Elasticsearch 9 em um único ponto da arquitetura. Contém todas as queries específicas no formato que o Elasticsearch entende e é responsável por sua execução. O retorno é composto por primitivas ou por objetos que representam a estrutura de dados indexada no Elasticsearch.
Não possui regras de negócio explícitas e não depende de outros serviços da arquitetura, apenas dos servidores Elasticsearch, por isso precisa receber todos os parâmetros necessários para execução das queries.
EMM - E-Docs Minio Manager
Concentra e encapsula toda a lógica específica relacionada ao MinIO em um único ponto da arquitetura. Conhece todos os buckets utilizados pelo E-Docs e fornece a geração de URLs de acesso e escrita aos documentos, considerando questões de segurança como o tempo de expiração dos links.
Importante destacar que o EMM não recebe o arquivo em si: o upload dos arquivos é feito diretamente ao MinIO, usando sua API, pelos demais módulos.
Possui como única dependência externa o servidor MinIO.
Serviços Especialistas
São serviços com responsabilidades muito específicas, normalmente associadas a um tipo de processamento ou a uma integração particular.
DOC-M - E-Docs Document Models
Possui modelos de documentos padrão e fragmentos de páginas, usados na geração de diversos tipos de documentos no E-Docs. São exemplos de modelos:
- Página de Metadados de documento capturado
- Registro de Encaminhamento
- Termos de Autuação, Despacho e demais atos processuais
- Capa de Cópia de Processo
- Corpo de um Documento Elaborado via interface do E-Docs
A partir dos dados informados, preenche um determinado modelo e retorna o resultado em formato HTML, com trechos de CSS inline e eventuais imagens embutidas em formato Base64.
Este serviço torna a criação e a manutenção de modelos muito mais fácil e flexível, dada a utilização de HTML e CSS na formatação dos documentos, em contraste com bibliotecas tradicionais de construção de PDF.
P-AV - Processador Áudio e Vídeo
Processa e converte arquivos de áudio e vídeo para um formato padronizado, adequado ao armazenamento e ao uso pelo E-Docs.
Executa em um Hangfire dedicado, trabalhando com conceito de fila seguindo o Outbox Pattern. Acessa o banco de dados do E-Docs.
P-PDF - Processador de PDF
Responsável pelo processamento de arquivos PDF na nova arquitetura, executando operações como conversão, otimização e padronização dos arquivos.
E-Docs CDN
CDN (Content Delivery Network) usado pelo E-Docs para entregar imagens, scripts e estilos de forma rápida e independente da aplicação. Simplifica a manutenção e permite o reuso em futuras aplicações web.
E-Docs E-Flow API
Funciona como integração entre os sistemas E-Docs e E-Flow. Possui consultas dedicadas de definições e execuções de fluxos. Para isso, acessa a base de dados do E-Flow (não a do E-Docs).
Este módulo é mantido pelo time do E-Flow, e não pela equipe de desenvolvimento do E-Docs. Está listado aqui para fins de documentação e compreensão da arquitetura.
Resumo dos atributos arquiteturais
A tabela abaixo consolida quatro características técnicas dos módulos do E-Docs NA: uso de Hangfire dedicado para processamento em segundo plano, existência de base de dados própria, acesso ao banco de dados do E-Docs e adoção do padrão Outbox para enfileiramento de tarefas. É um resumo prático do que está descrito nas seções acima.
| Módulo | Possui API | Hangfire dedicado | Base própria | Acessa banco do E-Docs | Outbox Pattern |
|---|---|---|---|---|---|
| ENQ - Negócio Query | Sim | Sim | |||
| ENC - Negócio Command | Sim | Sim | |||
| ENB - Negócio Base | Sim | Sim | |||
| END - Negócio Dispatch | Sim | Sim | |||
| ENP - Negócio Process | Sim | Sim | Sim | Sim | |
| ENT - Negócio Tasks | Sim | Sim | |||
| EAQ - Agente Query | Sim | Sim | Sim | ||
| EAC - Agente Carga | Sim | Sim | Sim | ||
| EUM - Usuário Manager | Sim | Sim | |||
| ENO - Notificação Composer | Sim | Sim | Sim | Sim | |
| ECQ - Classificação Query | Sim | Sim | |||
| EDA - Document Analyzer | Sim | Sim | Sim | Sim | Sim |
| EEI - Elastic Index 7 | |||||
| EEQ - Elastic Query 7 | Sim | ||||
| EEI9 - Elastic Index 9 | Sim | Sim | Sim | Sim | |
| EEQ9 - Elastic Query 9 | Sim | ||||
| EMM - MinIO Manager | Sim | ||||
| DOC-M - Document Models | Sim | ||||
| P-AV - Processador Áudio e Vídeo | Sim | Sim | Sim | ||
| P-PDF - Processador de PDF | Sim | ||||
| E-Docs CDN | |||||
| E-Flow API | Sim | Não¹ |
¹ A E-Flow API acessa a base de dados do E-Flow (não a do E-Docs) para realizar suas consultas.
Dependências entre módulos
A tabela abaixo mapeia as dependências de chamadas entre os módulos do E-Docs (Clássico e NA). Cada linha representa um módulo consumidor; cada coluna, um módulo consumido. A marcação Sim indica que o módulo da linha utiliza, em pelo menos um caso de uso, o módulo da coluna.
Dependências de plataforma e infraestrutura (banco de dados, MinIO, Elasticsearch, Hangfire, OpenShift, sistemas estruturantes do Prodest) não estão representadas aqui: o foco é apenas em chamadas entre sistemas do E-Docs.
| Módulo | ENQ | ENC | ENB | ENP | EAQ | EUM | ENO | ECQ | EDA | EEI | EEQ | EEQ9 | EMM | DOC-M | P-AV | P-PDF | E-Flow | Gerador PDF |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Web | Sim | Sim | Sim | Sim | Sim | Sim | Sim | Sim | ||||||||||
| Api Pública | Sim | Sim | Sim | Sim | Sim | Sim | Sim | |||||||||||
| Background Jobs | Sim | Sim | Sim | Sim | Sim | Sim | Sim | Sim | ||||||||||
| Process Jobs | Sim | Sim | Sim | Sim | Sim | Sim | Sim | Sim | Sim | |||||||||
| DevArea | Sim | Sim | Sim | Sim | Sim | Sim | Sim | |||||||||||
| Test Area | Sim | Sim | Sim | Sim | Sim | Sim | ||||||||||||
| ENB | Sim | Sim | ||||||||||||||||
| ENC | Sim | Sim | ||||||||||||||||
| ENQ | Sim | Sim | Sim | Sim | Sim | Sim | Sim | |||||||||||
| END | Sim | Sim | Sim | Sim | Sim | Sim | Sim | |||||||||||
| ENP | Sim | Sim | Sim | Sim | ||||||||||||||
| EAQ | Sim | Sim | ||||||||||||||||
| EAC | Sim | Sim | ||||||||||||||||
| ECQ | Sim | Sim | ||||||||||||||||
| EDA | Sim | Sim | ||||||||||||||||
| ENO | Sim | Sim | Sim | Sim | ||||||||||||||
| EUM | Sim | |||||||||||||||||
| EEI | Sim | |||||||||||||||||
| EEI9 | Sim | Sim | Sim | |||||||||||||||
| EEQ9 | Sim | |||||||||||||||||
| Módulo | ENQ | ENC | ENB | ENP | EAQ | EUM | ENO | ECQ | EDA | EEI | EEQ | EEQ9 | EMM | DOC-M | P-AV | P-PDF | E-Flow | Gerador PDF |
Outras Soluções
Soluções complementares que compõem o ecossistema do E-Docs, mas que não fazem parte do núcleo de processamento do sistema.
Web Portal
Portal inicial do E-Docs, acessível em https://edocs.es.gov.br. Trata-se de um hotsite construído em Orchard, mantido pelo Arquivo Público (GESTAD).
Este hotsite é mantido pela Arquivo Público, e não pelo time de desenvolvimento do E-Docs. Está listado aqui para fins de documentação e compreensão do ecossistema.
Docs
Página de documentação do E-Docs, acessível em https://docs.e-docs.es.gov.br. Reúne informações sobre a arquitetura do sistema, o detalhamento dos serviços, as principais regras de negócio e outras informações relevantes.