Arquiteturas: camadas, monólito, SOA, microsserviços, EDA, serverless

A ideia que organiza o assunto

Escreva um sistema inteiro num lugar só e ele funciona. O problema aparece depois: mudar a tela obriga a recompilar a regra de negócio, um vazamento de memória no relatório derruba o login, duas equipes não entregam em ritmos diferentes porque dividem o mesmo artefato, e escalar significa duplicar tudo, inclusive o que ninguém usa.

Arquitetura é a resposta, e a resposta tem sempre a mesma forma: cortar o sistema em partes e fixar a regra de dependência entre elas. O que muda de um estilo para outro é só onde passa o corte e quanto acoplamento sobra atravessando-o.

Camadas cortam por responsabilidade técnica — apresentação, negócio, dados — e cada camada só usa a de baixo. Cliente-servidor corta entre quem pede e quem atende. O MVC corta a parte interativa em três papéis. A SOA corta por serviço de negócio, atrás de um contrato publicado. Os microsserviços levam o corte ao extremo: processo, banco e implantação próprios por serviço. A orientação a eventos corta pela notificação — quem produz não sabe quem consome. O serverless corta até a função e entrega ao provedor tudo abaixo dela.

Isso é o método de resolver a prova, não o pano de fundo. Antes de julgar qualquer item, pergunte qual responsabilidade ele está movimentando e de que lado do corte ela pertence. Apresentação é do cliente; regra de negócio é da camada de negócio; acesso físico ao dado é da camada de dados; requisição de usuário é do controlador; dado é do próprio microsserviço. Se a responsabilidade descrita não pertence ao lugar citado, o item acabou ali.

Nenhum desses estilos substitui o anterior. Um microsserviço, por dentro, é uma aplicação em camadas; um sistema orientado a eventos continua tendo clientes e servidores. Eles se empilham — e a banca mora nas fronteiras.

Por que se usa (e o que custa)

O monólito não é um erro: é o ponto de partida racional. Um artefato, um deploy, uma transação de banco, depuração num processo só. Ele deixa de servir quando coordenar pessoas e implantar tudo junto custa mais do que distribuir.

Camadas compram substituibilidade: mantida a interface, troca-se uma camada inteira — outro banco, outra tela — sem tocar nas demais. Paga-se em indireção.

SOA compra reúso e integração. Serviços grossos, catalogados, com contrato explícito, permitem combinar sistemas heterogêneos, inclusive legados, e levar a mesma funcionalidade a plataformas novas — por isso a banca aceita que a SOA reduz custo e aumenta agilidade. E aceita, sem contradição, que sua limitação é o aumento das interdependências: quanto mais consumidores no mesmo serviço, mais cara fica qualquer mudança nele.

Microsserviços compram independência: equipes implantam separadamente, escolhem tecnologias diferentes, escalam só o que aperta, e uma falha — um vazamento de memória, por exemplo — fica contida no serviço que a sofreu, porque os processos são isolados. Paga-se com tudo o que é caro em sistema distribuído: latência, consistência eventual, rastreamento, e resiliência embutida na arquitetura.

Orientação a eventos compra desacoplamento no tempo e na identidade: o produtor publica e segue; o consumidor processa quando puder, e pode não existir nenhum. Paga-se com ordem, duplicidade e depuração difícil.

Serverless compra a saída do negócio de servidores: nada a dimensionar, escala automática, cobrança por execução. Paga-se com ausência de estado, tempo máximo de execução, partida a frio e dependência do provedor.

Como funciona

Camadas. A apresentação define a lógica da interface com o usuário; a camada de negócio concentra as regras; a de dados guarda e acessa fisicamente o armazenamento. Em três camadas, a apresentação roda no cliente, a lógica no servidor de aplicação e os dados no servidor de banco. Camada lógica não é camada física: as três podem conviver numa máquina só. A camada mais interna é a que encosta no sistema operacional e no banco; a mais externa fala com o usuário. E mantida a interface, uma camada inteira pode ser substituída.

Ainda em camadas, separe serviço de protocolo: serviço é o conjunto de operações que uma camada oferece à camada acima; protocolo é o conjunto de regras que governa a conversa entre entidades pares, na mesma camada de máquinas diferentes.

