Guia do Portal 2.0

O Portal 2.0 organiza a plataforma por responsabilidades. A interface atende a pessoa usuária. A entrada pública recebe e protege as requisições. Os domínios executam as regras de negócio. As capacidades compartilhadas fornecem a infraestrutura que sustenta esse trabalho.

Essa divisão permite mudar uma parte do sistema sem transformar uma alteração local em uma mudança transversal. Por exemplo, uma tela pode evoluir sem levar regras de negócio para o frontend, e um domínio pode trocar um detalhe de persistência sem alterar o contrato exposto ao consumidor.

Antes de abrir o código

Este guia é uma explicação da arquitetura. Ele ajuda você a escolher a responsabilidade correta antes de criar um diretório, uma rota ou uma dependência.

Se você precisa entender...	Comece por...
Como uma chamada entra e é validada	Camada de API
Como a experiência combina capacidades	BFF
Como o código é agrupado	Pacotes
Onde uma regra de negócio deve viver	Domínios
Onde uma capacidade técnica reutilizável pertence	Shared
Como a pessoa entra e acessa recursos	Autenticação
Como o grupo e a unidade cadastram a marca d'água do laudo	Marca d'água do laudo

O que significa monólito modular

O Portal 2.0 é um monólito modular. As aplicações são entregues de forma integrada, mas o comportamento é dividido em módulos com limites e contratos explícitos.

Um domínio controla suas regras e casos de uso. Outro módulo o acessa por um contrato conhecido, não por arquivos internos. As aplicações inicializam e conectam esses módulos. Shared oferece recursos técnicos, mas não se torna um depósito de regras de negócio.

O diagrama mostra o caminho mais comum. Nem toda operação usa todas as etapas. Uma consulta simples pode terminar no BFF. Uma alteração auditável pode publicar um evento depois que a resposta já foi enviada.

Caminho de uma operação

1. A experiência declara uma intenção, como consultar uma lista ou salvar uma alteração.
2. A camada de API valida o formato, cria o contexto de identidade e correlação, e encaminha a operação.
3. O BFF organiza a resposta para a experiência quando ela precisa combinar dados ou adaptar contratos.
4. O domínio responsável decide se a operação é válida e executa o comportamento.
5. Shared fornece recursos como logs, segurança, comunicação e persistência sem decidir a regra de negócio.
6. A auditoria registra os eventos que precisam ser rastreados sem bloquear a resposta quando o fluxo é assíncrono.

Como escolher onde implementar uma mudança

Pergunta	Responsabilidade provável
A mudança traduz HTTP ou GraphQL para uma chamada interna?	Camada de API.
A mudança combina dados para uma tela ou consumidor específico?	BFF.
A mudança decide uma regra que deve continuar válida em qualquer interface?	Domínio.
A mudança oferece uma capacidade técnica usada por vários módulos?	Shared.
A mudança só conecta módulos e inicia a aplicação?	Aplicação ou bootstrap.

Se uma regra continua válida quando a tela, o protocolo ou a integração mudam, ela pertence ao domínio. Se a dúvida persistir, defina primeiro a responsabilidade; só depois escolha o pacote.

Próximos passos

Leia Pacotes antes de criar um módulo. Use a Camada de API e o BFF para entender a entrada e a composição da experiência. Consulte Domínios e Shared antes de posicionar uma regra ou uma dependência técnica.