¿Cómo modelas un dominio en clases bien diseñadas?

Question

Accepted Answer

El buen modelado de clases significa clases que se asignan a conceptos de dominio reales, cada una con **una responsabilidad clara**, relacionadas a través de relaciones **is-a/has-a** honestas, y dependientes de **abstracciones** en los límites. No hay fórmula, pero hay un proceso repetible. ## Un proceso práctico ```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 ``` ## El comportamiento sigue a los datos ```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 mantienen las jerarquías saludables | Heurística | Por qué | |---|---| | Prefiere composición; usa herencia solo para is-a verdadero | Evita trampas de fragile base class / LSP | | Mantén las jerarquías planas (2–3 niveles) | Los árboles profundos acoplan todo | | Una razón para cambiar por clase (SRP) | Localiza el cambio | | Programa hacia interfaces en las costuras | Testabilidad, intercambiabilidad | | Haz los value objects inmutables | Elimina una clase de errores | ## Trampa No modeles el *mundo* completo de antemano. Comienza pequeño con clases concretas; extrae abstracciones solo cuando aparece variación real (la regla de tres). Las jerarquías especulativas envejecen mal. ## Por qué es importante Un modelo que refleja el dominio hace que el código sea autoexplicativo — un nuevo ingeniero lee `order.refund()` y entiende el negocio, no solo la sintaxis. El beneficio se multiplica: las clases cohesivas y débilmente acopladas localizan el cambio, por lo que las características y las correcciones de errores tocan pocos archivos en lugar de propagarse por todo el sistema.

Heurística	Por qué
Prefiere composición; usa herencia solo para is-a verdadero	Evita trampas de fragile base class / LSP
Mantén las jerarquías planas (2–3 niveles)	Los árboles profundos acoplan todo
Una razón para cambiar por clase (SRP)	Localiza el cambio
Programa hacia interfaces en las costuras	Testabilidad, intercambiabilidad
Haz los value objects inmutables	Elimina una clase de errores