Arquitectura robusta para procesadores de pago

Clase 27 de 27 • Curso de Patrones de Diseño y SOLID en Python

Resumen

El paso de un código que solo “funciona” a uno mantenible, escalable y flexible es claro cuando se aplican principios SOLID y patrones de diseño a un procesador de pagos real con Stripe. Aquí se explica cómo una clase con demasiadas responsabilidades se transformó en una arquitectura modular en Python, con decisiones que simplifican la evolución y el crecimiento del sistema.

Arquitectura que evoluciona

La versión inicial tenía una única clase con un método de procesar transacción que hacía de todo: validaba datos, cobraba en Stripe, notificaba y registraba. Paso a paso, se incorporaron principios SOLID —desde responsabilidad única hasta inversión de dependencias— y se reestructuró el sistema con módulos de Python y clases dedicadas a comportamientos específicos.

¿Qué problema resolvió responsabilidad única en el procesador de pagos?

Separación de validación, cobro, notificación y registro de eventos.
Clases enfocadas en una sola tarea.
Menor acoplamiento y cambios más seguros.
Pruebas más claras por unidad de comportamiento.

¿Cómo aporta inversión de dependencias a la flexibilidad?

Código que depende de abstracciones, no de implementaciones concretas.
Facilidad para intercambiar pasarelas sin reescribir flujos.
Integración del patrón Factory para decidir el procesador adecuado.
Evolución por configuración en lugar de cambios estructurales.

Patrones que hacen la diferencia

Además de la modularización, se integraron patrones que simplifican la creación de objetos, la selección de estrategias y la observabilidad del sistema, mejorando el control del flujo antes, durante y después del cobro.

¿Para qué se usó el patrón builder?

Instanciación sencilla de objetos complejos.
Construcción paso a paso de configuraciones del pago.
Lectura más clara al crear transacciones.

¿Cómo eligió el sistema el procesador con factory?

Selección del procesador de pagos según circunstancias.
Encapsulamiento de la lógica de elección.
Preparado para agregar nuevas pasarelas sin romper código existente.

¿Qué beneficio dio el logging decorado y la cadena de responsabilidades?

Decoración del servicio principal para trazabilidad y auditoría.
Validaciones encadenadas antes de procesar el pago.
Manejo ordenado de errores y flujos alternos.
Visibilidad completa de eventos: validar, cobrar, notificar, confirmar, registrar y retornar.

Resultados y aprendizajes clave

Al ejecutar el sistema refinado, el flujo completo se mantiene: se valida la información, se procesa la transacción, se notifica, se envía confirmación, se hace logging y se retorna el resultado. En Stripe se observa el cargo correcto a la tarjeta por el monto esperado, cumpliendo el primer requisito de negocio.

¿Qué demostró la ejecución end-to-end con Stripe?

Que la refactorización no cambió el resultado funcional.
Que el sistema continúa operando de forma confiable.
Que la observabilidad confirma cada paso del proceso.

¿Por qué mantenible, escalable y flexible importa?

No todo el código que funciona es sostenible en el tiempo.
Un diseño sin SOLID se vuelve frágil con alta transaccionalidad.
El software cambia: prepararlo para crecer reduce deuda técnica.
La arquitectura modular facilita agregar nuevas funcionalidades.

¿Qué habilidades y keywords debes recordar?

Principios SOLID: responsabilidad única, inversión de dependencias.
Patrones: builder, factory, decorador, cadena de responsabilidades.
Arquitectura: módulos de Python y clases con responsabilidades claras.
Dominio: procesador de pagos, Stripe, validación, notificación, confirmación, logging.
Objetivos: mantenible, escalable, flexible, preparado para iterar.

Si te interesa profundizar, comparte tus dudas o experiencias al implementar SOLID y patrones en sistemas de pagos o integraciones con Stripe.

juan esteban colcombet

student•

es posible subir el codigo final en algun lado?

Mario Alexander Vargas Celis

student•

