Reestructuración con módulos de Python y SOLID

Curso de Patrones de Diseño y SOLID en Python

Contenido del curso

Patrones de Diseño y Principios SOLID

1
Patrones de diseño y SOLID en Python
02:07 min

Principios SOLID

Reestructuración del proyecto

13
Reestructuración con módulos de Python y SOLID
Viendo ahora

Patrones de Diseño

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:0013:32

Reestructuración con módulos de Python y SOLID

Curso de Patrones de Diseño y SOLID en Python

Clase 13 de 27

Clase 13 / 27

Recursos

Aplicar SOLID con módulos de Python permite pasar de un archivo monolítico a un diseño limpio, escalable y mantenible. Aquí verás cómo identificar contextos, separar responsabilidades y usar protocolos para desacoplar el alto nivel del bajo nivel en un Payment Service sin cambiar su lógica principal.

¿Cómo reestructurar un payment service con módulos de Python?

La técnica central es identificar contextos y responsabilidades de las clases de bajo nivel, y convertir cada contexto en un módulo. El Payment Service opera como clase de alto nivel, mientras validadores, logger, notificador y procesadores son bajo nivel y viven en módulos separados.

Parte de SOLID: inversión de dependencias y responsabilidad única.
Define contextos: validaciones, logging, notificaciones, procesadores de pago.
Crea carpetas-módulo con archivos por clase y un init.py como puerta de acceso.
Importa en el servicio solo protocolos de lo que varía (procesadores, notificador) y clases concretas de lo estable (validadores, logger).
Beneficios: mantenibilidad, escalabilidad y cambio seguro por archivo y contexto.

¿Qué contextos definen los módulos y clases?

Esta organización agrupa clases afines y estandariza sus puntos de entrada con init.py para facilitar importaciones, incluso con import all cuando haga sentido.

Commons.
- ContactInfo: datos de contacto del customer.
- CustomerData: datos del cliente.
- PaymentData: incluye Currency agregado para soportar nuevos procesadores.
- PaymentsResponse: respuesta del pago.
- init.py: reexporta clases para importación centralizada.
Notifiers.
- NotifierProtocol: protocolo con método send confirmation.
- Email y SMS: implementaciones del protocolo.
- Nota práctica: en Python no es obligatorio que la clase herede explícitamente del protocolo si cumple su interfaz; el editor puede advertir inconsistencias.
Loggers.
- Transaction Logger: clase de logging de transacciones sin protocolo.
Validators.
- Customer Validator y Payment Data Validator: validaciones sin protocolo, misma lógica previa.
Processors.
- Protocolos: payment, recurring y reembolsos.
- Implementaciones: Stripe (lógica principal de cobro, reembolso y recurrencia), offline processor (ejemplo para efectivo) y procesador local (ejemplo para futuras referencias).

¿Por qué usar protocolos en Python?

Permiten programar contra abstracciones sin acoplarse a implementaciones.
Cambias de Stripe a otro procesador sin tocar el Payment Service.
El editor ayuda a verificar que la clase cumple el contrato del protocolo.

¿Qué aporta init.py al módulo?

Unifica puntos de entrada de cada contexto.
Facilita importaciones claras desde la carpeta del módulo.
Permite definir listas públicas para import all cuando se requiera.

¿Cómo escalar con nuevos procesadores?

Agrega una clase nueva en Processors que implemente los tres protocolos o los que necesites.
Extiende datos en Commons (como Currency en PaymentData) cuando haga falta.
No toques el Payment Service: ya depende de protocolos.

¿Cómo se instancia e importa el servicio de alto nivel?

El archivo Service.py mantiene el mismo código del principio de inversión de dependencias; cambian solo las rutas de importación. La recomendación es crear main.py para instanciar el servicio y orquestar dependencias.

Importa el servicio de alto nivel desde service.
Importa de processors y notifiers solo los protocolos en el servicio; en main.py sí eliges implementaciones concretas.
Importa validadores y logger como clases concretas.
Instancia el Payment Service con las dependencias concretas y cámbialas cuando necesites.

# main.py
from service import PaymentService
from processors import Stripe  # implementación elegida
from notifiers import Email    # implementación elegida
from loggers import TransactionLogger
from validators import CustomerValidator, PaymentDataValidator

