Prova 2 · Arquitetura e Detalhes
Partes V e VI: fronteiras, Arquitetura Limpa, detalhes
Objetivas
0/20 respondidas1.
Um time inicia um projeto escolhendo Kubernetes, 12 microsserviços, Kafka e um ORM antes de entender os casos de uso. Seis meses depois, pouca funcionalidade foi entregue. À luz dos caps. 15–17, qual o diagnóstico?
2.
Em uma Arquitetura Limpa, o caso de uso
TransferirSaldo precisa enviar e-mail de confirmação. Qual opção respeita a Regra da Dependência?3.
Um caso de uso retorna a entidade
Cliente para o controller, que a serializa em JSON. Qual o problema?4.
Qual a sequência correta de círculos atravessada por uma requisição web até a regra crítica, e de volta?
5.
Um presenter formata valores monetários e define
botaoPagarHabilitado = false. A View apenas exibe. O que se ganha?6.
Um sistema pequeno tem chance moderada de precisar de outro mecanismo de persistência no futuro. Implementar uma fronteira completa agora é caro. Qual solução intermediária o livro descreve?
7.
Onde deve ficar a leitura de variáveis de ambiente, a criação de conexões e o registro de implementações concretas em um container de DI?
8.
Uma empresa migrou para microsserviços e acredita estar desacoplada. Para adicionar um novo tipo de cliente, precisa alterar 9 serviços. Qual a análise correta (cap. 27)?
9.
Uma suíte de testes de aceitação via Selenium quebra a cada ajuste de CSS. Como o cap. 28 propõe resolver?
10.
Em um termostato embarcado, a lógica de controle acessa registradores do microcontrolador diretamente. Troca do chip força reescrever tudo. O que faltou?
11.
Qual afirmação sobre bancos de dados está de acordo com o cap. 30?
12.
Uma empresa migrou de páginas renderizadas no servidor para SPA, depois para server components. Cada mudança reescreveu regras de negócio. Qual conceito explica e qual lição tirar?
13.
Entidades de domínio anotadas com
@Entity (JPA) e @JsonProperty (Jackson). Pela ótica do cap. 32, o que acontece?14.
Um repositório organiza pastas em
pacientes/, consultas/, prescricoes/, cada uma com casos de uso e portas. Isso exemplifica:15.
Simon Brown critica arquiteturas em que todas as classes são
public. Qual o argumento central?16.
No programa de criptografia do cap. 19, qual design está correto?
17.
Qual alternativa descreve corretamente o papel de threads em relação a fronteiras arquiteturais?
18.
No estudo de caso de vendas de vídeo, por que o sistema é dividido primeiro por atores?
19.
Qual afirmação sobre "independência" (cap. 16) é correta?
20.
Qual cenário viola a Regra da Dependência?
Dissertativas
autoavaliação · não entram na notaD1.
Desenhe (em texto) a Arquitetura Limpa para um caso de uso "Emitir Nota Fiscal" acionado por uma API REST e persistido em PostgreSQL. Indique interfaces, DTOs e a direção das dependências.
Ver resposta modelo
Entidades:
NotaFiscal, Item, regras de cálculo de impostos.
Casos de uso: EmitirNotaFiscal (Interactor) + EmitirNotaInput (input port) + EmitirNotaOutput (output port) + RepositorioNotas (gateway interface). DTOs: EmitirNotaRequest, EmitirNotaResponse.
Adaptadores: NotaController (converte HTTP → Request e chama input port), NotaPresenter (implementa output port, gera ViewModel/JSON), RepositorioNotasPostgres (implementa gateway).
Frameworks: servidor HTTP, driver Postgres. Main monta tudo.
Todas as dependências de código apontam para dentro; fluxo de controle sai via interfaces (DIP).D2.
"Microsserviços são uma arquitetura." Avalie criticamente essa afirmação com base no cap. 27.
Ver resposta modelo
Falsa para Martin. Serviços são apenas mecanismo de implantação/comunicação: chamadas de função caras. Arquitetura é definida por fronteiras e pela Regra da Dependência.
Falácias: desacoplamento (dados compartilhados acoplam) e implantação/desenvolvimento independentes (mudanças de esquema atravessam serviços).
Problema dos gatinhos: feature transversal afeta todos os serviços. Solução: arquitetura de componentes dentro dos serviços, com polimorfismo (OCP). Serviços podem ser úteis para escala, mas não substituem arquitetura.
D3.
Explique por que banco de dados, web e frameworks são "detalhes" e quais consequências práticas isso tem no código.
Ver resposta modelo
São mecanismos de IO/entrega/persistência, não regras de negócio. Mudam por motivos tecnológicos, não de negócio.
Consequências: interfaces (gateways, portas) definidas no núcleo; implementações na borda; nada de ResultSet, HttpRequest ou anotações de framework em entidades/casos de uso; Main injeta os concretos; testes do núcleo rodam sem banco nem servidor.
Benefício: adiar decisões, trocar tecnologias e sobreviver ao pêndulo da UI.