Extender un framework de terceros sin tocar su núcleo
Cuándo la respuesta correcta no es forkear ni parchear, sino diseñar tu funcionalidad como un ciudadano externo bien portado del sistema que extiendes.
Cualquier framework maduro de e-commerce, CMS o backoffice llega a un punto en el que no cubre exactamente lo que tu negocio necesita. La reacción instintiva suele ser una de dos: forkear el framework y modificarlo directamente, o llenar el código de parches específicos del negocio en medio de la lógica del framework. Ambas resuelven el problema a corto plazo y lo empeoran a largo plazo. La primera te desincroniza de las actualizaciones futuras, la segunda hace que cada actualización sea una negociación con tu propio código.
La pregunta que cambia el diseño
Antes de escribir una sola línea, vale la pena hacer una pregunta simple: ¿esta funcionalidad necesita vivir dentro del framework, o puede vivir junto a él, observando y reaccionando a sus eventos?
Un ejemplo concreto: construir un programa de referidos sobre un framework de e-commerce existente. La tentación es modificar el modelo de pedido del framework para añadir campos de referido. La alternativa, casi siempre mejor, es tratar el programa de referidos como un módulo propio, con sus propios modelos (ReferralCode, ReferralCredit, ReferralUse), que se suscribe a los eventos que el framework ya emite (un pedido completado, un usuario creado) sin necesitar modificar una sola línea del núcleo.
Por qué esto importa más de lo que parece
La diferencia no es estética. Es una cuestión de superficie de acoplamiento:
- Si tu código vive dentro del framework, cada actualización de esa dependencia es una fusión potencial de conflictos entre tu lógica de negocio y los cambios internos del mantenedor.
- Si tu código vive junto al framework, reaccionando a eventos y extendiendo por composición (hooks, callbacks, un patrón de observador), una actualización del framework rara vez rompe tu módulo, porque tu módulo nunca dependió de sus detalles internos, solo de su contrato público de eventos.
Esto es, en esencia, el principio de inversión de dependencias aplicado a la relación entre tu negocio y una dependencia externa que no controlas: depende de abstracciones (eventos, contratos), no de la implementación concreta del framework.
El costo que sí hay que aceptar
Esta disciplina no es gratuita. Diseñar como módulo externo obliga a resolver problemas que el acceso directo al núcleo resolvería trivialmente, por ejemplo, cómo prevenir que dos procesos concurrentes usen el mismo código de referido dos veces, o cómo expirar créditos de forma consistente sin un job que dependa de detalles internos del framework. La disciplina de mantenerte fuera del núcleo obliga a resolver esos problemas explícitamente, en tu propio dominio, en lugar de apoyarte silenciosamente en garantías internas del framework que pueden cambiar sin aviso.
La lección que se generaliza
Esto no es exclusivo de e-commerce. Cualquier integración con un sistema de terceros, un CRM, un ERP, una plataforma de pagos, enfrenta la misma decisión: ¿extiendo el sistema desde dentro, o construyo alrededor de él? La respuesta casi siempre favorece construir alrededor, y el costo de hacerlo bien, modelar tu propio dominio, depender de contratos públicos y no de implementación interna, se paga una sola vez. El costo de no hacerlo se paga en cada actualización, para siempre.