Exercícios de fixação: Organizando a Lógica de Domínio

Question 1

Uma aplicação tem 10 casos de uso simples de cadastro, sem regras complexas, e a equipe não domina OO. Qual organização é mais indicada?

Accepted Answer

Transaction Script

Answer

Domain Model com herança rica

Answer

Domain Model com Data Mapper

Answer

Table Module sem Record Set

Question 2

No gráfico 'esforço × complexidade' de Fowler, o que acontece com o Transaction Script quando a lógica cresce?

Accepted Answer

O esforço sobe rápido pela duplicação de lógica entre scripts

Answer

O esforço cai porque cada script fica isolado dos outros

Answer

O esforço se mantém estável por não usar objetos

Answer

O esforço só cresce se houver um Service Layer por cima de todos os scripts

Question 3

O que distingue Table Module de Domain Model?

Accepted Answer

Table Module tem uma instância por tabela; Domain Model, uma por registro

Answer

Table Module guarda as regras de negócio; Domain Model contém só os dados das tabelas

Answer

Table Module exige herança; Domain Model proíbe qualquer herança

Answer

Table Module roda no banco; Domain Model roda sempre no cliente

Question 4

Em qual ambiente o Table Module brilha, segundo Fowler?

Accepted Answer

Plataformas com Record Set e componentes de UI ligados a dados, como .NET

Answer

Sistemas com regras de herança e polimorfismo muito ricas espalhadas pelo domínio

Answer

Aplicações sem banco relacional, que guardam tudo em arquivos XML

Answer

Sistemas distribuídos que trocam objetos remotos de grão fino

Question 5

Qual papel do Service Layer em relação às três organizações de domínio?

Accepted Answer

Pode ficar por cima de qualquer uma, definindo a fronteira da aplicação

Answer

Substitui o Domain Model quando a lógica de negócio fica complexa demais para objetos

Answer

Só funciona junto com Transaction Script, nunca com os outros

Answer

Fica abaixo da fonte de dados, organizando as consultas SQL

2. Organizando a Lógica de Domínio