Arquitetura de software: identificação de estilos
Gabarito: letra C. O cenário descreve clientes (web e mobile) que consomem APIs REST de um back-end conteinerizado (Docker) e orquestrado (Kubernetes), configurando uma arquitetura cliente-servidor combinada com microsserviços e contêineres orquestrados. As demais alternativas não se encaixam nas características descritas.
Alternativa | Descrição | Característica Principal | Correta? |
|---|
A | SOA com filas síncronas e acoplamento rígido | Comunicação REST síncrona, contêineres promovem desacoplamento | ❌ |
B | Peer-to-peer com comunicação direta | Distinção clara cliente-servidor, sem comunicação entre pares | ❌ |
C | Cliente-servidor com microsserviços e contêineres orquestrados | APIs REST, Docker, Kubernetes, alta disponibilidade e balanceamento | ✅ |
D | Monolítica com MVC centralizado | Múltiplos serviços independentes (microsserviços), não monolítico | ❌ |
E | Três camadas sem separação lógica | Separação lógica explícita (MVC) e uso de contêineres | ❌ |
Alternativa A — ❌ Incorreta
A alternativa sugere uma implementação de SOA baseada em filas síncronas e acoplamento rígido. No entanto, o cenário utiliza comunicação síncrona via REST (não filas) e o uso de contêineres e orquestração promove desacoplamento e escalabilidade, características opostas ao acoplamento rígido. Além disso, não há menção a barramento de serviços (ESB) ou contratos padronizados típicos de SOA.
Alternativa B — ❌ Incorreta
A arquitetura peer-to-peer (P2P) implica que cada nó atua como cliente e servidor simultaneamente, com comunicação direta entre pares. No cenário, há uma clara distinção entre clientes (web/mobile) e servidores (back-end), não havendo comunicação direta entre instâncias de clientes.
Alternativa C — ✅ Correta ⟵ GABARITO
A alternativa descreve exatamente o que é apresentado: clientes (aplicativo móvel e interface web) se comunicam com servidores (back-end) via APIs REST. Os servidores são implantados em contêineres Docker, orquestrados por Kubernetes para alta disponibilidade e balanceamento de carga, o que é típico de uma arquitetura de microsserviços. O uso de MVC internamente não descaracteriza o modelo cliente-servidor; ao contrário, é uma forma de organizar o código no servidor.
Alternativa D — ❌ Incorreta
A aplicação monolítica centraliza todos os componentes em uma única unidade executável. O cenário, porém, utiliza contêineres e orquestração, indicando que o sistema é composto por múltiplos serviços independentes (microsserviços), não sendo monolítico. O padrão MVC pode ser aplicado dentro de cada microsserviço, mas não torna a arquitetura monolítica.
Alternativa E — ❌ Incorreta
A arquitetura em três camadas (apresentação, negócio, dados) é um estilo comum, mas o cenário menciona explicitamente a separação da lógica da apresentação via MVC, o que já contradiz a afirmação de "sem separação lógica". Além disso, o uso de contêineres e APIs REST sugere uma arquitetura mais distribuída, não necessariamente restrita a três camadas físicas.
Gabarito: letra C.