Estudos gratuitos da ER Soluções WebVer outros conteúdos grátis
ER Soluções WebEstudos · Patterns of Enterprise Application Architecture

Prova 1 · Camadas, Domínio e Fonte de Dados

Introdução, cap. 1–3, 8, 9 e 10: camadas, organização do domínio, padrões de acesso a dados

Objetivas

0/20 respondidas
1.
Uma fintech começou com cadastros simples em Transaction Script. Dois anos depois, regras de crédito variam por produto, região e perfil, e a mesma validação aparece copiada em 14 scripts. Segundo Fowler, qual a evolução mais adequada?
2.
Um time .NET com telas CRUD ligadas a grids, lógica moderada e uso intenso de DataSet pergunta qual combinação de padrões usar. Qual a resposta coerente com o livro?
3.
Em uma revisão de arquitetura, alguém afirma: "Nossa camada de domínio importa HttpServletRequest para ler parâmetros". Qual crítica correta Fowler faria?
4.
Qual par de métricas melhor descreve um sistema que atende 1.000 requisições/s, mas cada uma leva 3 s?
5.
Um sistema usa Active Record. O time introduziu herança de três níveis, Value Objects e uma tabela legada que junta dois conceitos. Os testes de domínio exigem banco. Qual o diagnóstico?
6.
Qual alternativa descreve corretamente as diferenças entre os quatro padrões arquiteturais de fonte de dados?
7.
Uma API REST, um app móvel e um job noturno executam 'Fechar fatura', que grava dados, envia e-mail e publica evento. A lógica está copiada nos três. Qual padrão resolve e com qual cuidado?
8.
Por que Fowler diz que a lógica de negócio é muitas vezes 'ilógica', e qual consequência isso tem para a arquitetura?
9.
Uma classe PedidoGateway tem campos espelhando colunas e métodos insert/update. Um dev adiciona calcularFrete() com regras de negócio. O que aconteceu, em termos de padrões?
10.
No contexto de 'Juntando Tudo' (cap. 8), qual sequência de decisão Fowler recomenda?
11.
Um gerente propõe: "Cada camada deve rodar em uma máquina separada para ficar bem arquitetado". Qual a melhor resposta baseada nos cap. 1 e 7?
12.
Uma tela lista 300 contratos com nome do cliente. O código faz 1 consulta de contratos + 300 consultas de clientes. Qual princípio do cap. 3 foi violado e como corrigir?
13.
Qual afirmação sobre Table Module está incorreta?
14.
Em um Domain Model com Data Mapper, o objeto Cliente precisa listar seus contratos vencidos sem depender da camada de mapeamento. Qual combinação de padrões viabiliza isso?
15.
Por que Fowler prefere um Service Layer 'fino'?
16.
Qual cenário justifica Transaction Script mesmo em uma equipe experiente em OO?
17.
Um Row Data Gateway é usado por Transaction Scripts. O mesmo pedido é lido duas vezes no mesmo script e alterado em ambas as cópias. Que padrão do cap. 11 Fowler sugere considerar?
18.
Qual é o papel do padrão Gateway (cap. 18) em relação a Table e Row Data Gateway?
19.
Qual opção define 'arquitetura' no sentido usado por Fowler?
20.
Um sistema usa Domain Model + Data Mapper construído à mão, com 40 classes. O time gasta metade do tempo mantendo mappers. Qual recomendação Fowler daria?

Dissertativas

autoavaliação · não entram na nota
D1.
Compare Transaction Script, Table Module e Domain Model: estrutura, quando usar e padrão de fonte de dados que combina com cada um.
Ver resposta modelo
Transaction Script: um procedimento por ação; simples; bom para lógica simples; duplica regras ao crescer. Fonte: Row ou Table Data Gateway. Table Module: uma instância por tabela, opera sobre Record Set; meio-termo; ótimo com UI ligada a dados (.NET). Fonte: Table Data Gateway. Domain Model: objetos com dados e comportamento, polimorfismo; custo inicial maior, compensa em lógica complexa. Fonte: Active Record (simples) ou Data Mapper (rico), com Unit of Work, Identity Map e Lazy Load. Critério principal: complexidade da lógica; equipe e ferramentas também pesam.
D2.
Explique a diferença entre lógica de domínio e lógica de aplicação e como o Service Layer organiza as duas. Dê um exemplo.
Ver resposta modelo
Lógica de domínio: regras do problema (calcular receita, validar crédito). Lógica de aplicação: responsabilidades do caso de uso (transação, segurança, notificar, integrar). Service Layer define a fronteira da aplicação: operações por caso de uso, abre/fecha transação, coordena respostas e delega regras ao domínio. Deve ser fino. Exemplo: FaturaService.fechar(id): abre transação, chama fatura.fechar() (domínio calcula), grava, envia e-mail e publica evento (aplicação).
D3.
Quando usar Active Record e quando usar Data Mapper? Justifique com custos e benefícios.
Ver resposta modelo
Active Record: objeto = linha + SQL + regras. Simples, pouco código. Ideal quando classes casam 1:1 com tabelas e a lógica é moderada. Custos: acopla domínio ao esquema, dificulta herança, coleções complexas e testes sem banco. Data Mapper: camada separada move dados entre objetos e banco; domínio não conhece o banco. Ideal para Domain Model rico ou esquema legado divergente. Custos: mais uma camada, mais código; normalmente se usa ferramenta O/R. Regra: comece simples; migre para Data Mapper quando o modelo divergir do esquema.
Seu progresso fica salvo neste navegador.