Como você modela um domínio em classes bem projetadas?

Question

Accepted Answer

Boa modelagem de classe significa classes que mapeiam conceitos reais do domínio, cada uma com **uma responsabilidade clara**, relacionadas através de relacionamentos **is-a/has-a** honestos, e dependendo de **abstrações** nos limites. Não há fórmula, mas há um processo repetível. ## Um processo prático ```text 1. Find the NOUNS → candidate classes (Order, Customer, Payment) 2. Find the VERBS → candidate behaviors/methods (place, refund, ship) 3. Assign each behavior to the class that OWNS the data it needs (high cohesion) 4. Choose relationships: IS-A (rare, must pass LSP) vs HAS-A (default) 5. Depend on interfaces at boundaries (DIP); inject volatile dependencies 6. Keep invariants inside the object (encapsulation); prefer immutability for values ``` ## O comportamento segue os dados ```java // ❌ logic separated from data (anemic) → low cohesion class Order { List items; } class OrderCalculator { double total(Order o) {...} } // ✅ behavior lives with the data it operates on class Order { private final List items; public Money total() { // owns its own rule return items.stream().map(Item::price).reduce(Money.ZERO, Money::plus); } } ``` ## Heurísticas que mantêm hierarquias saudáveis | Heurística | Por quê | |---|---| | Prefira composição; use herança apenas para verdadeiras is-a | Evita armadilhas de classe base frágil / LSP | | Mantenha hierarquias rasas (2–3 níveis) | Árvores profundas acoplam tudo | | Uma razão para mudar por classe (SRP) | Localiza a mudança | | Programe para interfaces nos limites | Testabilidade, permutabilidade | | Torne objetos de valor imutáveis | Elimina uma classe de bugs | ## Armadilha Não modele o *mundo* inteiro antecipadamente. Comece pequeno com classes concretas; extraia abstrações apenas quando variação real aparecer (a regra de três). Hierarquias especulativas envelhecem mal. ## Por que isso importa Um modelo que espelha o domínio torna o código autoexplicativo — um novo engenheiro lê `order.refund()` e entende o negócio, não apenas a sintaxe. O retorno se acumula: classes coesivas e fracamente acopladas localizam mudanças, então recursos e correções de bugs afetam poucos arquivos em vez de se propagar pelo sistema.

Heurística	Por quê
Prefira composição; use herança apenas para verdadeiras is-a	Evita armadilhas de classe base frágil / LSP
Mantenha hierarquias rasas (2–3 níveis)	Árvores profundas acoplam tudo
Uma razão para mudar por classe (SRP)	Localiza a mudança
Programe para interfaces nos limites	Testabilidade, permutabilidade
Torne objetos de valor imutáveis	Elimina uma classe de bugs