Capítulo 11 — Arquitetura da Plataforma

11.1 Objetivo do Capítulo

Este capítulo apresenta a Arquitetura da Plataforma de Relacionamento Digital com o Cidadão na visão de contêineres (C4 — Nível 2), descrevendo como os componentes tecnológicos se organizam para suportar os módulos funcionais definidos no Capítulo 10.

A Arquitetura da Plataforma define:

• a organização em camadas lógicas e seus limites;
• os componentes que compõem cada camada;
• como os canais se comunicam com o backend;
• como o contexto de tenant é estabelecido e propagado;
• como os serviços de domínio são estruturados internamente;
• como a mensageria, a persistência, a IA e a observabilidade se articulam;
• os padrões internos que todos os serviços observam;
• os princípios de resiliência e escalabilidade horizontal.

11.2 Organização em Camadas Lógicas

A plataforma é organizada em dez camadas lógicas com responsabilidades claramente delimitadas. A implementação física distribui os componentes em containers, clusters ou ambientes conforme a arquitetura de infraestrutura definida no Capítulo 20.

┌─────────────────────────────────────────────────────────────────────────┐
│  CAMADA 1 — CANAIS DIGITAIS                                             │
│  Portal Web │ Aplicativo Mobile │ Painel do Gestor │ Canais Externos    │
├─────────────────────────────────────────────────────────────────────────┤
│  CAMADA 2 — ACESSO E EXPOSIÇÃO DE SERVIÇOS                              │
│  API Gateway │ BFF (quando necessário) │ Rate Limit │ CORS │ mTLS       │
├─────────────────────────────────────────────────────────────────────────┤
│  CAMADA 3 — IDENTIDADE E CONTEXTO                                       │
│  IAM Próprio │ GOV.BR │ Tenant Context │ Perfis │ Permissões            │
├─────────────────────────────────────────────────────────────────────────┤
│  CAMADA 4 — SERVIÇOS DE DOMÍNIO                                         │
│  Cidadão │ Catálogo │ Solicitações │ BPM │ CRM │ Comunicação            │
│  Documentos │ Agendamentos │ Ouvidoria │ Satisfação │ Segmentação        │
│  Administração                                                           │
├─────────────────────────────────────────────────────────────────────────┤
│  CAMADA 5 — SERVIÇOS CORPORATIVOS TRANSVERSAIS                          │
│  Auditoria │ Notificações │ Arquivos │ Busca │ Configuração              │
├─────────────────────────────────────────────────────────────────────────┤
│  CAMADA 6 — MENSAGERIA E PROCESSAMENTO ASSÍNCRONO                       │
│  RabbitMQ │ Exchanges │ Filas │ DLQ │ Retry │ Consumidores              │
├─────────────────────────────────────────────────────────────────────────┤
│  CAMADA 7 — DADOS E INTELIGÊNCIA                                        │
│  Bancos Operacionais │ Cache Redis │ Busca │ Vetores │ IA │ Data Lake   │
├─────────────────────────────────────────────────────────────────────────┤
│  CAMADA 8 — INTEGRAÇÃO EXTERNA                                          │
│  GOV.BR │ MG API │ SEI!MG │ MG-Ouv │ Data Lake MG │ PRO SMTP          │
│  SEG.ID │ Agenda Minas │ Portal de Municípios │ Sistemas de Trânsito    │
├─────────────────────────────────────────────────────────────────────────┤
│  CAMADA 9 — OBSERVABILIDADE E SEGURANÇA                                 │
│  Logs │ Métricas │ Traces │ Auditoria │ Alertas │ DevSecOps             │
├─────────────────────────────────────────────────────────────────────────┤
│  CAMADA 10 — INFRAESTRUTURA DE EXECUÇÃO                                 │
│  Containers │ Kubernetes │ Rede │ Secrets │ Storage │ Backup            │
└─────────────────────────────────────────────────────────────────────────┘

11.3 Camada 1 — Canais Digitais

11.3.1 Portal Web do Cidadão

Aplicação React que entrega as jornadas de autoatendimento em navegador. Responsável exclusivamente por apresentação e experiência de uso. Toda lógica de negócio, autorização, persistência e processamento residem no backend.

O portal comunica-se com o backend por APIs REST documentadas com OpenAPI, versionadas e protegidas pelo IAM. Para autenticação do cidadão, inicia o fluxo local (IAM próprio) ou redireciona para GOV.BR (federação OpenID Connect).