es el GitHub del profesor:

Ulises Alejandro Mánica Caricio

student•

Es curioso porque a primera vista podría ser mucho más tedioso desarrollar con principios y con patrones que sin ellos pero es esta misma robustez lo que te facilitará las cosas a futuro... Te felicito Eduardo ... Gran trabajo en la elaboración del curso... a veces puede volverse difícil de seguir pero con lecturas complementarias y volviendo a ver el vídeo varias veces se tiene una comprensión más profunda de lo mencionado.... Saludos!

edgardo ponce

student•

dejo mi repo, les puede ahorrar un tiempo. Esta dividido por branchs. saludos

Mario Alexander Vargas Celis

student•

Diseñar un **Procesador de Pagos** utilizando **Patrones de Diseño** y aplicando los **Principios SOLID** permite crear un sistema flexible, extensible y fácil de mantener. Este ejemplo integrará los principios SOLID y varios patrones de diseño. ### Escenario Un sistema de procesador de pagos que soporta múltiples métodos de pago (tarjeta de crédito, PayPal, transferencia bancaria) y permite extensiones futuras para agregar nuevos métodos sin modificar el código existente. ## Principios SOLID Aplicados 1. **Principio de Responsabilidad Única (SRP)**: Cada clase tendrá una única responsabilidad, como manejar un método de pago específico.2. **Principio Abierto/Cerrado (OCP)**: Permitimos agregar nuevos métodos de pago sin modificar las clases existentes, gracias al uso de interfaces y el patrón *Factory*.3. **Principio de Sustitución de Liskov (LSP)**: Las clases derivadas de una interfaz o clase base pueden ser utilizadas indistintamente.4. **Principio de Segregación de Interfaces (ISP)**: Las interfaces estarán bien segmentadas, asegurando que cada clase implemente solo lo que necesita.5. **Principio de Inversión de Dependencias (DIP)**: El sistema dependerá de abstracciones y no de implementaciones concretas. ## Arquitectura y Patrones Usados 1. **Patrón Strategy**: Se utilizará para definir los métodos de pago como estrategias intercambiables.2. **Patrón Factory**: Ayuda a crear instancias de métodos de pago según sea necesario.3. **Patrón Decorator**: Para agregar funcionalidad adicional, como registro o validación.4. **Patrón Chain of Responsibility**: Para validar las solicitudes de pago en pasos secuenciales.

## Implementación en Python ### 1. Definición de Interfaces y Clases Base Definimos una interfaz para los métodos de pago.

class MetodoPago(ABC):    @abstractmethod    def procesar\_pago(self, monto):        """Procesa el pago."""        pass```
\### 2. Métodos de Pago Concretos
Creamos implementaciones específicas para cada método de pago.
```pythonclass TarjetaCredito(MetodoPago):    def procesar\_pago(self, monto):        print(f"Procesando pago de ${monto} con tarjeta de crédito.")
class PayPal(MetodoPago):    def procesar\_pago(self, monto):        print(f"Procesando pago de ${monto} con PayPal.")
class TransferenciaBancaria(MetodoPago):    def procesar\_pago(self, monto):        print(f"Procesando pago de ${monto} mediante transferencia bancaria.")```
\### 3. Patrón Factory
Creamos un *\*factory\** para generar instancias de métodos de pago.
```pythonclass MetodoPagoFactory:    @staticmethod    def crear\_metodo\_pago(tipo):        if tipo == "tarjeta":            return TarjetaCredito()        elif tipo == "paypal":            return PayPal()        elif tipo == "transferencia":            return TransferenciaBancaria()        else:            raise ValueError(f"Método de pago no soportado: {tipo}")```
\### 4. Validación con Chain of Responsibility
Definimos una cadena para validar las solicitudes de pago.
```pythonclass Validador(ABC):    def \_\_init\_\_(self):        self.siguiente = None
    def establecer\_siguiente(self, validador):        self.siguiente = validador        return validador
    @abstractmethod    def validar(self, datos):        pass
