9.2. Domain Model
Objetos de domínio com dados + comportamento, colaborando entre si.
Resumo
- Modelo de objetos do domínio com dados e comportamento juntos. Cada objeto é uma entidade significativa.
- Simples: parece o esquema do banco (Active Record). Rico: herança, estratégias, padrões GoF (Data Mapper).
- Lógica distribuída: cada objeto faz a sua parte; evita a duplicação dos scripts.
- Custo: curva de aprendizado e mapeamento ao banco. Mantenha o modelo independente de outras camadas.
- Use quando as regras são complexas e mutáveis. Evite classes de domínio inchadas com regras de um só caso de uso.
Perguntas-chave
responda de cabeça, depois abraQual a diferença entre Domain Model simples e rico?
Simples: quase uma classe por tabela (Active Record). Rico: herança, estratégias e muitos objetos pequenos (Data Mapper).
Por que o Domain Model é difícil de mapear para o banco?
Objetos têm herança, coleções e referências; tabelas têm linhas e chaves. É preciso traduzir as estruturas.
Onde fica a regra específica de um único caso de uso?
Fowler sugere colocá-la na camada de aplicação (ou script), não inchando a classe de domínio.
Exercícios de fixação
0/5 respondidas1.
As regras de reconhecimento de receita variam por tipo de produto. Em um Domain Model, como isso é tratado de forma idiomática?
2.
Qual padrão de fonte de dados combina com um Domain Model rico?
3.
Qual é a principal desvantagem do Domain Model?
4.
Uma regra só é usada no caso de uso 'Exportar relatório anual'. Onde Fowler sugere colocá-la?
5.
Por que o Domain Model evita a duplicação típica de Transaction Script?