11.3.2 Aplicativo Mobile

Aplicação React Native com suporte a iOS e Android. Consome os mesmos contratos de API do Portal Web, com adaptações de experiência para dispositivo: captura de documentos por câmera, notificações push via APNS e FCM, biometria local para autenticação. Estado local é estritamente efêmero; a fonte de verdade é o backend.

11.3.3 Painel do Gestor

Aplicação React para usuários internos. Acessa módulos de atendimento, BPM, catálogo, comunicação, gestão documental, analytics, administração e monitoramento. As permissões são determinadas pelo IAM e re-validadas no backend em cada requisição — a ocultação de elementos na interface não é mecanismo suficiente de controle de acesso.

11.3.4 Canais Externos de Comunicação

Adaptadores de entrega de mensagens: e-mail (PRO SMTP ou equivalente), SMS, notificações push e WhatsApp. São acionados pelo módulo de Comunicação Omnichannel via RabbitMQ. Nenhuma regra de negócio reside nos adaptadores.

11.4 Camada 2 — Acesso e Exposição de Serviços

11.4.1 API Gateway

O API Gateway é o único ponto de entrada HTTP dos canais para o backend. Responsabilidades: roteamento para serviços de domínio; autenticação de tokens; propagação de identidade e contexto de tenant; rate limiting por tenant, usuário e endpoint; CORS; TLS termination; logging de acesso; coleta de métricas de entrada.

O Gateway não implementa lógica de negócio. Ele garante que toda requisição ao backend chegue autenticada, com contexto validado e dentro dos limites definidos.

11.4.2 BFF (Backend for Frontend)

BFFs são avaliados por canal quando há necessidade de composição de chamadas, transformação de resposta ou otimização de payload específica para um cliente. A adoção é definida por ADR-033. Quando utilizados, BFFs não duplicam regras de negócio dos serviços de domínio.

11.4.3 Proteção e Limites

Rate limiting é aplicado em múltiplas dimensões: por IP, por usuário autenticado, por tenant e por endpoint sensível. A política de throttling protege os serviços de domínio de picos e de uso abusivo. Respostas de limite excedido seguem RFC 6585 com cabeçalho Retry-After.

11.5 Camada 3 — Identidade e Contexto

11.5.1 IAM Próprio

O IAM próprio é o componente responsável por toda a gestão de identidade interna da plataforma. Gerencia: tenants; usuários com credenciais locais; políticas de senha e sessão; perfis, papéis e permissões; vínculos usuário-tenant-unidade; emissão de tokens de acesso; auditoria de autenticação.

A tecnologia específica do IAM é registrada como ADR-002. A arquitetura não assume protocolo único — o contrato fundamental é que o IAM emite tokens validados pelo API Gateway e que os serviços de domínio verificam autorização por meio de uma interface padronizada.

11.5.2 Federação com GOV.BR

O fluxo de autenticação federada segue OpenID Connect:

Cidadão seleciona "Entrar com GOV.BR"
    │
Canal inicia autenticação
    │
IAM redireciona para GOV.BR
    │
GOV.BR autentica e retorna identidade
    │
IAM valida transação e atributos recebidos
    │
IAM localiza ou cria vínculo com identidade interna
    │
IAM emite token de sessão da plataforma
    │
Canal acessa recursos com token emitido
    │
Backend valida tenant e autorização (sempre)

O GOV.BR confirma identidade. A autorização é sempre responsabilidade da plataforma. A identidade externa é vinculada à identidade interna por identificador estável — não por nome ou e-mail mutável.

11.5.3 Tenant Context

O tenant é um conceito transversal obrigatório. O Tenant Context é estabelecido pelo IAM a partir de elementos controlados: identidade autenticada e seus vínculos, domínio do canal, credencial de integração ou rota controlada. O valor de tenant enviado pelo cliente nunca é aceito isoladamente como confiável.

O contexto é propagado entre todos os componentes:

Request autenticado
    │
Tenant Context estabelecido
    │
┌───┼───────────────────────┐
│   │                       │
▼   ▼                       ▼
Serviço   Cache       Evento RabbitMQ
de Domínio (namespace   (envelope com
           por tenant)   tenantId)
    │
    ├── Repository (filtro estrutural)
    ├── Auditoria (tenantId no log)
    ├── AI Context (base isolada)
    └── Data Lake (partição do tenant)