class ValidadorMonto(Validador):    def validar(self, datos):        if datos.get("monto", 0) <= 0:            return "Error: Monto inválido."        elif self.siguiente:            return self.siguiente.validar(datos)        return "Validación completada."
class ValidadorMetodoPago(Validador):    def validar(self, datos):        if not datos.get("metodo\_pago"):            return "Error: Método de pago no especificado."        elif self.siguiente:            return self.siguiente.validar(datos)        return "Validación completada."```
\### 5. Decorador para Funcionalidades Adicionales
Usamos el patrón *\*Decorator\** para agregar funcionalidades como registro.
```pythonclass LoggerDecorator(MetodoPago):    def \_\_init\_\_(self, metodo\_pago):        self.\_metodo\_pago = metodo\_pago
    def procesar\_pago(self, monto):        print(f"Registrando el pago de ${monto}.")        self.\_metodo\_pago.procesar\_pago(monto)```
\### 6. Flujo Principal
Integramos todo en un flujo de procesamiento.
```python# Configurar validacionesvalidador\_monto = ValidadorMonto()validador\_metodo\_pago = ValidadorMetodoPago()validador\_monto.establecer\_siguiente(validador\_metodo\_pago)
\# Datos de pagodatos\_pago = {"monto": 150, "metodo\_pago": "paypal"}
\# Validar datosresultado\_validacion = validador\_monto.validar(datos\_pago)if resultado\_validacion != "Validación completada.":    print(resultado\_validacion)else:    # Crear el método de pago    metodo\_pago = MetodoPagoFactory.crear\_metodo\_pago(datos\_pago\["metodo\_pago"])
    # Decorar con registro    metodo\_pago = LoggerDecorator(metodo\_pago)
    # Procesar el pago    metodo\_pago.procesar\_pago(datos\_pago\["monto"])```
\### Salida Esperada
```Validación completada.Registrando el pago de $150.Procesando pago de $150 con PayPal.```
\## Beneficios del Diseño
1\. \*\*Extensibilidad\*\*: Se pueden agregar nuevos métodos de pago sin modificar el código existente.2. \*\*Modularidad\*\*: Cada componente tiene una responsabilidad única y bien definida.3. \*\*Flexibilidad\*\*: Los validadores y decoradores se pueden reorganizar o ampliar fácilmente.4. \*\*Mantenibilidad\*\*: El código está organizado de forma lógica, facilitando los cambios futuros.
Este diseño combina lo mejor de los principios SOLID y patrones de diseño para crear un procesador de pagos robusto, escalable y fácil de mantener.

Arquitectura robusta para procesadores de pago

Patrones de Diseño y Principios SOLID

Patrones de diseño y SOLID en Python

Principios SOLID

Principio de responsabilidad única en SOLID

Refactorizando código Python con principios SOLID

Cómo aplicar SRP en un procesador de pagos con Stripe

Open Closed Principle: extensión sin modificación

Cómo usar clases abstractas en Python

Principio de Liskov en S.O.L.I.D.

Principio de sustitución de Liskov en Python

Interface Segregation: cuándo separar contratos

Segregación de interfaces en procesadores de pagos

Principio de inversión de dependencias explicado

Principio de inversión de dependencias: servicio de pagos flexible

Reestructuración del proyecto

Reestructuración con módulos de Python y SOLID

Patrones de Diseño

Qué son los patrones de diseño: definición y categorías

Strategy Pattern con Python y setprocessor

Strategy Pattern para pagos en Python

Factory Pattern: centralizar creación de objetos

Patrón Factory para procesar pagos con match

Patrón Decorator en 5 pasos para funcionalidad dinámica

Patrón decorador en servicios de pagos

Builder Pattern: construcción paso a paso

Builder pattern para servicios de pagos

Observer Pattern en sistemas de eventos

Observer en sistemas de pagos con Python

Chain of Responsibility para validar pagos

Chain of Responsibility en servicios de pagos