if __name__ == "__main__":
    payment_processor = Stripe()
    email_notifier = Email()
    customer_validator = CustomerValidator()
    payment_data_validator = PaymentDataValidator()
    logger = TransactionLogger()

    service = PaymentService(
        payment_processor=payment_processor,
        notifier=email_notifier,
        customer_validator=customer_validator,
        payment_data_validator=payment_data_validator,
        logger=logger,
    )

¿Te gustaría comentar cómo organizarías tus módulos o qué protocolo agregarías primero? Comparte tu enfoque y mejoras posibles para el Payment Service.

Mario Alexander Vargas Celis

Hace 2 años

Reestructurar un proyecto en Python implica organizar su estructura de archivos y carpetas para que sea modular, mantenible y escalable, especialmente en proyectos complejos. Una estructura bien organizada facilita el desarrollo, las pruebas, la colaboración en equipo y la integración de herramientas de CI/CD.

Aquí tienes una guía para estructurar un proyecto en Python, especialmente útil para aplicaciones de tamaño medio a grande.

---

### Estructura Común para un Proyecto en Python

Imaginemos que tienes un proyecto llamado my\_project. La estructura típica podría verse así:


my\_project/

│

├── my\_project/              # Paquete principal de la aplicación

│   ├── \_\_init\_\_.py          # Marca este directorio como un paquete Python

│   ├── main.py              # Archivo principal para ejecutar la aplicación

│   ├── config.py            # Configuración de la aplicación

│   ├── controllers/         # Lógica de controladores o lógica de negocio

│   │   ├── \_\_init\_\_.py

│   │   └── user\_controller.py

│   ├── models/              # Modelos y clases de datos

│   │   ├── \_\_init\_\_.py

│   │   └── user.py

│   ├── services/            # Servicios o lógica de negocio

│   │   ├── \_\_init\_\_.py

│   │   └── user\_service.py

│   ├── repositories/        # Capa de acceso a datos

│   │   ├── \_\_init\_\_.py

│   │   └── user\_repository.py

│   ├── utils/               # Utilidades y funciones auxiliares

│   │   ├── \_\_init\_\_.py

│   │   └── helpers.py

│   └── schemas/             # Definición de esquemas o validaciones

│       ├── \_\_init\_\_.py

│       └── user\_schema.py

│

├── tests/                   # Pruebas unitarias y funcionales

│   ├── \_\_init\_\_.py

│   ├── test\_main.py         # Pruebas de integración para main.py

│   ├── controllers/         # Pruebas de controladores

│   ├── models/              # Pruebas de modelos

│   ├── services/            # Pruebas de servicios

│   └── repositories/        # Pruebas de acceso a datos

│

├── scripts/                 # Scripts de gestión (deploy, migraciones)

│   └── run\_migration.py

│

├── .env                     # Variables de entorno (NO subir a control de versiones)

├── requirements.txt         # Dependencias del proyecto

├── README.md                # Documentación general del proyecto

├── .gitignore               # Archivos y carpetas ignoradas por git

└── setup.py                 # Script de instalación para pip

### Explicación de Cada Directorio y Archivo

