Capítulo 8 — Arquitetura Corporativa

8.1 Objetivo do Capítulo

Este capítulo apresenta a Arquitetura Corporativa da Plataforma de Relacionamento Digital com o Cidadão, consolidando a visão de negócio, aplicações, dados, integrações, segurança e infraestrutura que orienta o desenvolvimento e a evolução da solução ao longo da parceria.

A arquitetura corporativa não representa apenas a organização técnica dos componentes. Ela estabelece como as capacidades institucionais, os processos, as aplicações e os dados atuam conjuntamente para viabilizar uma plataforma pública digital modular, interoperável, multi-tenant e evolutiva.

Este capítulo opera na camada C1 do C4 Model — a visão de contexto e de sistema. Os detalhamentos em C2 (contêineres), C3 (componentes) e C4 (código) são apresentados nos capítulos específicos correspondentes.

8.2 Visão Corporativa da Plataforma

A Plataforma de Relacionamento Digital com o Cidadão é organizada como um ecossistema digital que conecta:

• cidadãos e empresas que utilizam serviços públicos;
• servidores e atendentes que operam os módulos da plataforma;
• gestores que acompanham indicadores e administram configurações;
• administradores que gerenciam a plataforma globalmente;
• sistemas governamentais que integram informações;
• canais de comunicação externos;
• componentes de inteligência artificial;
• repositórios documentais;
• processos administrativos digitais;
• dados operacionais e analíticos por tenant.

A solução combina, de forma integrada, capacidades de CRM, BPM, ECM/GED, comunicação omnichannel, analytics, inteligência artificial, gestão de APIs e administração multi-tenant, atendendo múltiplos órgãos públicos por meio de uma arquitetura compartilhada com isolamento completo entre tenants.

8.3 Visão de Contexto (C4 — Nível 1)

A visão de contexto identifica os atores externos e os sistemas que interagem diretamente com a plataforma.

┌──────────────────────────────────────────────────────────────────────┐
│                        ATORES EXTERNOS                               │
│                                                                      │
│  [Cidadão]   [Empresa]   [Atendente]   [Gestor]   [Administrador]  │
│      │           │            │             │              │         │
│      ▼           ▼            ▼             ▼              ▼         │
│  Portal Web  Portal Web  Painel Gestor  Painel Gestor  Painel Gestor│
│  App Mobile  App Mobile                                              │
└──────────────────────────┬───────────────────────────────────────────┘
                           │
                           ▼
┌──────────────────────────────────────────────────────────────────────┐
│         PLATAFORMA DE RELACIONAMENTO DIGITAL COM O CIDADÃO           │
│                                                                      │
│  Canais  │  IAM + GOV.BR  │  Domínios de Negócio  │  IA  │  Dados  │
└──────────────────────────┬───────────────────────────────────────────┘
                           │
          ┌────────────────┼──────────────────┐
          ▼                ▼                  ▼
    [GOV.BR]       [Sistemas              [Canais de
                  Governamentais]         Comunicação]
                  SEI!MG, MG API,        E-mail, SMS,
                  MG-Ouv, Data Lake MG,  Push, WhatsApp
                  SEG.ID, PRO SMTP,
                  Agenda Minas, etc.

Descrição Textual

O cidadão acessa a plataforma pelo Portal Web ou pelo aplicativo mobile. Empresas utilizam os mesmos canais. Usuários internos, gestores e administradores acessam o Painel do Gestor com permissões determinadas pelo IAM próprio.

A autenticação do cidadão ocorre por dois mecanismos: IAM próprio da plataforma (com usuário, senha e perfis por tenant) ou autenticação federada via GOV.BR (OpenID Connect), com perfil do cidadão mantido internamente após a autenticação bem-sucedida.

A plataforma integra sistemas governamentais do ecossistema estadual — SEI!MG, MG API, MG-Ouv, Data Lake MG, SEG.ID, PRO SMTP, Portal de Municípios, Agenda Minas e sistemas de trânsito — e canais externos de comunicação — e-mail, SMS, push e WhatsApp.

8.4 Macrocamadas da Arquitetura

A arquitetura corporativa é organizada em sete macrocamadas lógicas com responsabilidades claramente delimitadas.