Nenhum repositório multi-tenant depende exclusivamente da disciplina do desenvolvedor para aplicar filtro de tenant em cada consulta. A arquitetura fornece mecanismos estruturais — como interceptores, filtros de repositório e contexto de thread — que reduzem este risco.

11.5.4 Autorização

A autorização é verificada em dois pontos: no API Gateway (validação do token e do tenant) e no serviço de domínio (verificação da permissão específica para o recurso e operação). A dupla verificação garante que falhas de configuração no gateway não concedam acesso indevido.

Modelo:

Identidade + Tenant + Perfil + Permissão + Recurso + Operação + Escopo

11.6 Camada 4 — Serviços de Domínio

11.6.1 Tecnologia e Estrutura

Os serviços de domínio são implementados em Java com Spring Boot. A estrutura interna segue arquitetura hexagonal com Domain-Driven Design:

Adapter de Entrada (REST Controller / RabbitMQ Consumer)
    │
Port de Entrada (Interface de Caso de Uso)
    │
Domínio (Entidades, Agregados, Value Objects, Regras)
    │
Port de Saída (Interfaces de Repositório, Eventos, Integrações)
    │
Adapters de Saída (JPA, RabbitMQ Publisher, HTTP Client, Cache)

Esta organização isola o domínio de negócio de detalhes de infraestrutura. Frameworks e bibliotecas são dependências dos adapters, não do núcleo de domínio.

11.6.2 Serviços Identificados

A decomposição definitiva em microsserviços — incluindo critérios de agrupamento, limites exatos e granularidade — é detalhada no Capítulo 12.

11.6.3 Padrões Internos dos Serviços

Todos os serviços Java observam os seguintes padrões:

Starter Corporativo: todos os serviços utilizam um starter Spring Boot corporativo que encapsula configuração de logging estruturado, métricas, rastreamento distribuído, health checks, Tenant Context, tratamento de erro padronizado e resiliência.

Logs estruturados: formato JSON com campos obrigatórios: timestamp, level, service, environment, tenantId, traceId, correlationId, event. Dados pessoais, tokens e secrets são vedados nos logs.

Health Checks: cada serviço expõe /actuator/health/liveness e /actuator/health/readiness separadamente. Um serviço com dependência externa temporariamente indisponível permanece vivo enquanto puder aguardar recuperação.

Rastreamento distribuído: OpenTelemetry com propagação de traceparent (W3C Trace Context) entre serviços, mensagens RabbitMQ e chamadas externas. O Tenant Context é propagado sem expor dados pessoais em atributos de alta cardinalidade.

Graceful Shutdown: ao receber sinal de encerramento, o serviço para de aceitar novas requisições, conclui as em andamento dentro de um timeout configurável e fecha conexões de forma ordenada.

11.7 Camada 5 — Serviços Corporativos Transversais

11.7.1 Auditoria

Serviço responsável pela trilha imutável de ações sensíveis. Recebe eventos de auditoria dos serviços de domínio via API síncrona ou evento RabbitMQ. Garante que a gravação da trilha não bloqueie o fluxo principal quando a criticidade permite processamento assíncrono. Consultas são restritas por perfil autorizado e toda consulta à trilha é ela mesma auditada.

11.7.2 Notificações

Serviço que abstrai a entrega de notificações ao cidadão e a usuários internos. Recebe comandos de notificação dos serviços de domínio, seleciona o canal adequado conforme preferências e consentimentos, e aciona os adaptadores externos (e-mail, SMS, push). Registra status de entrega para rastreabilidade.

11.7.3 Armazenamento de Arquivos

Serviço responsável por armazenamento binário de documentos e arquivos. Encapsula a tecnologia de storage — sistema de arquivos, object storage ou solução GED externa — dos serviços de domínio. Documentos são referenciados por identificador; o serviço de domínio nunca armazena o binário diretamente.

11.7.4 Busca

Serviço que expõe capacidades de busca textual e semântica para os módulos de catálogo, documentos e base de conhecimento. A tecnologia de índice textual e de banco vetorial é encapsulada atrás de uma interface de busca, permitindo evolução sem impactar os consumidores.

11.8 Camada 6 — Mensageria e Processamento Assíncrono

11.8.1 RabbitMQ

RabbitMQ é a infraestrutura central de comunicação assíncrona. Sua função é desacoplar produtores de consumidores, absorver picos, suportar processamento em background, alimentar o Data Lake por eventos e apoiar os processamentos não interativos de IA.