Cliente-servidor. O cliente é o processo ativo: inicia a comunicação e pede. O servidor é reativo: fica disponível e responde. Essa assimetria é o que separa cliente-servidor de peer-to-peer, onde os nós são simétricos e o servidor, quando existe, apenas apresenta os pares uns aos outros. Daí decorrem três fatos que a banca cobra direto: cliente e servidor podem estar no mesmo computador; a comunicação pode ser assíncrona; e, em multicamadas, um mesmo processo é servidor de uns e cliente de outros ao mesmo tempo, conforme o papel em cada requisição.

MVC. O modelo gerencia os dados, a lógica e o acesso à base — recuperar, inserir, alterar. A visão define e gerencia como os dados aparecem. O controlador recebe a interação, aciona o modelo e escolhe a visão. Por isso o MVC facilita várias interfaces sobre o mesmo sistema: a regra fica isolada da apresentação e o mesmo modelo alimenta visões diferentes.

SOA. O ciclo é publicar, descobrir e vincular: o provedor publica a especificação, o consumidor a descobre, localiza o provedor, liga sua aplicação ao serviço e conversa por protocolos padronizados — SOAP sobre HTTP, com WSDL, ou REST. A fórmula que a prova gosta é contrato forte, implementação fraca: acoplamento forte na interface publicada, fraco no que está atrás dela. Os serviços têm granularidade grossa, representam processos de negócio e se compõem, normalmente por um barramento (ESB). Compor tem duas formas: orquestração, com maestro central e ordem preestabelecida, e coreografia, em que cada serviço reage a mensagens sem regente.

Microsserviços. Cada serviço é uma capacidade de negócio autônoma: processo próprio, banco próprio, implantação independente, linguagem livre. Em torno deles vêm as peças que a prova cobra pelo nome: contêineres, que empacotam a aplicação isolando-a do ambiente — virtualizando o sistema operacional, não o hardware; API gateway, ponto único de entrada que concentra roteamento, autenticação, autorização, limitação de taxa, terminação TLS, cache e estatísticas; e registro e descoberta de serviços (Eureka, por exemplo), em que cada instância se registra ao subir informando nome, endereço e porta, enquanto os clientes mantêm uma cópia local do catálogo, atualizada periodicamente.

Orientada a eventos. O produtor detecta um fato e o publica; um intermediário distribui; o consumidor reage de forma assíncrona. Produtor e consumidor não se conhecem — é um estilo de sistemas distribuídos, e é essa palavra que os itens trocam.

Serverless. Em FaaS, um gatilho — HTTP, fila, evento de armazenamento — dispara uma função executada em contêiner stateless totalmente gerenciado pelo provedor, que provisiona e escala sob demanda, sem nada pré-alocado. Em BaaS, a aplicação consome por API serviços prontos de terceiros: autenticação, banco de dados, criptografia, notificações.

O que decide os itens

Onde mora cada responsabilidade — a distinção que decide mais itens que todas as outras somadas:

responsabilidade	dono	não é de
lógica da interface, exibição	apresentação, no cliente	servidor de aplicação
regra de negócio	camada de negócio / domínio	apresentação
acesso físico ao dado	camada de dados / servidor de banco	camada intermediária
receber a interação do usuário	controlador (MVC)	modelo
dados e acesso à base	modelo (MVC)	visão ou controlador
abstrair protocolo e infraestrutura	middleware	interface com o usuário
detalhes técnicos (persistência, APIs externas)	camada de infraestrutura (DDD)	camada de domínio

Cliente × servidor — cliente é ativo (inicia, requisita); servidor é reativo (aguarda, atende). Não exige máquinas distintas, não exige sincronismo, e em multicamadas os dois papéis coexistem no mesmo componente.

Cliente-servidor × P2P — se os nós são simétricos, trocam dados armazenados localmente e o servidor só apresenta pares uns aos outros, é P2P, ainda que o item escreva cliente-servidor.

SOA × microsserviços:

	SOA	microsserviços