┌──────────────────────────────────────────────────────────────────────┐
│  CAMADA 1 — CANAIS E EXPERIÊNCIA                                     │
│  Portal Web  │  App Mobile  │  Painel do Gestor  │  Canais Externos  │
├──────────────────────────────────────────────────────────────────────┤
│  CAMADA 2 — ACESSO, IDENTIDADE E CONTEXTO                           │
│  IAM Próprio  │  GOV.BR  │  Tenant Context  │  Perfis  │  Sessões   │
├──────────────────────────────────────────────────────────────────────┤
│  CAMADA 3 — CAPACIDADES DE NEGÓCIO (DOMÍNIOS)                       │
│  Cidadão │ Catálogo │ Solicitações │ BPM │ CRM │ Comunicação        │
│  Documentos │ Agendamentos │ Ouvidoria │ Satisfação │ Segmentação   │
├──────────────────────────────────────────────────────────────────────┤
│  CAMADA 4 — SERVIÇOS CORPORATIVOS TRANSVERSAIS                      │
│  Auditoria  │  Notificações  │  Arquivos  │  Busca  │  Configuração │
├──────────────────────────────────────────────────────────────────────┤
│  CAMADA 5 — ORQUESTRAÇÃO, MENSAGERIA E INTEGRAÇÃO                   │
│  API Gateway  │  RabbitMQ  │  Adaptadores  │  Conectores            │
├──────────────────────────────────────────────────────────────────────┤
│  CAMADA 6 — DADOS E INTELIGÊNCIA                                     │
│  Bancos Operacionais  │  Cache  │  Busca  │  Vetores  │  IA         │
│  Data Lake por Tenant                                                │
├──────────────────────────────────────────────────────────────────────┤
│  CAMADA 7 — INFRAESTRUTURA, SEGURANÇA E OBSERVABILIDADE             │
│  Containers  │  Kubernetes  │  Logs  │  Métricas  │  Traces         │
│  DevSecOps   │  Alertas     │  Auditoria de Segurança               │
└──────────────────────────────────────────────────────────────────────┘

Cada camada possui interfaces controladas com as camadas adjacentes, evitando dependências indevidas que comprometam a evolução independente dos componentes.

8.5 Princípio de Separação entre Canais e Regras de Negócio

Os canais — Portal Web (React), Painel do Gestor (React) e aplicativo mobile (React Native) — são responsáveis exclusivamente pela apresentação e experiência do usuário. Regras de negócio, persistência, segurança e integrações residem no backend Java com Spring Boot.

8.6 Arquitetura dos Canais

8.6.1 Portal Web do Cidadão

Aplicação React que disponibiliza ao cidadão as jornadas de autoatendimento digital. Cobre catálogo de serviços, criação e acompanhamento de solicitações, documentos, agendamentos, mensagens, ouvidoria, assistente virtual e gestão de dados pessoais.

O portal consome APIs REST do backend e comunica-se com o IAM para autenticação por credencial própria ou via GOV.BR.

8.6.2 Aplicativo Mobile

Aplicação React Native disponível para iOS e Android. Oferece as mesmas jornadas do portal web com adaptações de experiência para dispositivos móveis, incluindo captura de documentos por câmera, notificações push e uso de biometria local para autenticação.

O aplicativo consome os mesmos contratos de backend do Portal Web, sem duplicação de regras de negócio.

8.6.3 Painel do Gestor

Aplicação React destinada a atendentes, analistas, gestores e administradores. Oferece operação dos módulos de atendimento, BPM, CRM, gestão documental, comunicação, analytics, administração do tenant e monitoramento.

As permissões de acesso ao painel são determinadas pelo IAM próprio conforme o perfil e o tenant do usuário. A ocultação visual de um recurso não é considerada controle de segurança suficiente — toda operação é re-autorizada pelo backend.

8.6.4 Canais Externos de Comunicação

A plataforma integra canais externos como adaptadores desacoplados: e-mail transacional (PRO SMTP ou equivalente), SMS, notificações push e WhatsApp Business. Nenhuma regra de negócio reside nos adaptadores de canal.

8.7 Arquitetura de Identidade e Contexto

8.7.1 IAM Próprio

O IAM próprio da plataforma gerencia:

• cadastro e configuração de tenants;
• usuários internos com credenciais próprias;
• políticas de senha, sessão e recuperação de acesso;
• perfis, papéis e permissões por tenant;
• vínculo entre usuário, tenant e unidade organizacional;
• consentimentos e auditoria de autenticação.

8.7.2 Integração com GOV.BR

O GOV.BR atua como provedor de identidade federada, prioritariamente para cidadãos. O fluxo segue o protocolo OpenID Connect. Após autenticação bem-sucedida, a plataforma mantém internamente o vínculo entre a identidade GOV.BR, o perfil do cidadão no tenant, os consentimentos associados e o histórico de autenticações.

A autorização é sempre responsabilidade da plataforma. O GOV.BR confirma identidade; o IAM próprio determina o que o usuário pode executar.

8.7.3 Contexto Obrigatório de Tenant

Toda operação na plataforma ocorre sob um contexto de tenant validado. O tenant não é aceito como parâmetro informado pelo cliente — é determinado a partir da identidade autenticada, do domínio acessado ou de outro mecanismo controlado pela plataforma.

8.8 Arquitetura Multi-Tenant

