System Design
Diagramas de clases
Explica cómo representar clases, atributos, operaciones, asociaciones y responsabilidades sin confundir un modelo conceptual con la estructura exacta del código.
- Última actualización
- Actualizada
- Nivel
- Aplicación
System Design
Explica cómo representar clases, atributos, operaciones, asociaciones y responsabilidades sin confundir un modelo conceptual con la estructura exacta del código.
Un diagrama de clases explica estructura y comportamiento orientado a objetos. No es un ERD con métodos añadidos ni una captura automática de todo el código.
Un class diagram representa clases, interfaces, atributos, operaciones y relaciones relevantes para comprender un modelo o una colaboración concreta.
Cuando el diseño solo existe en código, cuesta revisar responsabilidades, dependencias y variaciones antes de implementar. El diagrama permite discutir límites y relaciones sin leer cientos de archivos.
Incluye nombre, atributos y operaciones solo cuando aportan significado.
Expresa un contrato que puede tener varias implementaciones.
Objetos mantienen una relación estructural.
Una clase usa otra temporalmente, por ejemplo como parámetro.
Una clase especializada es sustituible por la base. No debe usarse solo para reutilizar código.
Una clase implementa una interfaz.
La parte pertenece al ciclo de vida del todo.
Relación todo-parte débil; suele ser ambigua y conviene usarla con cautela.
1, 0..1, * y 1..* indican cuántas instancias pueden participar. Deben corresponder a reglas reales.
classDiagram
class Order {
-OrderId id
-OrderStatus status
-OrderLine[] lines
+addLine(productId, quantity, price)
+confirm()
+cancel(reason)
+total() Money
}
class OrderLine {
-ProductId productId
-Quantity quantity
-Money unitPrice
+subtotal() Money
}
class PaymentPort {
<<interface>>
+charge(orderId, amount) PaymentResult
+refund(paymentId, amount) RefundResult
}
class PlaceOrder {
+execute(command) OrderResult
}
Order "1" *-- "1..*" OrderLine : contains
PlaceOrder --> Order : coordinates
PlaceOrder ..> PaymentPort : usesOrder protege reglas de modificación y estado.OrderLine pertenece al ciclo de vida del pedido.PlaceOrder coordina el caso, pero no decide las invariantes internas del pedido.PaymentPort separa el contrato de la implementación externa.| Class Diagram | ERD |
|---|---|
| Modela objetos y comportamiento | Modela persistencia e integridad |
| Incluye operaciones e interfaces | Incluye claves y relaciones de datos |
| Puede contener elementos no persistentes | Puede contener tablas técnicas |
| Composición expresa ciclo de vida de objetos | FK y cascada expresan integridad física |
Una clase no tiene que corresponder a una tabla.
La herencia es adecuada cuando existe una relación estable “es un” y sustitución válida. Para variaciones de comportamiento, composición mediante interfaces suele facilitar pruebas y evolución.
Malo:
PaymentServiceBase
├─ StripePaymentService
├─ PayPalPaymentService
└─ CashPaymentServicesi los flujos no comparten realmente el mismo contrato.
Mejor puede ser una estrategia PaymentMethod con capacidades explícitas.
Un diagrama conceptual muestra entidades, value objects y asociaciones importantes. Uno de implementación puede incluir servicios, puertos y adaptadores. No mezcles niveles sin explicar el propósito.
Una composición conceptual no implica cargar todos los hijos en memoria. El modelo y la estrategia de carga son decisiones diferentes.
Añadir referencias en ambos sentidos aumenta sincronización y acoplamiento. Solo hazlo si ambos lados necesitan navegar.
Puede romper invariantes si varias partes modifican el mismo objeto sin coordinación.
Pueden ser útiles como puerto, pero crear una interfaz por cada clase sin variación real añade ruido.
Para explorar un modelo de dominio, explicar patrones internos, preparar refactorizaciones o comunicar contratos entre objetos. No es necesario documentar todo el sistema de esta forma.
OrderLine puede ser composición de Order sin tener una tabla embebida?Responsabilidades y colaboración explica cómo decidir quién conoce, coordina y protege cada comportamiento.