A topologia de exchanges, filas e routing keys é registrada como ADR-003. A referência de organização:

platform.events       → eventos de domínio (fanout por tipo)
platform.commands     → comandos assíncronos direcionados
platform.jobs         → trabalhos de processamento em background
platform.dlx          → dead letter exchange para falhas

11.8.2 Envelope de Evento

Todo evento publicado no RabbitMQ carrega envelope padronizado:

{
  "id": "uuid-v4",
  "type": "request.submitted.v1",
  "version": "1",
  "occurredAt": "2026-07-15T10:30:00Z",
  "tenantId": "tenant-abc",
  "correlationId": "correlation-xyz",
  "causationId": "event-que-causou-este",
  "producer": "request-service",
  "payload": { }
}

O tenantId no envelope garante que consumidores multi-tenant apliquem corretamente o contexto de isolamento sem depender do payload de negócio.

11.8.3 Semântica de Entrega

A arquitetura adota entrega at-least-once. Consumidores críticos são idempotentes. O padrão Transactional Outbox garante consistência entre a transação de domínio e a publicação do evento: o evento é gravado na mesma transação do banco operacional do produtor e publicado no RabbitMQ por um publisher em background.

11.8.4 Tratamento de Falhas

Mensagens que excedem as retentativas configuradas são encaminhadas para a Dead Letter Queue correspondente. DLQs possuem: responsável definido, dashboard de monitoramento, alerta de acúmulo, política de retenção e processo de replay auditado. Uma poison message não bloqueia indefinidamente a fila original.

11.9 Camada 7 — Dados e Inteligência

11.9.1 Bancos Operacionais

Cada serviço de domínio é o único responsável pelos seus dados operacionais. Nenhum serviço acessa diretamente a base de dados de outro. A comunicação entre domínios ocorre por API ou evento.

O isolamento de dados por tenant é aplicado no nível do banco: a estratégia entre banco por tenant, schema por tenant e particionamento lógico é registrada como ADR-001 e ADR-004.

11.9.2 Cache — Redis

Redis é utilizado para: redução de latência em leituras frequentes (catálogo, configurações de tenant, sessões quando aplicável); distributed locks para operações concorrentes (reserva de agendamento, por exemplo); rate limiting distribuído.

O cache é tenant-aware: chaves incluem o identificador de tenant para garantir isolamento. Cada uso classifica explicitamente: o que acontece quando o cache está indisponível. Para otimizações, o fallback é a origem. Para controles de segurança como rate limiting, a política de falha é restritiva.

Consistência entre banco e cache é gerida por invalidação após commit. A estratégia anti-cache-stampede é aplicada a chaves de alta concorrência.

11.9.3 Busca Textual e Vetorial

A plataforma mantém índices de busca para catálogo de serviços, conteúdo de documentos indexados e base de conhecimento de IA. A busca textual cobre pesquisas por termos, metadados e conteúdo. A busca vetorial cobre similaridade semântica para RAG. Os índices são segregados por tenant — nenhuma busca retorna conteúdo de outro tenant.

11.9.4 Data Lake por Tenant

O Data Lake recebe eventos de negócio via RabbitMQ e os consolida em partições segregadas por tenant. Cada partição mantém linhagem de origem, permite analytics histórico, alimenta relatórios e dashboards, e suporta datasets de IA. O acesso ao Data Lake é restrito por perfil e finalidade.

11.9.5 Plataforma de IA

A plataforma de IA expõe capacidades por gateway governado. Os serviços de domínio consomem capacidades — chat, busca semântica, RAG, classificação, sumarização — sem dependência direta de provedores. A troca de provedor ou modelo não exige alteração nos consumidores.

O contexto de tenant é obrigatório em toda requisição de IA. Bases de conhecimento, embeddings, configurações de modelo e quotas de consumo são completamente isolados por tenant.

A arquitetura detalhada de IA é apresentada no Capítulo 16.

11.10 Camada 8 — Integração Externa

Todas as integrações com sistemas externos são mediadas por adaptadores específicos que encapsulam os protocolos e contratos externos. Nenhum serviço de domínio depende diretamente de um contrato externo. Os adaptadores implementam resiliência: timeout, retry com backoff exponencial e jitter, circuit breaker e bulkhead.

Integrações não implementadas diretamente nos canais. O Integration Service centraliza adaptadores, monitoramento de saúde, gestão de credenciais e reprocessamento de falhas.

