Patrones de arquitectura vistos con Python

• Las aplicaciones complejas de Python, a medida que crecen, tienen cada vez más dificultad para soportar pruebas y cambios con enfoques de implementación simples, y este libro aborda esa solución mediante patrones de arquitectura con ejemplos de código
• Toma como ejemplo la venta online de muebles de MADE.com y una cadena de suministro global, poniendo en el centro el modelado de dominio que traslada problemas operativos del mundo real a modelos de software
• Sus ejes principales son TDD, DDD y la arquitectura basada en eventos, con el objetivo de lograr pruebas unitarias rápidas y pocas pruebas E2E, modelos separados de la infraestructura e integración basada en mensajes
• Usa Flask, SQLAlchemy, pytest, Docker y Redis, pero se enfoca en crear una estructura donde la elección de tecnologías concretas quede relegada a detalles de implementación
• Puede leerlo cualquiera que ya haya trabajado con aplicaciones complejas en Python, y no hace falta conocer de antemano DDD ni los patrones clásicos de arquitectura de aplicaciones

---

Una inquietud que nace de una estructura fácil de probar

• Después del libro anterior de Harry, Test-Driven Development with Python, quedó abierta la pregunta de cómo estructurar una aplicación para que sea fácil de probar
• La idea central es crear una estructura que permita cubrir suficientemente la lógica de negocio con pruebas unitarias, minimizando al mismo tiempo la cantidad de pruebas de integración y pruebas E2E
• Se mencionaban conceptos como "Hexagonal Architecture", "Ports and Adapters" y "Functional Core, Imperative Shell", pero en ese momento todavía no los entendía ni aplicaba realmente con suficiente profundidad
• Bob se convirtió en arquitecto porque en su equipo no había nadie encargado de la arquitectura de software, e Ian Cooper le enseñó un nuevo enfoque para escribir código y pensar los problemas

El caso de MADE.com: modelar la cadena de suministro en software

• Los dos autores trabajaron en la empresa europea de ecommerce MADE.com, donde aplicaron las técnicas del libro a la construcción de sistemas distribuidos que modelan problemas reales de negocio
• El dominio de ejemplo está basado en el primer sistema que Bob construyó en MADE, con la intención de ordenar lo que había que enseñar a los nuevos programadores que se incorporaban al equipo
• MADE.com opera una cadena de suministro global compuesta por socios de carga y fabricantes
  • Para reducir costos, busca optimizar los envíos para no acumular inventario demasiado tiempo en los almacenes
  • Idealmente, quieren un flujo donde el sofá llegue al puerto el mismo día en que el cliente lo compra, para enviarlo a su casa sin pasar por almacenamiento
  • Como los productos pueden tardar 3 meses en llegar en barco contenedor, ajustar los tiempos es complicado
• En la operación real aparecen constantemente variables como daños, inundaciones, retrasos por tormentas, errores de procesamiento de socios logísticos, documentos faltantes o cambios en los pedidos de los clientes
• Para manejar estos problemas, buscan representar las operaciones del mundo real en software y automatizar la mayor cantidad posible de trabajo

Los límites que aparecen cuando un proyecto en Python crece

• Python ha crecido y madurado rápidamente, pero ahora recién empieza a asumir en serio el tipo de problemas que los ecosistemas de C# y Java vienen enfrentando desde hace mucho tiempo
• Las startups se convierten en negocios reales, y las aplicaciones web y la automatización con scripts crecen hasta transformarse en software empresarial
• Aunque la filosofía de Python dice “There should be one—and preferably only one—obvious way to do it”, cuando un proyecto crece, la forma más obvia no siempre es adecuada para gestionar la complejidad y los cambios en los requisitos
• Las técnicas y patrones del libro no son nuevos, pero en gran parte siguen siendo relativamente recientes dentro del mundo Python
• No es un libro que busque reemplazar Domain-Driven Design de Eric Evans ni Patterns of Enterprise Application Architecture de Martin Fowler; al contrario, los referencia con frecuencia y recomienda leer esos clásicos
• Como muchos ejemplos de código de la literatura existente están escritos en Java o C++/#, para los desarrolladores Python pueden resultar más pesados de leer

Tres herramientas para gestionar la complejidad

• El desarrollo guiado por pruebas (TDD) ayuda a crear código correcto y a refactorizar o agregar funcionalidad sin miedo a las regresiones
  • Se aborda cómo ejecutar pruebas lo más rápido posible
  • Cómo obtener la mayor cobertura y retroalimentación posibles con pruebas unitarias rápidas y sin dependencias
  • Y cómo minimizar las pruebas E2E lentas e inestables
• El diseño guiado por el dominio (DDD) ayuda a concentrarse en construir un buen modelo del dominio de negocio
  • Se explica cómo evitar que el modelo quede atado a preocupaciones de infraestructura
  • Y cómo impedir que se convierta en un modelo difícil de cambiar
• Los microservicios débilmente acoplados integrados mediante mensajes, a veces llamados reactive microservices, se presentan como una forma de manejar la complejidad entre múltiples aplicaciones o dominios de negocio
  • No siempre está claro cómo encajarlos con herramientas ya existentes del ecosistema Python como Flask, Django o Celery
