Parte X — Anexos Técnicos
Parte X — Anexos TécnicosCapítulo 69
Capítulo 69 — Diagramas de Referência
Este capítulo consolida os diagramas arquiteturais canônicos da Plataforma de Relacionamento Digital com o Cidadão. Os diagramas seguem o modelo C4 nos níveis de Contexto (C1), Contêineres (C2) e Componentes (C3), comple…
69.1 Objetivo
Este capítulo consolida os diagramas arquiteturais canônicos da Plataforma de Relacionamento Digital com o Cidadão. Os diagramas seguem o modelo C4 nos níveis de Contexto (C1), Contêineres (C2) e Componentes (C3), complementados por diagramas de fluxo para os processos mais críticos e por um diagrama de implantação representando a topologia de infraestrutura.
O objetivo não é repetir descrições textuais já desenvolvidas nos capítulos de arquitetura, mas oferecer representações visuais de referência que um arquiteto possa utilizar diretamente como ponto de partida para decisões técnicas, avaliações de aderência e comunicação com equipes especializadas.
Todos os diagramas são descritos com precisão textual suficiente para reprodução formal em ferramentas como Structurizr, PlantUML, draw.io ou Mermaid. A linguagem visual adotada é a notação C4 Model — consistente com o padrão declarado no Capítulo 8 e utilizado ao longo de todo o Documento Mestre.
69.2 Contexto e Escopo dos Diagramas
Os diagramas deste capítulo cobrem os seguintes temas:
| # | Diagrama | Nível C4 | Capítulos de Referência |
|---|---|---|---|
| D01 | Contexto do Sistema (C1) — visão global | Contexto | 8, 11 |
| D02 | Contêineres da Plataforma (C2) — camadas e componentes | Contêineres | 11, 12 |
| D03 | Componentes do Backend — microsserviços de domínio (C3) | Componentes | 12 |
| D04 | Fluxo de Autenticação — IAM próprio e GOV.BR | Sequência | 17, 28, 43 |
| D05 | Fluxo de Solicitação de Serviço — jornada completa do cidadão | Sequência | 10, 12 |
| D06 | Arquitetura de Mensageria — tópicos e fluxos RabbitMQ | Componentes | 13 |
| D07 | Arquitetura de IA e RAG — pipeline de inteligência artificial | Componentes | 16 |
| D08 | Arquitetura de Dados — persistência, cache e Data Lake | Componentes | 15, 23 |
| D09 | Arquitetura de Segurança — camadas de controle Zero Trust | Componentes | 17, 42, 43 |
| D10 | Topologia de Implantação — Kubernetes, nós e namespaces | Implantação | 37, 38 |
| D11 | Fluxo DevSecOps — pipeline CI/CD com verificações de segurança | Processo | 40 |
| D12 | Multi-Tenancy — segregação lógica e propagação de contexto | Componentes | 30 |
69.3 D01 — Contexto do Sistema (C1)
69.3.1 Descrição
O diagrama de contexto apresenta a plataforma como uma caixa preta no centro, rodeada pelos atores externos e sistemas com os quais interage. Não detalha componentes internos — estabelece limites e relações externas.
69.3.2 Elementos
Sistema Central:
Plataforma de Relacionamento Digital com o Cidadão
[Sistema de Software]
Centraliza serviços digitais do Estado de Minas Gerais
para múltiplos órgãos públicos (multi-tenant)
Atores Externos:
| Ator | Tipo | Relação |
|---|---|---|
| Cidadão | Pessoa | Acessa serviços pelo Portal Web ou Aplicativo Mobile |
| Servidor Público / Atendente | Pessoa | Opera módulos de atendimento, análise e gestão |
| Administrador do Órgão (Tenant Admin) | Pessoa | Configura serviços, usuários e fluxos do órgão |
| Administrador da Plataforma | Pessoa | Gerencia tenants, infraestrutura e capacidades globais |
Sistemas Externos:
| Sistema | Tipo | Relação |
|---|---|---|
| GOV.BR | Sistema Externo | Provedor de identidade federada — OIDC/OAuth 2.0 |
| SEI!MG | Sistema Externo | Integração de processos e documentos SEI |
| Portal de Municípios | Sistema Externo | Canal de distribuição para municípios |
| PROBPMS | Sistema Externo | Integração BPM do Estado |
| Agenda Minas | Sistema Externo | Integração de agendamentos |
| SEG.ID | Sistema Externo | Identidade e segurança |
| MG API | Sistema Externo | Gateway de APIs do Estado |
| DATALAKE MG | Sistema Externo | Data Lake corporativo do Estado |
| MG-Ouv | Sistema Externo | Sistema de ouvidoria estadual |
| PRO SMTP | Sistema Externo | Serviço de e-mail transacional |
| Provedores LLM | Sistema Externo | Provedores de modelos de linguagem (via AI Gateway) |
69.3.3 Representação Textual
╔══════════════════════════════════════════════════════════════════════╗
║ ║
║ [Cidadão] [Atendente] [Admin Tenant] [Admin Plat.] ║
║ │ │ │ │ ║
║ └───────────────────┴──────────────────┴──────────────┘ ║
║ │ ║
║ ▼ ║
║ ┌────────────────────────────────────────────────────────┐ ║
║ │ │ ║
║ │ Plataforma de Relacionamento Digital │ ║
║ │ com o Cidadão │ ║
║ │ │ ║
║ │ Multi-tenant · Java/Spring Boot · React · K8s │ ║
║ └────────────────────────────────────────────────────────┘ ║
║ │ │ │ │ │ ║
║ ▼ ▼ ▼ ▼ ▼ ║
║ [GOV.BR] [SEI!MG] [MG API] [DATALAKE] [LLM Providers] ║
║ [MG-Ouv] [PRO SMTP] [Agenda] [SEG.ID] [Portal Municip] ║
║ ║
╚══════════════════════════════════════════════════════════════════════╝
69.4 D02 — Contêineres da Plataforma (C2)
69.4.1 Descrição
O diagrama de contêineres decompõe a plataforma nas suas unidades executáveis e camadas lógicas, mostrando como os canais de acesso, o backend e os sistemas de suporte se relacionam.
69.4.2 Camadas e Contêineres
Camada 1 — Canais
┌─────────────────────────────────────────────────────────────────┐
│ CANAIS DE ACESSO │
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ Portal Web │ │ App Mobile │ │
│ │ [React / TS] │ │ [React Native] │ │
│ │ SSR / SPA │ │ iOS · Android │ │
│ └────────┬─────────┘ └────────┬──────────┘ │
│ │ │ │
└───────────┼─────────────────────────┼────────────────────────────┘
│ HTTPS / REST / JWT │
Camada 2 — API Gateway
┌─────────────────────────────────────────────────────────────────┐
│ API GATEWAY │
│ │
│ Autenticação de Token · Resolução de Tenant · Rate Limiting │
│ Roteamento · Transformação de Requisições · Coleta de Métricas │
└─────────────────────────────────────────────────────────────────┘
Camada 3 — Identidade e Contexto
┌─────────────────────────────────────────────────────────────────┐
│ IAM (Identity & Access Management) │
│ │
│ IAM Próprio │ Federação GOV.BR │
│ (usuários, tenants, │ (OIDC / OAuth 2.0) │
│ perfis, sessões, │ │
│ tokens JWT) │ │
└─────────────────────────────────────────────────────────────────┘
Camada 4 — Serviços de Domínio
┌─────────────────────────────────────────────────────────────────┐
│ SERVIÇOS DE DOMÍNIO (24 microsserviços) │
│ │
│ [Identity] [Tenant] [Citizen] [Service Catalog] [Forms] │
│ [Request] [Workflow] [Task] [CRM] [Communication] │
│ [Document] [Scheduling] [Ombudsman] [Satisfaction] │
│ [Segmentation] [Campaign] [Analytics] [Data Quality] │
│ [Data Lake Ingestion] [AI Gateway] [AI Specialized] │
│ [Integration] [Configuration] [Audit] │
└─────────────────────────────────────────────────────────────────┘
Camadas de Suporte
┌───────────────┐ ┌───────────────┐ ┌───────────────┐ ┌────────────────┐
│ MENSAGERIA │ │ PERSISTÊNCIA │ │ CACHE │ │ BUSCA/VETORES │
│ [RabbitMQ] │ │ [PostgreSQL] │ │ [Redis] │ │ [Vector Store] │
│ Exchanges │ │ DB por domín.│ │ Por tenant │ │ RAG · Semântic.│
│ Filas │ │ Por tenant │ │ │ │ │
└───────────────┘ └───────────────┘ └───────────────┘ └────────────────┘
┌───────────────────────────────────────────────────────────────────────────┐
│ OBSERVABILIDADE │
│ OpenTelemetry · Logs Estruturados · Métricas Prometheus · Tracing Dist. │
└───────────────────────────────────────────────────────────────────────────┘
┌───────────────────────────────────────────────────────────────────────────┐
│ INFRAESTRUTURA │
│ Kubernetes · Docker · DevSecOps · CI/CD · Cloud / On-Premise │
└───────────────────────────────────────────────────────────────────────────┘
69.5 D03 — Componentes do Backend — Microsserviços de Domínio (C3)
69.5.1 Descrição
Apresenta os 24 serviços de domínio organizados em grupos funcionais, com suas dependências primárias e canais de comunicação (síncrono REST e assíncrono RabbitMQ).
69.5.2 Grupos e Serviços
╔══════════════════════════════════════════════════════════════════════════╗
║ GRUPO 1 — IDENTIDADE E CONTEXTO ║
║ ║
║ ┌─────────────────────┐ ┌──────────────────────┐ ║
║ │ Identity Service │ │ Tenant Service │ ║
║ │ Usuários · MFA │ │ Ciclo de vida tenant │ ║
║ │ Sessões · GOV.BR │ │ Módulos · Limites │ ║
║ │ Tokens JWT │ │ Domínios │ ║
║ └─────────────────────┘ └──────────────────────┘ ║
╠══════════════════════════════════════════════════════════════════════════╣
║ GRUPO 2 — NÚCLEO DE SERVIÇOS ║
║ ║
║ ┌──────────┐ ┌────────────────┐ ┌───────┐ ┌─────────┐ ║
║ │ Citizen │ │Service Catalog │ │ Forms │ │ Request │ ║
║ │ Service │ │ Service │ │Service│ │ Service │ ║
║ └──────────┘ └────────────────┘ └───────┘ └─────────┘ ║
║ ┌──────────┐ ┌────────┐ ┌─────┐ ┌──────────────────┐ ║
║ │ Workflow │ │ Task │ │ CRM │ │ Communication │ ║
║ │ Service │ │Service │ │Serv.│ │ Service │ ║
║ └──────────┘ └────────┘ └─────┘ └──────────────────┘ ║
║ ┌──────────────┐ ┌────────────┐ ┌──────────────────┐ ║
║ │ Document │ │ Scheduling │ │ Ombudsman │ ║
║ │ Service │ │ Service │ │ Service │ ║
║ └──────────────┘ └────────────┘ └──────────────────┘ ║
╠══════════════════════════════════════════════════════════════════════════╣
║ GRUPO 3 — RELACIONAMENTO E ENGAJAMENTO ║
║ ║
║ ┌──────────────┐ ┌───────────────┐ ┌──────────────────┐ ║
║ │ Satisfaction │ │ Segmentation │ │ Campaign │ ║
║ │ Service │ │ Service │ │ Service │ ║
║ └──────────────┘ └───────────────┘ └──────────────────┘ ║
╠══════════════════════════════════════════════════════════════════════════╣
║ GRUPO 4 — DADOS, IA E GOVERNANÇA ║
║ ║
║ ┌───────────┐ ┌──────────────┐ ┌──────────────────────┐ ║
║ │ Analytics │ │ Data Quality │ │ Data Lake Ingestion │ ║
║ │ Service │ │ Service │ │ Service │ ║
║ └───────────┘ └──────────────┘ └──────────────────────┘ ║
║ ┌───────────────────┐ ┌────────────────────────────┐ ║
║ │ AI Gateway │ │ AI Specialized Services │ ║
║ │ LLM · RAG · Embed.│ │ Copiloto · Roteamento │ ║
║ └───────────────────┘ └────────────────────────────┘ ║
╠══════════════════════════════════════════════════════════════════════════╣
║ GRUPO 5 — PLATAFORMA TRANSVERSAL ║
║ ║
║ ┌─────────────────┐ ┌─────────────────┐ ┌────────────────┐ ║
║ │ Integration │ │ Configuration │ │ Audit │ ║
║ │ Service │ │ Service │ │ Service │ ║
║ │ SEI!MG·MG API │ │ Flags·Feature │ │ Logs·Rastr. │ ║
║ └─────────────────┘ └─────────────────┘ └────────────────┘ ║
╚══════════════════════════════════════════════════════════════════════════╝
Comunicação entre grupos:
→ Síncrona (REST/HTTP): Request → Workflow, Forms → Document, CRM → Citizen
→ Assíncrona (RabbitMQ): Request, Workflow, Communication, Analytics, Data Lake
→ Cache (Redis): Tenant Context, Service Catalog, Citizen Profile parcial
69.6 D04 — Fluxo de Autenticação — IAM Próprio e GOV.BR
69.6.1 Fluxo IAM Próprio
Cidadão Portal Web API Gateway IAM Service
│ │ │ │
│── e-mail + senha ────►│ │ │
│ │── POST /auth/login ►│ │
│ │ │── valida token ─────►│
│ │ │ │── busca usuário
│ │ │ │── valida senha (Argon2)
│ │ │ │── verifica MFA?
│ │ │◄─ JWT (access+refresh)│
│◄── sessão estabelecida│◄── token seguro ────│ │
│ │ │ │
│── requisição recurso ►│ │ │
│ │── GET /api/... ────►│ │
│ │ valida JWT, resolve tenant │
│ │ verifica permissão │
│ │──────────── roteia para serviço ──────────►│
│◄── resposta ──────────│◄──────────────────────────────────────────│
69.6.2 Fluxo GOV.BR (Authorization Code + PKCE)
Cidadão Portal Web IAM Service GOV.BR
│ │ │ │
│── "Entrar GOV.BR"►│ │ │
│ │── inicia OIDC ──►│ │
│ │ │── redirect ────────►│
│◄── redirect ──────│◄─────────────────│ │
│ │ │ │
│──────────────────────────── autentica no GOV.BR ──────────►│
│◄──────────────────────── authorization_code ───────────────│
│ │ │ │
│── retorna com code►│ │ │
│ │── troca code ───►│ │
│ │ │── token request ───►│
│ │ │◄── ID Token+Access──│
│ │ │ extrai sub (estável) │
│ │ │ localiza/cria vínculo│
│ │ │ emite JWT plataforma │
│◄── sessão OK ─────│◄── JWT ──────────│ │
69.7 D05 — Fluxo de Solicitação de Serviço — Jornada Completa do Cidadão
Cidadão Portal Web API Gateway Request Svc Workflow Svc Communication Svc
│ │ │ │ │ │
│─ busca serviço►│ │ │ │ │
│ │── GET catalog ►│ │ │ │
│◄─ lista serviços│◄──────────────│ │ │ │
│ │ │ │ │ │
│─ seleciona svc ►│ │ │ │ │
│◄─ detalhe svc ──│ │ │ │ │
│ │ │ │ │ │
│─ preenche form.►│ │ │ │ │
│─ anexa docs ───►│ │ │ │ │
│─ submete ──────►│ │ │ │ │
│ │──POST /requests►│ │ │ │
│ │ │─ valida token ┤ │ │
│ │ │─ resolve tenant │ │
│ │ │──────────────►│ │ │
│ │ │ │─ cria Request│ │
│ │ │ │─ gera número │ │
│ │ │ │ protocolo │ │
│ │ │ │── publica evento ─────────────►│
│ │ │ │ request.created.v1 │
│ │ │ │ │◄─ consome evento│
│ │ │ │ │─ inicia workflow │
│ │ │ │ │─ cria tarefas │
│◄─ protocolo ───│◄───────────────│◄──────────────│ │ │
│ │ │ │ │── notificação──►│
│ │ │ │ │ (e-mail/push) │
│ │ │ │ │
│ ... dias depois ... │ │ │ │
│─ acompanha ────►│ │ │ │ │
│ │── GET /requests/{id} ──────────►│ │ │
│◄─ status atual─│◄──────────────────────────────│ │ │
69.8 D06 — Arquitetura de Mensageria — Tópicos e Fluxos RabbitMQ
69.8.1 Topologia de Exchanges
┌─────────────────────────────────────────────────────────────────────────┐
│ RABBITMQ BROKER │
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Exchange: platform.domain.events [topic] │ │
│ │ │ │
│ │ Routing Keys (exemplos): │ │
│ │ citizen.created.v1 │ │
│ │ request.created.v1 · request.status-changed.v1 │ │
│ │ workflow.task-assigned.v1 · workflow.completed.v1 │ │
│ │ document.uploaded.v1 · document.validated.v1 │ │
│ │ tenant.activated.v1 · tenant.suspended.v1 │ │
│ │ communication.send-requested.v1 │ │
│ │ analytics.ingestion-requested.v1 │ │
│ └────────────────────────────┬────────────────────────────────────┘ │
│ │ binding por routing key │
│ ┌────────────────────────┼──────────────────────┐ │
│ │ │ │ │
│ ┌────▼────────┐ ┌──────────▼──────┐ ┌─────────▼───────┐ │
│ │ workflow.q │ │ communication.q │ │ analytics.q │ │
│ │ (Workflow │ │ (Communication │ │ (Analytics/ │ │
│ │ Service) │ │ Service) │ │ Data Lake) │ │
│ └─────────────┘ └─────────────────┘ └─────────────────┘ │
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Exchange: platform.dlx [direct] (Dead Letter Exchange) │ │
│ │ Filas de reprocessamento e alertas de mensagens não entregues │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ Padrão Transactional Outbox em todos os produtores │
│ Idempotência garantida em todos os consumidores │
│ Envelope obrigatório: tenantId · eventId · correlationId · version │
└─────────────────────────────────────────────────────────────────────────┘
69.8.2 Fluxo de Publicação com Outbox
Serviço Produtor (ex.: Request Service)
│
├─ Escreve registro de negócio no banco (ex.: Request)
├─ Escreve evento na tabela outbox (mesma transação)
│ (atomicidade garantida)
│
Outbox Relay Worker
├─ Lê eventos pendentes na tabela outbox
├─ Publica no exchange RabbitMQ
└─ Marca evento como publicado
69.9 D07 — Arquitetura de IA e RAG
69.9.1 Pipeline de Inteligência Artificial
┌─────────────────────────────────────────────────────────────────────────┐
│ PLATAFORMA DE IA │
│ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ AI GATEWAY (LLM Abstraction Layer) │ │
│ │ · Roteia para provedores LLM (tecnologicamente neutro) │ │
│ │ · Controla quotas e metering por tenant │ │
│ │ · Aplica políticas de segurança e filtros de conteúdo │ │
│ │ · Registra logs de uso, latência e tokens consumidos │ │
│ └──────────────────────────┬───────────────────────────────────────┘ │
│ │ │
│ ┌─────────────────┼─────────────────┐ │
│ │ │ │ │
│ ┌─────────▼──────┐ ┌───────▼──────┐ ┌──────▼──────────┐ │
│ │ Copiloto │ │ RAG Engine │ │ Roteamento │ │
│ │ (@brasfy/core │ │ Retrieval │ │ Semântico │ │
│ │ /assistente) │ │ Augmented │ │ (rotear, │ │
│ │ │ │ Generation │ │ EXEMPLOS) │ │
│ └────────────────┘ └───────┬──────┘ └─────────────────┘ │
│ │ │
│ ┌──────────▼──────────┐ │
│ │ Vector Store │ │
│ │ (Banco Vetorial) │ │
│ │ Isolado por tenant │ │
│ │ Embeddings + ANN │ │
│ └──────────┬──────────┘ │
│ │ │
│ ┌──────────▼──────────┐ │
│ │ Base de Conhecimento│ │
│ │ por Tenant │ │
│ │ (documentos, │ │
│ │ FAQs, processos) │ │
│ └─────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────┘
Fluxo RAG:
Pergunta do Cidadão
│
Geração de Embedding
│
Busca Vetorial (top-K no contexto do tenant)
│
Recuperação de Chunks Relevantes
│
Montagem do Prompt Aumentado (contexto + pergunta)
│
Chamada ao LLM via AI Gateway
│
Resposta Gerada
│
Pós-processamento e Filtros de Segurança
│
Entrega ao Cidadão
69.10 D08 — Arquitetura de Dados — Persistência, Cache e Data Lake
┌─────────────────────────────────────────────────────────────────────────┐
│ CAMADA DE DADOS │
│ │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ PERSISTÊNCIA OPERACIONAL — PostgreSQL │ │
│ │ │ │
│ │ Cada microsserviço controla seu próprio banco/schema │ │
│ │ (decisão de segregação registrada em ADR-001 e ADR-004) │ │
│ │ │ │
│ │ [identity_db] [tenant_db] [citizen_db] [request_db] │ │
│ │ [workflow_db] [document_db] [crm_db] [communication_db] │ │
│ │ [scheduling_db] [ombudsman_db] [analytics_db] [audit_db] │ │
│ │ [ai_db] [integration_db] [configuration_db] │ │
│ │ │ │
│ │ Isolamento por tenant via schema ou particionamento (ADR-001) │ │
│ └────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ CACHE DISTRIBUÍDO — Redis │ │
│ │ │ │
│ │ · Contexto de tenant (resolução frequente sem hit no banco) │ │
│ │ · Catálogo de serviços por tenant (TTL configurável) │ │
│ │ · Sessões de usuário (complementar ao IAM) │ │
│ │ · Resultados de busca e fragmentos de IA (resposta rápida) │ │
│ │ · Rate limiting (contadores por chave) │ │
│ │ │ │
│ │ Namespace por tenant obrigatório: tenant:{id}:... │ │
│ │ Política fail-open ou fail-closed por criticalidade do dado │ │
│ └────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ BUSCA E VETORES │ │
│ │ │ │
│ │ · Banco Vetorial: embeddings por tenant, isolamento garantido │ │
│ │ · Busca semântica: ANN (Approximate Nearest Neighbor) │ │
│ │ · Indexação de documentos e FAQs por tenant │ │
│ └────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ DATA LAKE (Segregado por Tenant) │ │
│ │ │ │
│ │ Zona Raw → Zona Curated → Zona Analytical │ │
│ │ (ingestão por eventos RabbitMQ via Data Lake Ingestion Svc) │ │
│ │ │ │
│ │ Integração: DATALAKE MG (ecossistema estadual) │ │
│ │ Analytics, BI e Dashboards consomem zona analytical │ │
│ └────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────┘
69.11 D09 — Arquitetura de Segurança — Camadas de Controle Zero Trust
┌─────────────────────────────────────────────────────────────────────────┐
│ MODELO ZERO TRUST — CAMADAS DE CONTROLE │
│ │
│ Requisição inbound │
│ │ │
│ ┌────▼─────────────────────────────────────────────────────────────┐ │
│ │ CAMADA 1 — PERÍMETRO / TLS │ │
│ │ TLS 1.3 obrigatório · Certificados gerenciados │ │
│ │ WAF · DDoS mitigation · Bloqueio de IPs maliciosos │ │
│ └────┬─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────▼─────────────────────────────────────────────────────────────┐ │
│ │ CAMADA 2 — API GATEWAY │ │
│ │ Validação de JWT · Extração de tenant · Rate limiting │ │
│ │ Roteamento seguro · Logging de acesso │ │
│ └────┬─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────▼─────────────────────────────────────────────────────────────┐ │
│ │ CAMADA 3 — IAM / AUTORIZAÇÃO │ │
│ │ Verificar identidade · Verificar credencial · Verificar tenant │ │
│ │ Avaliar permissão · Verificar escopo do recurso │ │
│ └────┬─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────▼─────────────────────────────────────────────────────────────┐ │
│ │ CAMADA 4 — SERVIÇO DE DOMÍNIO │ │
│ │ Re-verificação de autorização (dupla checagem) │ │
│ │ Aplicação de tenant context estrutural │ │
│ │ Validação de input · Sanitização │ │
│ └────┬─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────▼─────────────────────────────────────────────────────────────┐ │
│ │ CAMADA 5 — PERSISTÊNCIA │ │
│ │ Filtro estrutural de tenant em repositórios │ │
│ │ Criptografia em repouso (AES-256) para dados sensíveis │ │
│ │ TLS em trânsito (banco → serviço) │ │
│ └────┬─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ┌────▼─────────────────────────────────────────────────────────────┐ │
│ │ CAMADA TRANSVERSAL — AUDITORIA E OBSERVABILIDADE │ │
│ │ Audit Service: registra toda operação sensível │ │
│ │ Logs estruturados: tenantId · userId · correlationId · ação │ │
│ │ Alertas em tempo real para eventos de segurança │ │
│ └─────────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────┘
69.12 D10 — Topologia de Implantação — Kubernetes
┌─────────────────────────────────────────────────────────────────────────┐
│ CLUSTER KUBERNETES │
│ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ Namespace: platform-ingress │ │
│ │ Ingress Controller · TLS Termination · WAF │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ Namespace: platform-gateway │ │
│ │ API Gateway Pods (N réplicas) · Rate Limiter │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ Namespace: platform-identity │ │
│ │ IAM Service Pods · GOV.BR Adapter │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ Namespace: platform-core │ │
│ │ 24 microsserviços de domínio (Deployments) │ │
│ │ HPA (Horizontal Pod Autoscaler) por serviço │ │
│ │ ConfigMaps + Secrets por serviço │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ Namespace: platform-infra │ │
│ │ RabbitMQ Cluster · Redis Cluster · PostgreSQL (StatefulSets) │ │
│ │ Vector Store · MinIO/Object Storage │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ Namespace: platform-observability │ │
│ │ OpenTelemetry Collector · Prometheus · Alertmanager │ │
│ │ Log Aggregation · Tracing Backend │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ Namespace: platform-ai │ │
│ │ AI Gateway · RAG Engine · Embedding Workers │ │
│ │ AI Specialized Services │ │
│ └──────────────────────────────────────────────────────────────────┘ │
│ │
│ Network Policies: comunicação entre namespaces controlada por policy │
│ RBAC: service accounts com menor privilégio por namespace │
│ PodSecurityContext: non-root, read-only root filesystem │
└─────────────────────────────────────────────────────────────────────────┘
Ambientes: development · integration · homologation · production
Estratégia de deploy: rolling update (padrão) · blue-green · canary
69.13 D11 — Fluxo DevSecOps — Pipeline CI/CD
Developer Git / SCM Pipeline CI/CD Ambientes
│ │ │ │
│── commit / PR ─────────►│ │ │
│ │── trigger ────────►│ │
│ │ │ │
│ │ ┌───────▼──────────┐ │
│ │ │ FASE: BUILD │ │
│ │ │ Compile · Test │ │
│ │ │ Unit Tests │ │
│ │ └───────┬──────────┘ │
│ │ │ │
│ │ ┌───────▼──────────┐ │
│ │ │ FASE: SECURITY │ │
│ │ │ SAST (análise │ │
│ │ │ estática) │ │
│ │ │ SCA (depend.) │ │
│ │ │ Secret scanning │ │
│ │ └───────┬──────────┘ │
│ │ │ │
│ │ ┌───────▼──────────┐ │
│ │ │ FASE: CONTAINER │ │
│ │ │ Docker build │ │
│ │ │ Image scanning │ │
│ │ │ SBOM generation │ │
│ │ │ Image signing │ │
│ │ └───────┬──────────┘ │
│ │ │ │
│ │ ┌───────▼──────────┐ │
│ │ │ FASE: QUALITY │ │
│ │ │ Integr. Tests │ │
│ │ │ Coverage gate │ │
│ │ │ API contract │ │
│ │ └───────┬──────────┘ │
│ │ │ │
│ │ │── deploy ─────────────►│ Integration
│ │ │── deploy ─────────────►│ Homologation
│◄── aprovação requerida ─│◄────────────────── │ │
│── aprova ──────────────►│ │── deploy ─────────────►│ Production
│ │ │ (rolling / canary) │
69.14 D12 — Multi-Tenancy — Segregação e Propagação de Contexto
┌─────────────────────────────────────────────────────────────────────────┐
│ MODELO MULTI-TENANT │
│ │
│ Tenant A (Órgão Estadual) Tenant B (Município X) │
│ │
│ Usuários A Usuários B │
│ Cidadãos A Cidadãos B │
│ Serviços A Serviços B │
│ Processos A Processos B │
│ Documentos A Documentos B │
│ Base RAG A Base RAG B │
│ Data Lake A Data Lake B │
│ │ │ │
│ └──────────────┬───────────────┘ │
│ │ Plataforma Compartilhada │
│ │ │
│ PROPAGAÇÃO DO CONTEXTO DE TENANT: │
│ │
│ 1. Entrada: domínio HTTP ou JWT contém tenantId │
│ 2. API Gateway: extrai e valida tenant ativo │
│ 3. IAM: confirma vínculo usuário→tenant │
│ 4. Thread Context: tenantId propagado em toda a thread de execução │
│ 5. Repository: filtro estrutural aplica WHERE tenant_id = :tenant │
│ 6. Cache: namespace prefixado por tenant (tenant:{id}:chave) │
│ 7. RabbitMQ: envelope de evento contém tenantId obrigatório │
│ 8. Data Lake: partição correspondente ao tenant │
│ 9. Vector Store: coleção isolada por tenant │
│ 10. Audit Log: tenantId registrado em toda entrada de auditoria │
│ │
│ NENHUMA OPERAÇÃO OCORRE SEM TENANT CONTEXT ESTABELECIDO │
│ TENANT NÃO É ACEITO COMO PARÂMETRO DO CLIENTE — É DERIVADO │
│ DA IDENTIDADE AUTENTICADA OU DO CANAL CONTROLADO │
└─────────────────────────────────────────────────────────────────────────┘
69.15 Padrões de Notação Adotados
Os diagramas deste capítulo adotam as seguintes convenções:
| Elemento | Notação |
|---|---|
| Sistema externo | Caixa com bordas arredondadas rotulada [Sistema Externo] |
| Contêiner de software | Caixa retangular com tecnologia entre colchetes |
| Ator humano | Rotulado sem caixa ou entre [Pessoa] |
| Comunicação síncrona REST | Seta sólida ──► com protocolo (HTTP/REST/JWT) |
| Comunicação assíncrona | Seta tracejada ──► com tópico/evento |
| Agrupamento lógico | Caixa externa delimitada com título |
| Decisão | Losango ou bifurcação com ├─ Sim / └─ Não |
| Processo sequencial | Numeração ou seta vertical descendente |
| Banco de dados | Indicado entre colchetes com tecnologia |
| Isolamento de tenant | Prefixo tenant:{id}: ou nota explícita |
Os diagramas são complementares ao texto dos capítulos de origem e não substituem as especificações técnicas detalhadas contidas nos respectivos capítulos.
69.16 Instruções para Reprodução em Ferramentas
Os diagramas textuais deste capítulo foram elaborados para máxima legibilidade no documento escrito. Para reprodução em ferramentas formais de diagramação, recomenda-se:
Structurizr DSL — para diagramas C4 (D01, D02, D03, D12): utilizar o workspace DSL com as entidades softwareSystem, container, component e relacionamentos com ->. Aplicar tag [external] para sistemas externos.
PlantUML — para diagramas de sequência (D04, D05): usar notação @startuml com participant, actor e ->>/--> para síncrono e assíncrono.
draw.io / Mermaid — para diagramas de fluxo (D06, D07, D08, D09, D11): draw.io com shapes C4 disponíveis na biblioteca pública; Mermaid com graph TD para topologias e sequenceDiagram para fluxos.
Diagrama de implantação (D10) — reproduzir com shapes de Kubernetes no draw.io ou com extensão de notação C4 para deployment diagrams.
69.17 Rastreabilidade PRODEMGE
Edital CP 001/2026:
- Item 3.1 — Diagramas documentam a arquitetura da solução proposta para avaliação técnica.
Plano de Negócio (Anexo I):
- Seção 3.1 — Diagramas de contexto (D01) e contêineres (D02) evidenciam a plataforma como produto original com arquitetura coerente.
Funcionalidades (Anexo III):
- Bloco 1 (Relacionamento): D05 documenta a jornada de solicitação de serviço.
- Bloco 2 (BPM): D05 inclui o Workflow Service no fluxo.
- Bloco 3 (GED): D08 documenta a camada de persistência e documentos.
- Bloco 4 (Dados e IA): D07 documenta a arquitetura de IA e RAG; D08 o Data Lake.
- Bloco 5 (Integração): D01 documenta todos os sistemas externos integrados.
- Bloco 6 (Infraestrutura e Segurança): D09 e D10 documentam segurança e implantação.
Capacidades (Anexo IV):
- Multi-tenancy: D12 documenta a propagação de contexto e segregação.
- IAM e GOV.BR: D04 documenta os fluxos de autenticação.
- Microsserviços: D03 documenta os 24 serviços de domínio.
- IA: D07 documenta o pipeline de IA e RAG.
- DevSecOps: D11 documenta o pipeline CI/CD com verificações de segurança.
- Infraestrutura: D10 documenta a topologia Kubernetes.
Sustentabilidade (Anexo V):
- D10 evidencia a capacidade de implantação em cloud e on-premise.
- D11 evidencia DevSecOps como prática integrada, não add-on.
- D12 evidencia que a segregação de tenant está na arquitetura, não em políticas manuais.
Esclarecimentos pertinentes:
- Montreal (02/07/2026) — D12 confirma a segregação lógica multi-tenant com propagação estrutural de contexto.
- Valtech (03/07/2026) — D03 confirma os 24 serviços de domínio como capacidade técnica da solução.
- WideLabs (04/07/2026) — D07 e D04 confirmam a arquitetura de IA e os fluxos de autenticação.
Erratas:
- Errata nº 002 (10/07/2026) — Não aplicável a este capítulo.
69.18 Resumo
O Capítulo 69 apresenta doze diagramas de referência que cobrem as visões arquiteturais essenciais da plataforma: contexto sistêmico, decomposição em contêineres, organização dos microsserviços de domínio, fluxos de autenticação, jornada completa de solicitação de serviço, topologia de mensageria, pipeline de IA, arquitetura de dados, modelo de segurança Zero Trust, topologia Kubernetes, pipeline DevSecOps e modelo de multi-tenancy.
Os diagramas são canônicos — representam o estado de design aprovado da plataforma — e servem como referência única para consulta rápida por qualquer membro técnico da equipe ou avaliador da PRODEMGE, sem necessidade de navegação pelos capítulos detalhados.
69.19 Próximo Capítulo
O Capítulo 70 — Modelo de Dados apresenta o modelo entidade-relacionamento dos principais domínios da plataforma, com dicionário de entidades, atributos relevantes, chaves e relacionamentos, complementando os contratos de API descritos no Capítulo 71.
69.20 Controle de Versão
| Campo | Valor |
|---|---|
| Documento | Documento Mestre — Plataforma de Relacionamento Digital com o Cidadão |
| Capítulo | 69 — Diagramas de Referência |
| Versão | 1.0 |
| Situação | Concluído |
| Última atualização | 17/07/2026 |
| Status de Aprovação | Aprovado |
Capítulo 68 — Glossário Expandido
Este capítulo consolida e expande o glossário técnico e de negócio da Plataforma de Relacionamento Digital com o Cidadão. O objetivo é fornecer definições precisas, unívocas e contextualizadas para todos os termos utiliz…
Capítulo 70 — Modelo de Dados
Este capítulo apresenta o modelo de dados da Plataforma de Relacionamento Digital com o Cidadão. O objetivo é documentar as principais entidades de cada domínio, seus atributos relevantes, chaves, relacionamentos e invar…