11.11 Camada 9 — Observabilidade e Segurança

11.11.1 Três Pilares de Observabilidade

Logs: estruturados em JSON com campos obrigatórios. Coletados por agentes nos containers e encaminhados ao backend de logs centralizado. Dados pessoais, tokens, secrets e prompts de IA são vedados.

Métricas: padrões RED (Rate, Errors, Duration) para serviços e USE (Utilization, Saturation, Errors) para infraestrutura. Emitidas por OpenTelemetry. Cardinalidade controlada — labels com tenant são avaliados por impacto.

Traces: rastreamento distribuído com OpenTelemetry. Spans propagados entre serviços HTTP, mensagens RabbitMQ, chamadas de IA e integrações externas. Correlation ID funcional coexiste com Trace ID técnico.

O Capítulo 19 detalha a arquitetura completa de observabilidade, SRE e resiliência.

11.11.2 Segurança na Plataforma

Controles aplicados em toda a plataforma:

• TLS obrigatório em trânsito entre todos os componentes;
• secrets gerenciados por cofre de segredos, nunca em variáveis de ambiente ou código;
• imagens de container sem vulnerabilidades críticas conhecidas antes do deploy;
• análise estática de código (SAST) e análise de dependências (SCA) no pipeline;
• autenticação mútua (mTLS) avaliada para comunicação interna entre serviços;
• menor privilégio nas permissões de serviço e de banco de dados;
• containers executados com usuário não-root quando possível.

O Capítulo 16 detalha a arquitetura completa de segurança, identidade e proteção de dados.

11.12 Camada 10 — Infraestrutura de Execução

Os componentes da plataforma são empacotados como containers OCI. Kubernetes é o principal candidato arquitetural para orquestração — a decisão definitiva considera o modelo operacional da PRODEMGE, infraestrutura disponível e requisitos de SLA.

Cada container: contém apenas dependências necessárias; executa com usuário não-privilegiado; expõe liveness e readiness separadamente; é configurado externamente por variáveis de ambiente e secrets montados; não armazena estado efêmero como fonte de verdade.

A estratégia de ambientes, clusters, namespaces e node pools é detalhada no Capítulo 20.

11.13 Padrões de Resiliência

11.13.1 Timeout

Toda chamada remota possui timeout configurado. Chamadas sem timeout criam dependências implícitas que comprometem a resiliência. O timeout é propagado entre chamadas encadeadas (deadline propagation).

11.13.2 Retry

Retentativas são aplicadas apenas a erros transitórios e idempotentes. A política utiliza exponential backoff com jitter para evitar retry storms. O número de retentativas é limitado por retry budget. Operações não idempotentes não têm retry automático.

11.13.3 Circuit Breaker

Circuit breakers isolam dependências degradadas. Quando uma dependência excede o limiar de falhas, o circuit breaker abre e retorna resposta de fallback sem pressionar a dependência até sua recuperação. O estado do circuit breaker é monitorado e emite métricas.

11.13.4 Bulkhead

Bulkheads isolam pools de recursos entre contextos diferentes, impedindo que a saturação de um contexto (tenant, canal ou funcionalidade) se propague para outros. Connection pools de banco de dados e de clientes HTTP são dimensionados com bulkheads.

11.13.5 Graceful Degradation

A plataforma mantém as jornadas críticas quando componentes não essenciais falham. A indisponibilidade da IA não bloqueia a criação de solicitações. A indisponibilidade do Data Lake não impede o atendimento. A indisponibilidade do cache não derruba o serviço de domínio.

11.14 Escalabilidade

A plataforma escala horizontalmente. Serviços sem estado local obrigatório adicionam réplicas conforme a demanda sem necessidade de redesenho. O estado compartilhado (sessões, locks, rate limits) reside em Redis, não nos processos.

Serviços com pressão diferenciada escalam independentemente: consumers de RabbitMQ; serviço de solicitações sob campanhas; serviço de busca; processamento documental; workers de IA. A arquitetura não exige escalabilidade uniforme de todos os componentes.

11.15 Deploy e Evolução

11.15.1 Estratégias de Deploy

A plataforma suporta deploys progressivos: rolling deployment para atualizações de baixo risco; blue-green para versões com mudanças significativas; canary para validação com tráfego real limitado antes de rollout completo. Rollback automático é acionado quando métricas de saúde degradam durante a janela de deploy.

11.15.2 Feature Flags