• Incluso si no usas microservicios o no te interesan, la mayoría de los patrones del libro y buena parte del contenido sobre arquitectura basada en eventos también se pueden aplicar a una arquitectura monolítica

Lectores objetivo y conocimientos previos

• Este libro asume lectores que ya han trabajado de cerca con aplicaciones de Python de cierta complejidad
• Está pensado para quienes ya experimentaron el dolor que trae gestionar la complejidad
• No hace falta tener conocimientos previos de DDD ni de patrones clásicos de arquitectura de aplicaciones
• La explicación se construye capítulo por capítulo alrededor de una aplicación de ejemplo
• Como los autores usan TDD en su trabajo, con frecuencia muestran primero el código de prueba y después la implementación
• Usan Flask, SQLAlchemy, pytest, Docker y Redis, pero conocerlos de antemano ayuda sin ser un requisito
• Uno de los objetivos principales es crear una arquitectura donde la elección de tecnologías específicas se convierta en un detalle de implementación menor

Estructura del libro

• El libro está dividido en dos partes

• Parte 1: Arquitectura que respalda el modelado de dominio

  • El modelado de dominio y DDD se tratan en los capítulos 1, 2 y 7
  • Parte de la premisa de que los problemas de negocio complejos deben reflejarse en un modelo de dominio dentro del código
  • Explica cómo empezar con un modelo sin dependencias externas y fácil de probar con pruebas unitarias rápidas
  • Más adelante vuelve sobre la elección adecuada de aggregates y los problemas de integridad de datos
  • Los patrones Repository, Service Layer y Unit of Work se tratan en los capítulos 2, 4 y 5
  • Estos patrones se complementan entre sí para separar el modelo de dependencias innecesarias
  • Se crea una capa de abstracción alrededor del almacenamiento persistente y una capa de servicios que captura los puntos de entrada del sistema y los casos de uso principales
  • Muestra una estructura que facilita crear puntos de entrada delgados, como una API en Flask o una CLI
  • La discusión sobre abstracción y pruebas continúa en los capítulos 3 y 5
  • Después de introducir el patrón Repository, se aborda cómo elegir abstracciones y qué papel juegan en las formas de acoplamiento
  • Tras el patrón Service Layer, se trata la pirámide de pruebas y cómo escribir pruebas unitarias en el mayor nivel de abstracción posible

• Parte 2: Arquitectura basada en eventos

  • La arquitectura basada en eventos se trata en los capítulos 8 al 11
  • Introduce los patrones Domain Events, Message Bus y Handler
  • Los Domain Events sirven para representar la idea de que una interacción en el sistema dispara otra acción
  • El Message Bus permite que una acción dispare eventos y llame al handler adecuado
  • Se aborda cómo usar eventos como patrón de integración entre servicios dentro de una arquitectura de microservicios
  • Distingue entre commands y events, y la aplicación se convierte esencialmente en un sistema de procesamiento de mensajes
  • En el capítulo 12 se trata un ejemplo de CQRS tanto con un enfoque que usa eventos como con otro que no los usa
  • En el capítulo 13 se ordenan las dependencias explícitas e implícitas y se implementa un marco simple de inyección de dependencias
  • En el epílogo se explica cómo aplicar estos principios a software existente, en lugar de partir de un ejemplo simple desde cero, y se ofrecen lecturas adicionales

Código de ejemplo y cómo seguirlo

• El libro está construido alrededor de un solo proyecto de ejemplo, que se amplía paso a paso a medida que avanzan los capítulos
• Se da mucha importancia a que el lector toque realmente el código y adquiera intuición sobre cómo funcionan los patrones
• Todo el código está en GitHub y cada capítulo tiene su propia rama
  • La lista de ramas puede verse en la página de branches de GitHub
• Se proponen tres formas de seguirlo
  • Crear tu propio repositorio y construir la app siguiendo los ejemplos del libro, consultando el repositorio de los autores cuando haga falta
  • Probar cada patrón capítulo por capítulo en tu propio proyecto pequeño
  • Practicar rápidamente con los "Exercise for the Reader" de cada capítulo y el código de GitHub que viene parcialmente incompleto
• Especialmente para quienes quieren aplicar los patrones a sus propios proyectos, empezar con ejemplos simples es una forma de practicar con seguridad
• Como mínimo, se recomienda que al leer cada capítulo uses git checkout en el repositorio para revisar el código dentro del contexto de una aplicación real funcionando

Licencia y formato

• El código y la versión online están bajo licencia Creative Commons CC BY-NC-ND
  • Para fines no comerciales
  • Con atribución
  • Se permite copiar y compartir
• La edición impresa se rige por una licencia distinta, y si hay dudas sobre reutilización se indica consultar con O’Reilly
• Las convenciones tipográficas del libro distinguen entre cursiva, ancho fijo, ancho fijo en negrita y ancho fijo en cursiva
  • La cursiva indica términos nuevos, URL, direcciones de correo electrónico, nombres de archivo y extensiones
  • El ancho fijo representa listados de programas y elementos de código
  • El ancho fijo en negrita representa comandos o texto que el usuario debe escribir tal cual
  • El ancho fijo en cursiva representa texto que debe reemplazarse por valores proporcionados por el usuario o definidos por el contexto

[xguru]

Ya existe una edición en coreano: Patrones de arquitectura vistos con Python