A plataforma é multi-tenant nativa. Diferentes órgãos utilizam os mesmos componentes tecnológicos com segregação completa de dados, configurações, usuários, processos e regras.

O tenant é o limite organizacional primário. Cada tenant possui:

• identificação e configurações próprias;
• identidade visual personalizada;
• catálogo de serviços próprio;
• usuários internos, perfis e permissões isolados;
• cidadãos vinculados ao contexto do órgão;
• processos, documentos e integrações próprios;
• indicadores e dados analíticos segregados;
• base de conhecimento de IA isolada;
• contexto, quotas e métricas de IA próprios;
• partição correspondente no Data Lake.

Segregação de Dados

Um tenant não acessa dados de outro, incluindo consultas operacionais, documentos, mensagens, índices de busca, vetores, cache, eventos, logs de negócio, dados analíticos e bases de RAG.

Estratégia Física de Segregação

A decisão entre banco por tenant, schema por tenant, particionamento lógico ou modelo híbrido é registrada como ADR-001, considerando isolamento, custo operacional, volumetria e escalabilidade.

8.9 Arquitetura de Domínios de Negócio

A plataforma organiza suas capacidades em domínios de negócio com responsabilidades claras e limites estáveis. A decomposição técnica definitiva em microsserviços é detalhada no Capítulo 12.

8.10 Arquitetura de Comunicação

Comunicação Síncrona (APIs REST)

Utilizada quando o resultado é necessário imediatamente para concluir a operação: autenticação, consulta ao catálogo, abertura e consulta de solicitações, carregamento de documentos, consulta de agenda, comandos administrativos e respostas imediatas do assistente de IA.

As APIs são documentadas com OpenAPI e versionadas. Detalhamento no Capítulo 14.

Comunicação Assíncrona (RabbitMQ)

Utilizada para desacoplar operações que não exigem resultado imediato. Exemplos de eventos produzidos pela plataforma:

• solicitação criada, atualizada ou concluída;
• protocolo gerado;
• documento anexado ou aprovado;
• mensagem enviada ou recebida;
• agendamento confirmado ou cancelado;
• avaliação recebida;
• processo iniciado ou tarefa vencida;
• dados disponibilizados para ingestão no Data Lake.

O RabbitMQ suporta desacoplamento entre domínios, processamento em background, absorção de picos, retentativas, DLQ e alimentação do Data Lake. Detalhamento no Capítulo 13.

8.11 Arquitetura de Dados

A plataforma separa claramente o plano operacional do plano analítico:

• Bancos operacionais — mantidos pelos serviços de domínio com isolamento por tenant. Nenhum serviço acessa diretamente o banco de outro domínio.
• Cache — reduz latência em operações frequentes como catálogo, sessões e configurações de tenant.
• Busca textual e vetorial — para pesquisa de serviços, documentos e conteúdos da base de conhecimento de IA.
• Data Lake por tenant — alimentado por eventos de negócio via RabbitMQ, segregado por tenant. Fonte para Analytics, BI e IA que requerem dados históricos.

A estratégia física de persistência é definida e registrada como ADR-004. Detalhamento no Capítulo 15.

8.12 Arquitetura de Inteligência Artificial

A IA é uma capacidade transversal e governada da plataforma. A arquitetura segue o modelo em camadas:

Capacidades de Negócio (domínios)
         │
    Plataforma de IA
    (gateway, governança, quotas por tenant)
         │
    Capacidades de IA
    (chat, busca semântica, RAG, classificação, sumarização)
         │
    Abstração de Modelos
         │
    Modelos Locais ou em Nuvem
    (conforme política e configuração do tenant)

Cada tenant possui contexto de IA completamente isolado: base de conhecimento própria, embeddings, coleções vetoriais, configurações de modelo, quotas de consumo e métricas segregadas.

Serviços especializados de IA — busca semântica com RAG, chat com base de conhecimento, FAQ, indexação e gateway — coexistem com os serviços Java de domínio de negócio, comunicando-se por contratos definidos.

Detalhamento no Capítulo 16.

8.13 Arquitetura de Integração com Sistemas Governamentais

A plataforma integra o ecossistema tecnológico do Estado de Minas Gerais por meio de adaptadores específicos, preservando o isolamento entre os domínios internos e os contratos externos.

Integrações não são implementadas diretamente nos canais. APIs, conectores e adaptadores mediam toda comunicação com sistemas externos. Detalhamento no Capítulo 14.

8.14 Arquitetura de Segurança

A segurança é transversal à arquitetura — não é uma camada adicional, mas uma propriedade de todos os componentes. Os controles corporativos abrangem:

• autenticação multifator onde aplicável;
• autorização granular por perfil, tenant e recurso;
• segregação completa entre tenants em todas as camadas;
• proteção de APIs com autenticação, autorização e rate limiting;
• criptografia em trânsito (TLS) e em repouso para dados sensíveis;
• gestão segura de credenciais e segredos;
• trilhas de auditoria imutáveis;
• gestão de consentimentos conforme LGPD;
• monitoramento contínuo de incidentes e anomalias;
• segurança no ciclo de desenvolvimento (DevSecOps);
• proteção dos componentes de IA contra vazamento entre tenants.

Detalhamento completo na Parte VI (Capítulos 42 a 47).

8.15 Arquitetura de Observabilidade

Todos os componentes produtivos emitem sinais de observabilidade compatíveis com a operação distribuída da plataforma:

• Logs estruturados com correlationId, tenantId, userId e contexto de negócio;
• Métricas de aplicação, infraestrutura, RabbitMQ, APIs, bancos, Data Lake e IA;
• Rastreamento distribuído com spans propagados entre serviços via OpenTelemetry;
• Auditoria de negócio com registro imutável de ações sensíveis;
• Alertas operacionais com thresholds por domínio e por tenant;
• Indicadores por tenant visíveis no Painel do Gestor conforme perfil autorizado.

Detalhamento no Capítulo 41.

8.16 Governança da Arquitetura

A evolução da plataforma observa governança arquitetural formal. Decisões relevantes estão registradas como Architecture Decision Records (ADR) e refletem a arquitetura em operação.

A arquitetura corporativa é revisada formalmente quando há mudanças significativas em requisitos, volumetria, integrações, legislação ou modelo operacional da parceria.

8.17 Decisões Arquiteturais Confirmadas

As seguintes decisões estão confirmadas e orientam todos os capítulos técnicos subsequentes:

1. Backend corporativo em Java com Spring Boot;
2. Portal Web em React;
3. Aplicativo Mobile em React Native;
4. Comunicação assíncrona com RabbitMQ;
5. IAM próprio com gestão de tenants, usuários, perfis e permissões;
6. Autenticação federada com GOV.BR via OpenID Connect;
7. Arquitetura multi-tenant nativa com segregação obrigatória por tenant;
8. Arquitetura de IA com isolamento de contexto, base de conhecimento e métricas por tenant;
9. Data Lake com segregação por tenant;
10. Integração com sistemas do ecossistema governamental por adaptadores específicos.

8.18 Benefícios da Arquitetura Corporativa

A organização proposta oferece:

• visão comum e coerente entre negócio e tecnologia;
• separação clara de responsabilidades entre camadas e domínios;
• base sólida para decomposição em microsserviços (Capítulo 12);
• isolamento que previne vazamento de dados entre órgãos;
• rastreabilidade dos requisitos até os componentes técnicos;
• suporte a configurações e serviços específicos por tenant;
• evolução incremental sem reestruturação global;
• fonte de verdade por domínio com governança definida;
• escalabilidade independente de componentes.

8.19 Riscos Arquiteturais e Mitigações

8.20 Considerações Finais

A Arquitetura Corporativa é a visão integradora que fundamenta todos os capítulos técnicos da Parte III. Ela não é um documento estático — é revisada à medida que novos requisitos emergem ao longo da parceria.

Os capítulos seguintes aprofundam cada dimensão: negócio (Capítulo 9), funcional (Capítulo 10), plataforma (Capítulo 11), microsserviços (Capítulo 12), eventos (Capítulo 13), APIs (Capítulo 14), dados (Capítulo 15), IA (Capítulo 16) e segurança (Capítulo 17).

8.21 Controle de Versão

8.22 Rastreabilidade PRODEMGE

• [PNR] — Plano de Negócio Referencial: plataforma digital integrada com arquitetura modular, microsserviços, multi-tenant, cloud/híbrido/on-premise, CRM, BPM, ECM, dados, IA, interoperabilidade, segurança, governança, escalabilidade e evolução contínua.
• [ANX-III] — Planilha de Qualificação de Funcionalidades: este capítulo estabelece a base arquitetural para os seis blocos funcionais — Relacionamento e Atendimento, BPM, ECM/GED, Dados e Analytics, Integração e Interoperabilidade, Infraestrutura e Governança.
• [ANX-IV] — Planilha de Qualificação de Capacidades: IAM, multi-tenancy, RabbitMQ, Data Lake, IA, API Gateway e observabilidade correspondem às capacidades avaliadas no Anexo IV.
• [ANX-V] — Planilha de Qualificação de Sustentabilidade: evolução incremental, baixo acoplamento, documentação contínua e governança por ADRs atendem aos critérios de sustentabilidade tecnológica.
• [EDITAL] — Edital CP001/2026: a arquitetura corporativa demonstra aderência ao objeto da parceria e às características técnicas esperadas da solução.