granularidade	grossa, processo de negócio	fina, capacidade de negócio
dados	frequentemente compartilhados	um banco por serviço
comunicação	mensagens padronizadas, ESB	API leve (REST) e mensageria
implantação	conjunta, governada	independente por serviço
tecnologia	padronizada pelo contrato	poliglota

Acoplamento em SOA — forte no contrato, fraco na implementação. Nunca o contrário.

Orquestração × coreografia — maestro central e ordem preestabelecida × reação a mensagens sem regente. A coreografia é a que maximiza o desacoplamento; um barramento de mensageria transporta, não orquestra.

FaaS × BaaS — código próprio disparado por evento × serviço de retaguarda pronto, de terceiro, consumido por API. Nos dois, quem dimensiona e escala é o provedor.

Serviço × protocolo (camadas) — serviço é vertical, oferecido à camada de cima; protocolo é horizontal, entre pares do mesmo nível em máquinas diferentes.

Contêiner × máquina virtual — o contêiner virtualiza o sistema operacional e compartilha o núcleo; quem virtualiza o hardware é a VM.

API gateway faz roteamento, autenticação, autorização, limitação de taxa, terminação SSL/TLS, TLS mútuo, cache e coleta de estatísticas. Item que negue qualquer uma dessas está errado.

Distribuição por assunto — cliente-servidor e MVC, juntos, respondem por quase um terço dos itens, e no nível mais básico. Depois vêm SOA (características, limitações, granularidade, composição), microsserviços com seus satélites (contêineres, API gateway, descoberta, REST) e camadas (“que responsabilidade mora onde”). Serverless aparece em blocos inteiros, sempre sobre quem gerencia a infraestrutura e sobre FaaS × BaaS. Monólito e EDA, apesar do título do tópico, comparecem pouco e em formulações genéricas — motivo para não gastar neles o tempo que o MVC merece.

Como a CEBRASPE derruba você aqui

Inversão — um terço dos itens errados, e quase sempre sobre acoplamento, direção ou papel. É a manobra dominante do tópico e a mais fácil de perder por pressa, porque nada na frase soa estranho: só o sentido está ao contrário. Acoplamento invertido: microsserviços “fortemente acoplados” e “dependentes uma das outras”, serviços que “devem possuir acoplamento forte” em SOA, uma arquitetura “altamente acoplada” apresentada como facilitadora de mudança de processo. Papel invertido: “o cliente se encarrega de ofertar os serviços”; “o cliente é o processo reativo, pois depende da interação com o usuário, e o servidor é o processo ativo”; “a camada interface deve oferecer abstrações da camada modelo”, quando quem oferece abstração é sempre a camada de baixo; no DDD, “a infrastructure layer deve conter a lógica de negócios central e coordenar as regras de domínio”. Propriedade definidora negada: “a SOA não permite a execução em computadores geograficamente distribuídos”; microsserviços que “não podem ser implantados de forma independente” e “devem usar a mesma técnica de armazenamento de dados”; mensageria entregando “de forma síncrona e em tempo real”, ou um tópico cuja mensagem “será entregue a uma única aplicação consumidora” — isso é fila. E o benefício vendido como custo: separar responsabilidades “ao custo de maiores manutenção, escalabilidade e flexibilidade”. A defesa é uma só: antes de julgar, enuncie você mesmo a direção correta do par — quem oferta e quem consome, quem é a camada de cima e quem é a de baixo, o que é acoplado e o que é independente — e só então compare com a do item.

Troca de termo — pouco mais de um quinto. A frase inteira descreve com precisão um conceito e assina o nome do vizinho. “Um protocolo é um conjunto de operações em alto nível de abstração funcional que uma camada oferece à camada situada acima dela” — isso é serviço, não protocolo. Uma SOA elogiada por operar “com granularidade fina” — é grossa. Contêineres que “virtualizam o hardware físico da máquina em que estão instalados” — é o hipervisor. “Nuvens comunitárias se refere a uma infraestrutura de nuvem disponibilizada ao público em geral” — é nuvem pública. O REST descrito como “um protocolo para troca de informações estruturadas, cujo formato de mensagem é embasado na linguagem de marcação extensível (XML)” — é o SOAP. Uma EDA “em sistemas centralizados”; o JSON como “uma linguagem de programação”; microsserviços como “a fragmentação de uma API em operações menores”, quando o que se fragmenta é a aplicação. Leia a descrição inteira, decida que nome ela merece e só então olhe o nome que o item usou.

