Questão de Arquitetura de Software — Padrões de Arquiteturas Corporativas — CESPE / CEBRASPE 2024
Arquitetura de Software›Padrões de Arquiteturas Corporativas
Código
ce176007
Banca
CESPE / CEBRASPE
Órgão
LNA
Ano
2024
Nível
Superior
Cargo
Tecnologista – Especialidade: Desenvolvimento e Arquitetura de Software
Uma instituição de ensino superior tem um sistema de resultados escolares e outros sistemas relacionados como apoio à colocação profissional, pós-graduação e de controle de egressos. Quando o sistema de resultados escolares registra uma conclusão de um curso de graduação, todos os sistemas relacionados devem ser notificados assim que o registro da conclusão ocorra, ainda que de forma assíncrona.Com base nessa situação, assinale a opção em que é apresentada a arquitetura de software mais apropriada para resolver especificamente a demanda citada desses sistemas.
Amicrosserviços
Bpeer-to-peer
Cmonolítica
DMVC (model-view-controller)
Epublish/subscribe
Revelar gabarito e comentário▾
GabaritoE — publish/subscribe
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
Arquitetura de Software: Notificação de Eventos
Gabarito: letra E (publish/subscribe). A demanda descrita — notificar múltiplos sistemas assim que um evento ocorrer, de forma assíncrona — é resolvida de forma direta pelo padrão publish/subscribe (pub/sub), no qual o sistema de resultados escolares atua como editor (publisher) e os demais sistemas como assinantes (subscribers), recebendo a notificação quando o evento "conclusão de curso" é publicado. Esse estilo arquitetural é o mais apropriado por atender exatamente a necessidade de comunicação assíncrona e desacoplada entre sistemas.
SE LIGUE NESSA!
O padrão publish/subscribe é um subconjunto da arquitetura orientada a eventos, onde os componentes se comunicam por meio de um canal de eventos, sem conhecerem uns aos outros diretamente.
Critério
Microsserviços (A)
Peer-to-Peer (B)
Monolítica (C)
MVC (D)
Publish/Subscribe (E)
Propósito principal
Estruturar sistema como serviços independentes
Rede descentralizada entre pares
Sistema único e integrado
Separação entre modelo, visão e controle
Comunicação assíncrona entre componentes via eventos
Atende notificação assíncrona?
Não diretamente (precisa de mecanismo adicional)
Não (foco em compartilhamento descentralizado)
Não (requer mecanismo externo)
Não (foco em interação usuário-sistema)
Sim (editor publica evento, assinantes recebem)
Desacoplamento entre sistemas
Parcial (serviços independentes, mas comunicação síncrona comum)
Alto (nós autônomos)
Baixo (tudo acoplado)
Baixo (componentes do mesmo sistema)
Alto (editores e assinantes não se conhecem)
Adequação ao cenário
Solução ampla, não específica para notificação
Inadequado (não há centralização de evento)
Inadequado (não escala para múltiplos sistemas externos)
Inadequado (não resolve comunicação entre sistemas)
Ideal (notifica múltiplos sistemas assim que evento ocorre)
Alternativa A — ❌ Incorreta
Microsserviços é um estilo arquitetural que estrutura o sistema como um conjunto de serviços independentes. Embora seja compatível com notificações via pub/sub, não é a solução específica para a demanda de notificação — ela seria uma abordagem mais ampla e não resolve por si só a comunicação assíncrona; seria necessário implementar pub/sub ou outra técnica dentro de microsserviços.
Alternativa B — ❌ Incorreta
Peer-to-peer (P2P) é uma arquitetura descentralizada onde cada nó é tanto cliente quanto servidor. Não se aplica ao cenário de um sistema central que precisa notificar múltiplos sistemas de forma controlada; P2P é mais adequado para compartilhamento de arquivos ou redes descentralizadas.
Alternativa C — ❌ Incorreta
Monolítica concentra toda a lógica em um único bloco. Não atende à necessidade de notificar sistemas externos de forma assíncrona; seria necessário um mecanismo adicional (como filas) e mesmo assim a arquitetura não é a mais apropriada para integração com múltiplos sistemas.
Alternativa D — ❌ Incorreta
MVC (Model-View-Controller) é um padrão de separação de responsabilidades no front-end/back-end, focado na interação com o usuário. Não se destina a comunicação entre sistemas distintos; a notificação entre sistemas não é seu propósito.
Alternativa E — ✅ Correta ⟵ GABARITO
Publish/subscribe é o padrão ideal: o sistema de resultados publica um evento no canal "conclusão de curso", e todos os sistemas interessados (colocação profissional, pós-graduação, egressos) se inscrevem para recebê-lo. A comunicação é assíncrona e desacoplada, atendendo exatamente ao requisito.