- **my_project/**: Este es el paquete principal de tu aplicación, que incluye la mayor parte de la lógica y componentes del proyecto.

- **\_\_init\_\_.py**: Marca el directorio como un paquete. Si usas namespaces, puedes añadir configuraciones básicas.

- **main.py**: Punto de entrada de la aplicación. En una aplicación web, aquí podría residir el servidor principal, mientras que en una CLI se definiría el comando principal.

- **config.py**: Define configuraciones globales (puedes cargar variables de .env o definir configuraciones específicas para cada entorno).

- **controladores (controllers/)**: Aquí reside la lógica de los controladores, que gestionan la lógica de flujo de la aplicación. Para una API, por ejemplo, este directorio puede incluir controladores para diferentes endpoints.

- **modelos (models/)**: Define la estructura de datos (o modelos ORM, si usas una base de datos). Cada modelo representa una entidad o clase de datos.

- **servicios (services/)**: Contiene la lógica de negocio. Aquí colocas las operaciones específicas y servicios que actúan sobre los datos y no necesariamente dependen del flujo del usuario.

- **repositorios (repositories/)**: Capa de acceso a datos que interactúa con la base de datos o con APIs externas. Permite la separación del almacenamiento de datos y la lógica de negocio.

- **utilidades (utils/)**: Funciones auxiliares que pueden ser usadas en distintas partes del proyecto (validaciones, formateo de datos, etc.).

- **esquemas (schemas/)**: Definiciones de esquemas o validaciones de datos (por ejemplo, usando librerías como pydantic o marshmallow). Sirve para definir y validar los datos que entran o salen del sistema.

- **tests/**: Directorio para pruebas unitarias, funcionales e integradas. Organizado de forma similar al proyecto principal para encontrar y estructurar mejor las pruebas de cada módulo.

- **scripts/**: Contiene scripts auxiliares, como scripts de migraciones, herramientas de despliegue, o utilidades de mantenimiento del sistema.

- **.env**: Archivo para variables de entorno, como claves API o configuraciones específicas del entorno, que no deben subirse al repositorio.

- **requirements.txt**: Lista de dependencias del proyecto, necesaria para instalar las librerías con pip.

- **README.md**: Documentación general del proyecto. Aquí puedes describir el propósito del proyecto, instrucciones de instalación y guías de uso.

- **.gitignore**: Archivo de configuración para ignorar archivos específicos en el control de versiones (por ejemplo, .env, archivos de caché, etc.).

- **setup.py**: Script de configuración para la instalación del paquete si estás planeando distribuir el proyecto como una biblioteca o una herramienta instalable.

### Consejos Adicionales

1. **Usa herramientas de linting y formateo**: Utiliza flake8 o pylint para asegurar la calidad del código, y black o autopep8 para mantener el formato del código.

2. **Pruebas automatizadas**: Configura tus pruebas con pytest o unittest para que corran automáticamente en un servidor de CI/CD (por ejemplo, usando GitHub Actions o GitLab CI).

3. **Documentación**: Es recomendable documentar tanto el código como el README.md, e incluso usar docstrings y herramientas como Sphinx si el proyecto es grande.

4. **Configuración flexible**: En config.py, carga variables de entorno usando una librería como dotenv para facilitar el cambio de entornos (producción, desarrollo, etc.).

### Ejemplo de Código para config.py


import os

from dotenv import load\_dotenv



\# Cargar variables de entorno del archivo .env

load\_dotenv()



class Config:

&#x20;   DEBUG = os.getenv("DEBUG", "False") == "True"

&#x20;   DATABASE\_URL = os.getenv("DATABASE\_URL")

&#x20;   SECRET\_KEY = os.getenv("SECRET\_KEY", "default\_secret\_key")

### Ejemplo de main.py con Configuración de Entrada


from my\_project.config import Config

from my\_project.controllers.user\_controller import UserController



def main():

&#x20;   print("Starting application...")

&#x20;   user\_controller = UserController()

&#x20;   user\_controller.run()



if \_\_name\_\_ == "\_\_main\_\_":

&#x20;   main()

### Beneficios de una Buena Estructura de Proyecto

- **Mantenibilidad**: La separación de responsabilidades hace que el código sea más fácil de modificar y mantener.

- **Escalabilidad**: Una estructura bien organizada permite agregar nuevas funcionalidades de manera ordenada.

- **Colaboración**: Facilita el trabajo en equipo, ya que cada miembro puede trabajar en un módulo sin interferir en otros.

- **Pruebas**: Las pruebas se integran de forma natural en la estructura, permitiendo que cada módulo tenga sus pruebas específicas.

Organizar y estructurar bien un proyecto en Python es esencial para el éxito a largo plazo. Mantener estas buenas prácticas hará que el desarrollo sea más eficiente y sostenible.

Patrones de Diseño y Principios SOLID

Patrones de diseño y SOLID en Python

Principios SOLID

Qué es el principio de responsabilidad única

Procesador de pagos en Python con Stripe

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

Principio open-closed en Python

Clases abstractas y principio abierto-cerrado

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

Principio de sustitución de Liskov en Python

Principio de segregación de interfaces en SOLID

Segregación de interfaces en procesadores de pagos

Principio de inversión de dependencias en SOLID

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

Qué es el patrón Decorator

Patrón decorador en servicios de pagos

Builder Pattern: construcción paso a paso

Builder Pattern aplicado a un servicio 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

Código funcional vs código mantenible en Python

Reestructuración con módulos de Python y SOLID

Progreso del curso

Patrones de Diseño y Principios SOLID

Principios SOLID

Reestructuración del proyecto

Patrones de Diseño

Recursos

Recursos