Atribuição errada de camada ou componente — um em cada seis. A ação existe, o dono está errado, e o alvo preferido é a pilha de três camadas. “A camada de apresentação encontra-se no servidor de aplicação.” “A camada intermediária é responsável por acessar fisicamente os dados armazenados.” “O componente de modelo gerencia as requisições dos usuários” — é o controlador. O middleware “responsável pela interface com o usuário, como as camadas de apresentação e visualização”. O UDP como “o principal protocolo da camada de aplicação”. O servidor web respondendo “pelo armazenamento e pela disponibilização dos dados solicitados pelas páginas web” — é o SGBD. A tabela de responsabilidades acima é a defesa: confira se a ação descrita pertence àquela camada antes de olhar qualquer outra coisa da frase.

Condição ou causa inventada. A frase é verdadeira até o conectivo. “Um microsserviço pode ter diversas finalidades, desde que sejam escritas na mesma linguagem e estejam no mesmo servidor.” A integração por API é possível “desde que tais serviços tenham sido implementados por meio de SOA”. Não se usa RESTful “porque ele é um protocolo desenvolvido a partir de SOAP”. E a causa que aponta para o lado errado: o reúso em SOA que “acaba por promover aumento nos custos da solução”; a flexibilidade da SOA que “corroboram sua adequação ao desenvolvimento de sistemas que demandem respostas em tempo real”, quando essa flexibilidade se paga justamente em desempenho. Oração iniciada por porque, desde que, uma vez que ou a fim de merece leitura separada: o fato pode estar certo e a justificativa, inventada.

Generalização. “A comunicação entre cliente e servidor ocorre de forma síncrona.” Cliente e servidor que “devem ser executados em computadores diferentes” — são papéis lógicos. Um cache de registro de serviços “garantindo sempre dados atualizados”. Um serviço “encapsulando todas as funções que sejam necessárias para a sua execução e gerando independência em relação a outros serviços”. Regra de negócio que “fica totalmente na camada intermediária, sem qualquer distribuição para as camadas de apresentação ou de dados”. Achado o absoluto — sempre, todo, devem, apenas, totalmente —, procure o caso que ele exclui.

Número trocado. Raro aqui: dois itens no tópico inteiro, ambos baratos de escrever — o modelo OSI definido por “nove camadas” e a documentação de API seguindo “o padrão Swagger 2.0”, quando a referência atual é o OpenAPI 3.

Erros clássicos

Achar que cliente-servidor exige máquinas separadas. Não exige: é um modelo lógico de papéis, e as duas metades podem estar no mesmo computador.

Confundir camada lógica com camada física. Três camadas descrevem responsabilidades, não servidores. E a apresentação, nessa divisão, pertence ao cliente.

Pôr regra de negócio na apresentação. A camada de apresentação cuida da lógica de interface. Item que espalhe as regras de negócio entre apresentação e negócio está errado, por mais razoável que soe.

Tratar microsserviço como “API fatiada”. É unidade de negócio com processo, dado e implantação próprios. Nada nele exige linguagem única, servidor único ou banco compartilhado.

Achar que serverless significa ausência de servidor. Os servidores existem; o que desaparece é a gestão deles pelo cliente — e o provedor provisiona sob demanda, de modo que exigir infraestrutura pré-provisionada contraria o modelo.

Trocar orquestração por coreografia. Orquestração tem maestro e ordem preestabelecida; coreografia tem mensagens e nenhum regente central.

Confundir serviço com protocolo. O que uma camada oferece à de cima é serviço; protocolo é o acordo entre pares do mesmo nível.

Esperar que SOA e microsserviços sejam sinônimos. Compartilham a ideia de serviço e divergem em tudo o que a prova pergunta: granularidade, propriedade do dado, barramento e independência de implantação.