Next.js o htmx + Rust. Qué usar y cuándo
Compare Next.js con Axum, Askama y htmx según el estado del navegador, contratos, caché, despliegue, seguridad, clientes móviles y entrega.
Palabras clave:
Patrones de diseño en la práctica. Cuándo ayudan y cuándo complican el código
Un patrón de diseño no demuestra experiencia por sí solo. Es el nombre de una solución que ha funcionado repetidamente ante un tipo concreto de problema. Si ese problema no existe, el patrón añade archivos, interfaces y vocabulario sin reducir un riesgo real.
Por eso, al diseñar software empresarial no empezamos preguntando qué patrón podríamos aplicar. Primero buscamos qué parte cambiará, quién será responsable del cambio y qué debe permanecer estable. La respuesta puede conducir a Strategy, Adapter, Factory o a una función directa.
Decida según el cambio esperado, no según el nombre del patrón
La abstracción más pequeña que aísla un cambio probable suele ser la adecuada.
Una regla estable
Mantenga una función directa.
Algoritmo cambiante
Considere Strategy.
Interfaz externa
Aíslela con un Adapter.
Varias formas de creación
Una Factory puede ocultar el ensamblaje.
El código simple no es código primitivo
Pensemos en el cálculo de gastos de envío. La primera versión admite recogida y un transportista. Dos condiciones dentro de una función se entienden mejor que una jerarquía de clases. Entrada, regla y resultado permanecen juntos.
La presión aparece cuando las reglas evolucionan por separado. Un transportista calcula por peso y otro por región. Los clientes con contrato tienen condiciones propias. La función acumula varios motivos independientes para cambiar. Un ajuste para un proveedor puede perjudicar otras rutas.
Un buen diseño no reacciona al número de líneas. Reacciona a los motivos independientes de cambio. Cincuenta líneas estables pueden ser más sencillas que diez modificadas cada semana por razones empresariales diferentes.
Strategy separa una regla variable
Strategy encaja cuando la tarea permanece estable, pero el algoritmo puede cambiar. Seguimos calculando un precio de envío. El método varía según transportista o contrato.
type DeliveryQuote = (order: Order) => Money;
const quoteDelivery = (order: Order, quote: DeliveryQuote): Money =>
quote(order);
Una Strategy no necesita ser una clase. En TypeScript suelen bastar un tipo y varias funciones puras. El pedido no conoce la tarifa del transportista, y el cálculo no necesita saber de dónde procede el pedido. Se añade una regla sin editar algoritmos existentes.
El patrón no conviene cuando solo existe un cálculo estable o cuando las variantes comparten mucho estado mutable. En ese caso, pequeños archivos Strategy se limitan a mover las condiciones. Antes hay que encontrar la frontera real.
Adapter protege el dominio de una interfaz ajena
Un ERP, una pasarela de pago o un transportista aportan nombres, tipos de datos y errores propios. Si entran directamente en el núcleo, el dominio empieza a hablar el idioma del proveedor. La siguiente versión del API afecta entonces a pedidos, facturas e interfaz de usuario.
Adapter traduce el modelo externo a un contrato pequeño que pertenece a nuestro sistema. El dominio puede pedir reserveStock aunque un ERP exponga movimientos de almacén y otro reservas de artículos. La diferencia queda en el límite de integración.
La frontera también mejora las pruebas. Una prueba de dominio no necesita red ni un entorno de pruebas del proveedor. Comprueba el comportamiento contra el contrato propio. Otra prueba de integración demuestra la traducción correcta de solicitudes, respuestas y fallos.
Adapter no debe convertirse en un cajón para cualquier desorden. Si solo cambia el nombre de cada campo y la interfaz externa es estable, aporta poco. Su valor aumenta con la distancia semántica entre el modelo externo y nuestro dominio.
Factory oculta el montaje
Factory ayuda a crear un objeto o flujo cuando el montaje depende del tipo de entrada. Un procesador de facturas PDF puede necesitar OCR, validación y mapeo contable. Un contrato utiliza otro extractor y controles diferentes.
Quien llama no tiene por qué conocer el orden de todas las dependencias. Solicita un procesador para un tipo de documento. Factory lo compone y lo devuelve mediante un contrato común.
El criterio empresarial no debe desaparecer dentro de una Factory enorme con muchas ramas. Elegir componentes técnicos pertenece al montaje. Decidir si una factura puede contabilizarse automáticamente es una regla del dominio. Debe seguir visible y contar con pruebas propias.
La misma función, otro punto de cambio
Los patrones merecen su lugar cuando reducen el alcance del siguiente cambio real.
Antes
Un servicio conoce precios, proveedores y formatos de documentos.
Después de separar
El dominio llama a una interfaz pequeña y el detalle queda detrás del límite.
El patrón debe limitar el alcance del próximo cambio
Durante la revisión sirven tres preguntas. ¿Podemos nombrar un cambio concreto y esperado? ¿El patrón mantendrá ese cambio detrás de una frontera? ¿El resultado será más claro para alguien que no conoce la historia de la decisión?
Si la respuesta es negativa, probablemente la abstracción llegó pronto. El código no tiene que cubrir todos los futuros imaginables. Debe responder a los cambios que se desprenden del producto, los contratos y la operación.
Los patrones pueden colaborar. Adapter entrega una interfaz propia al dominio. Strategy contiene la regla variable y Factory compone las dependencias. La combinación solo tiene sentido si cada pieza protege una frontera distinta. Si tres nombres describen una condición, el diseño es demasiado grande.
Qué debe preguntar quien contrata
La dirección de una empresa no necesita revisar un diagrama de clases. Necesita saber si un nuevo método de pago o un cambio de ERP afecta a toda la aplicación. La dirección técnica debe ver dónde vive la regla, qué contrato la contiene y qué prueba protege su comportamiento.
En el desarrollo de software a medida conectamos cada frontera técnica con un cambio empresarial esperado. El siguiente artículo lleva la misma idea a la elección entre monolito modular y microservicios. Para el efecto de la IA en el trabajo de desarrollo puede leer el análisis sobre control humano en desarrollo asistido por IA.
El mejor patrón casi desaparece durante el trabajo diario. El próximo cambio tiene un lugar evidente, la prueba tiene un propósito claro y el resto del sistema no necesita conocerlo. Antes de añadir una abstracción conviene comprobar si una función directa mantiene el mismo espacio de cambio con mayor claridad. Un nombre conocido no aporta valor por sí mismo. Lo aporta una reducción demostrable del riesgo.
Fuentes y evidencias
Cómo se elaboró este artículo
Maroš Bednár preparó el artículo con apoyo de IA para la investigación y la edición lingüística. Revisó y aprobó las conclusiones técnicas, los ejemplos y el texto final.
Fundador y responsable técnico de Rise.sk. Diseña y entrega aplicaciones web, sistemas de datos y automatizaciones, y escribe sobre decisiones de software, IA y servicios digitales.
- Arquitectura de software
- Automatización con IA
- Sistemas de datos
Leer a continuación
Evaluación de proveedores de software. Seguridad y propiedad
Una lista de verificación sobre seguridad, integraciones, roles de datos, propiedad, soporte y salida antes de firmar un contrato de software.
Cómo elegir un socio de software y tecnología
Una guía práctica para definir requisitos, comparar proveedores, validar evidencias de entrega y decidir con el equipo.