System Design
Explica cómo asignar responsabilidades y diseñar colaboraciones entre objetos, componentes y servicios para mantener cohesión, límites claros y dependencias explícitas.
Diseñar responsabilidades significa decidir quién conoce información, quién toma decisiones y quién coordina colaboradores. Una responsabilidad sin dueño termina duplicada; un dueño con demasiadas responsabilidades termina acoplado a todo.
La asignación de responsabilidades busca alta cohesión y acoplamiento controlado. Cada elemento debería cambiar por razones relacionadas y depender solo de aquello que necesita.
En un diseño improvisado, el controller valida reglas, calcula precios, consulta inventario, cobra, persiste y envía correos. Funciona al inicio, pero cualquier cambio toca el mismo punto y las pruebas requieren montar todo el sistema.
Separar responsabilidades no significa crear una capa por moda. Significa ubicar decisiones donde existe la información adecuada y hacer explícitas las colaboraciones.
entrada
→ coordinador del caso
→ objetos que protegen reglas
→ puertos para capacidades externas
→ persistencia y efectos
→ resultadoMantener datos necesarios para responder una pregunta.
Aplicar una regla o elegir un cambio válido.
Ordenar varias colaboraciones para completar un caso de uso.
Adaptar información entre límites o formatos.
Guardar y recuperar sin apropiarse de las reglas del dominio.
Publicar un evento, notificar o invocar un sistema externo.
Asigna una decisión al objeto que posee la información necesaria. Order puede calcular su total porque conoce sus líneas.
Un objeto puede crear otro cuando lo contiene, lo registra o tiene los datos necesarios. No es una obligación universal.
Recibe un evento del sistema y delega en el caso de uso. No debería absorber toda la lógica.
Las responsabilidades de un elemento están relacionadas. Una clase que gestiona pedidos, emails y reportes carece de cohesión.
Reduce dependencias innecesarias, especialmente hacia detalles volátiles.
Delega variaciones de comportamiento a implementaciones con un contrato común cuando la variación es real.
Introduce un mediador cuando reduce acoplamiento significativo, no como capa automática.
Estabiliza puntos que probablemente cambien mediante contratos o límites.
Las tarjetas Class–Responsibility–Collaborator permiten explorar rápidamente.
Elemento: PlaceOrder
Responsabilidades:
- validar autorización del caso
- coordinar inventario, pedido y pago
- devolver resultado consistente
Colaboradores:
- Order
- InventoryPort
- PaymentPort
- OrderRepositoryLa tarjeta ayuda a detectar si un elemento acumula demasiadas tareas.
class PlaceOrder {
constructor(
private readonly inventory: InventoryPort,
private readonly payments: PaymentPort,
private readonly orders: OrderRepository,
) {}
async execute(command: PlaceOrderCommand) {
const reservation = await this.inventory.reserve(command.items);
try {
const order = Order.create(command, reservation);
const payment = await this.payments.charge(order.id, order.total());
order.confirm(payment.id);
await this.orders.save(order);
return order.snapshot();
} catch (error) {
await this.inventory.release(reservation.id);
throw error;
}
}
}Order.Protege reglas y significado.
Coordina un objetivo del usuario o sistema.
Implementa persistencia, red, broker y proveedores.
Esta separación es útil cuando refleja responsabilidades reales. En una aplicación pequeña pueden convivir en menos archivos sin mezclar decisiones.
Un puerto expresa qué capacidad necesita el núcleo:
interface PaymentPort {
charge(orderId: string, amount: Money): Promise<PaymentResult>;
}Stripe, un simulador o un proveedor futuro son adaptadores. El puerto debe diseñarse desde la necesidad del caso, no copiando el SDK externo.
Operaciones que deben ocurrir juntas pueden pertenecer al mismo límite. Sin embargo, agrupar todo para obtener una sola transacción puede crear un componente enorme. Distingue invariantes locales de procesos distribuidos.
Si el pago fue aprobado pero guardar el pedido falla, no basta con lanzar error. Se necesita idempotencia, reconciliación o compensación.
La regla puede divergir. Muévela a una política o entidad común.
El coordinador debe definir timeout, retry y respuesta parcial.
Si un service consulta varios objetos solo para decidir algo que pertenece a uno de ellos, probablemente la decisión está mal ubicada.
Demasiadas dependencias, métodos y razones de cambio.
Reglas y transacciones dentro del transporte.
Solo datos mutables y toda decisión fuera.
Nombres vagos que esconden responsabilidad.
Elementos que solo llaman al siguiente sin adaptar, proteger o coordinar nada.
La persistencia no debería decidir si un pedido puede cancelarse.
Más separación facilita pruebas y cambio, pero añade contratos y navegación. Menos capas reduce ceremonia, pero puede acoplar reglas a transporte o proveedores. El tamaño, complejidad y ritmo de cambio determinan el nivel adecuado.
No crees interfaces o servicios anticipando una variación puramente hipotética. Extrae cuando existe un límite, una dependencia costosa, varias implementaciones, necesidad de prueba o evolución probable respaldada por contexto.
Diseño de APIs y contratos convierte capacidades y responsabilidades en interfaces estables entre consumidores y proveedores.