Feature flags permitem rollout gradual por tenant, testes controlados e migração incremental entre versões. Não substituem autorização, configuração funcional permanente nem controle contratual.

11.15.3 Compatibilidade

APIs são versionadas. Contratos de eventos RabbitMQ são versionados. Migrações de banco seguem o padrão Expand-Migrate-Contract para garantir que o deploy de uma nova versão de serviço não quebre instâncias anteriores ainda em execução.

11.16 Ambientes

A plataforma opera em quatro ambientes distintos:

Cada ambiente possui credenciais, bancos, filas RabbitMQ, secrets e configurações completamente separados. Dados produtivos não são copiados indiscriminadamente para ambientes não-produtivos.

11.17 Fluxo Completo de uma Requisição

O diagrama a seguir descreve o fluxo de uma requisição típica do cidadão:

Cidadão acessa Portal Web
    │
    ▼
API Gateway
  ├── Valida TLS
  ├── Extrai e valida token
  ├── Aplica rate limit
  └── Roteia para serviço

    │
    ▼
Serviço de Domínio (ex.: Request Service)
  ├── Resolve Tenant Context
  ├── Verifica autorização
  ├── Executa lógica de domínio
  ├── Persiste no banco operacional (com outbox)
  └── Publica evento no RabbitMQ

    │
    ├──▶ Notification Consumer → Envia notificação ao cidadão
    ├──▶ Workflow Consumer → Inicia instância de processo
    ├──▶ Audit Consumer → Grava trilha de auditoria
    └──▶ Data Lake Consumer → Ingere evento analítico

    │
    ▼
Resposta ao cidadão com protocolo e status

11.18 Benefícios da Arquitetura

• separação clara entre apresentação, lógica e persistência;
• escalabilidade independente por serviço e por função;
• isolamento de falhas por circuit breaker e bulkhead;
• tenant como contexto estrutural, não como filtro manual;
• deploys progressivos com rollback automático;
• observabilidade ponta a ponta por OpenTelemetry;
• segurança aplicada em camadas, não em ponto único;
• evolução independente de serviços sem reestruturação global;
• integrações externas encapsuladas por adaptadores;
• dados operacionais e analíticos com responsabilidades separadas.

11.19 Riscos e Mitigações

11.20 Decisões Arquiteturais

11.21 Relacionamento com Outros Capítulos

11.22 Considerações Finais

A Arquitetura da Plataforma estabelece a organização técnica que viabiliza os módulos funcionais definidos no Capítulo 10. Ela distribui responsabilidades em camadas com limites claros, define padrões internos que todos os serviços observam e estabelece os mecanismos de resiliência, escalabilidade e segurança que sustentam a operação multi-tenant.

O Capítulo 12 aprofunda a decomposição dos serviços de domínio em microsserviços, definindo para cada um: responsabilidades, dados sob sua governança, APIs candidatas, eventos produzidos e consumidos.

11.23 Controle de Versão

11.24 Rastreabilidade PRODEMGE

• [ANX-III] Bloco 1 — Relacionamento com o Cidadão: Camadas 1, 3 e 4 (Portal, IAM, GOV.BR, CRM, Comunicação, Cadastro).
• [ANX-III] Bloco 2 — BPM: Camada 4 (Workflow Service, Task Service, integração com RabbitMQ).
• [ANX-III] Bloco 3 — Gestão Documental: Camadas 4, 5 e 7 (Document Service, armazenamento de arquivos, busca).
• [ANX-III] Bloco 4 — Dados, Analytics e Inteligência: Camadas 6, 7 (Data Lake, Analytics, IA, RAG, cache, busca vetorial).
• [ANX-III] Bloco 5 — Integração e Interoperabilidade: Camadas 2 e 8 (API Gateway, Integration Service, adaptadores governamentais).
• [ANX-III] Bloco 6 — Infraestrutura, Segurança e Governança: Camadas 3, 9 e 10 (IAM, observabilidade, segurança, containers, DevSecOps).
• [ANX-IV] — Capacidades técnicas de escalabilidade, resiliência, multi-tenancy, IA, integração e observabilidade atendidas pelas camadas descritas.
• [ANX-V] — Sustentabilidade tecnológica: hexagonal + DDD, versionamento de APIs e eventos, deploys progressivos, padrões corporativos, separação de responsabilidades.
• [PNR] — Plano de Negócio Referencial: plataforma modular, escalável, segura, multi-tenant, interoperável, com IA integrada e evolução contínua.