book

Patrones de Arquitectura con Python

by Harry Percival, Bob Gregory

September 2024

Intermediate to advanced

304 pages

7h 50m

Spanish

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

Gestionar la complejidad, resolver problemas empresariales¿Por qué Python?TDD, DDD y Arquitectura Dirigida por EventosQuién debería leer este libroBreve resumen de lo que aprenderásParte I, Construir una arquitectura para apoyar el modelado de dominiosParte II, Arquitectura dirigida por eventosContenido adicionalEjemplo de código y codificaciónLicenciaConvenciones utilizadas en este libroAprendizaje en línea O'ReillyCómo contactar con O'ReillyAgradecimientos
¿Por qué fallan nuestros diseños?Encapsulación y abstraccionesCapasEl principio de inversión de la dependenciaUn lugar para toda nuestra lógica empresarial: El Modelo de Dominio
¿Qué es un modelo de dominio?Explorar el lenguaje del dominioPruebas unitarias de modelos de dominioLas clases de datos son geniales para los objetos de valorObjetos y entidades de valorNo todo tiene que ser un objeto: Una Función de Servicio de DominioLos métodos mágicos de Python nos permiten utilizar nuestros modelos con Python idiomáticoLas excepciones también pueden expresar conceptos de dominio
Persistencia de nuestro modelo de dominioUn poco de pseudocódigo: ¿Qué vamos a necesitar?Aplicación del DIP al Acceso a los DatosRecordatorio: Nuestro modeloLa manera "normal" de ORM: El modelo depende del ORMInvertir la dependencia: El ORM depende del modeloPresentación del modelo de repositorioEl Repositorio en el Resumen¿Cuál es la contrapartida?Construir un falso repositorio para pruebas ¡ahora es trivial!¿Qué es un puerto y qué es un adaptador, en Python?Recapitulación
Abstraer el estado ayuda a la comprobabilidadElegir la(s) abstracción(es) adecuada(s)Implementación de las abstracciones elegidasPruebas de perímetro a perímetro con falsificaciones e inyección de dependencia¿Por qué no poner un parche?Recapitulación
Conectar nuestra aplicación con el mundo realUna primera prueba de principio a finLa aplicación directaCondiciones de error que requieren comprobaciones de la base de datosIntroducir una capa de servicio y utilizar FakeRepository para probarla unitariamenteUna función de servicio típica¿Por qué todo se llama servicio?Poner las cosas en carpetas para ver dónde está cada cosaRecapitulaciónEl DIP en acción
¿Cómo va nuestra pirámide de pruebas?¿Deberían trasladarse las pruebas de la capa de dominio a la capa de servicio?Sobre la decisión de qué tipo de pruebas escribirMarcha alta y bajaDesacoplar completamente las pruebas de la capa de servicio del dominioMitigación: Mantener todas las Dependencias de Dominio en Funciones FijasAñadir un servicio que faltaLlevar la mejora a las pruebas E2ERecapitulación
La Unidad de Trabajo colabora con el RepositorioProbar un UoW con pruebas de integraciónUnidad de Trabajo y su Contexto GestorLa Unidad de Trabajo Real Utiliza Sesiones SQLAlchemyUnidad de trabajo falsa para pruebasUtilizar el UoW en la Capa de ServicioPruebas explícitas del comportamiento de confirmación/retrocesoCompromisos explícitos frente a implícitosEjemplos: Utilizar UoW para Agrupar Varias Operaciones en una Unidad AtómicaEjemplo 1: ReasignarEjemplo 2: Modificar la cantidad del loteOrdenar las pruebas de integraciónRecapitulación
¿Por qué no ejecutarlo todo en una hoja de cálculo?Invariantes, restricciones y coherenciaInvariantes, concurrencia y bloqueos¿Qué es un agregado?Elegir un áridoUn Agregado = Un Repositorio¿Y el rendimiento?Concurrencia optimista con números de versiónOpciones de aplicación de los números de versiónPruebas para nuestras reglas de integridad de datosAplicación de reglas de concurrencia mediante niveles de aislamiento de transacciones de bases de datosEjemplo pesimista de control de la concurrencia: SELECCIONAR PARA ACTUALIZARRecapitulaciónResumen de la Parte I

Evitar hacer un desastreEn primer lugar, evitemos hacer un desastre con nuestros controladores webY tampoco hagamos un desastre de nuestro modelo¡O la Capa de Servicio!Principio de Responsabilidad Única¡Todos a bordo del autobús de los mensajes!El Modelo Registra EventosLos eventos son simples clases de datosEl Modelo Plantea EventosEl Bus de Mensajes Asigna Eventos a ManejadoresOpción 1: La capa de servicio toma los eventos del modelo y los coloca en el bus de mensajesOpción 2: La capa de servicio genera sus propios eventosOpción 3: La UoW Publica Eventos en el Bus de MensajesRecapitulación
Un nuevo requisito nos lleva a una nueva arquitecturaImaginando un Cambio de Arquitectura: Todo Será un Manejador de EventosRefactorización de Funciones de Servicio a Manejadores de MensajesEl Bus de Mensajes ahora recoge eventos de la UoWNuestros tests también se escriben en términos de acontecimientosUn feo hack temporal: el autobús de mensajes tiene que devolver resultadosModificar nuestra API para trabajar con eventosPoner en práctica nuestro nuevo requisitoNuestro nuevo eventoProbar un nuevo manipuladorAplicaciónUn nuevo método sobre el modelo de dominioOpcionalmente: Prueba unitaria de controladores de eventos aislados con un falso bus de mensajesRecapitulación¿Qué hemos conseguido?¿Por qué lo hemos conseguido?
Comandos y EventosDiferencias en el manejo de excepcionesDiscusión: Eventos, comandos y gestión de erroresRecuperación de errores de forma sincrónicaRecapitulación
Bola de barro distribuida, y Pensar en sustantivosTratamiento de errores en sistemas distribuidosLa alternativa: Desacoplamiento temporal mediante mensajería asíncronaUtilizar un canal Redis Pub/Sub para la integraciónPruébalo todo con una prueba de extremo a extremoRedis es otro adaptador delgado alrededor de nuestro bus de mensajesNuestro nuevo evento salienteAcontecimientos internos frente a acontecimientos externosRecapitulación
Los modelos de dominio son para escribirLa mayoría de los usuarios no van a comprar tus mueblesPublicar/Redirigir/Obtener y CQSAgarraos el almuerzo, amigosProbar las vistas CQRSAlternativa "obvia" 1: Utilizar el repositorio existenteTu modelo de dominio no está optimizado para las operaciones de lecturaAlternativa "obvia" 2: Utilizar el ORMSELECT N+1 y otras consideraciones sobre el rendimientoEs hora de saltar completamente el tiburónActualizar una Tabla Modelo de Lectura Utilizando un Manejador de SucesosCambiar la implementación de nuestro modelo de lectura es fácilRecapitulación
Dependencias implícitas frente a explícitas¿Las dependencias explícitas no son totalmente raras y propias de Java?Preparación de los Manipuladores: Manual DI con Cierres y ParcialesUna alternativa utilizando clasesUn script BootstrapEl bus de mensajes recibe manejadores en tiempo de ejecuciónUtilizar Bootstrap en nuestros puntos de entradaInicializar DI en nuestras pruebasConstruir un adaptador "correctamente": Un ejemplo prácticoDefine las Implementaciones Abstracta y ConcretaHaz una versión falsa para tus pruebasAverigua cómo probar la integración realRecapitulación
¿Y ahora qué?¿Cómo llego desde aquí?Separar las responsabilidades enredadasIdentificar agregados y contextos limitadosUn Enfoque Dirigido por Eventos para Pasar a Microservicios mediante el Patrón StranglerConvencer a tus partes interesadas para que prueben algo nuevoPreguntas de nuestros revisores técnicos que no pudimos convertir en prosaFootgunsMás lecturas obligatoriasRecapitulación
Env Vars, 12-Factor, y Config, Contenedores Internos y ExternosConfig.pyConfiguración de Docker-Compose y ContenedoresInstalar tu fuente como paqueteDockerfilePruebasRecapitulación
Implementar un repositorio y una unidad de trabajo para los CSV
Patrón de repositorio con DjangoMétodos personalizados en clases ORM de Django para traducir a/desde nuestro modelo de dominioPatrón de Unidad de Trabajo con DjangoAPI: Las Vistas de Django son Adaptadores¿Por qué fue todo esto tan difícil?Qué hacer si ya tienes DjangoPasos en el camino
¿Qué es la validación?Validar la sintaxisLa ley de Postel y el patrón del lector toleranteValidación en el perímetroValidar la semánticaValidar la pragmática

Content preview from Patrones de Arquitectura con Python

Parte II. Arquitectura dirigida por eventos

Siento haber acuñado hace tiempo el término "objetos" para este tema, porque consigue que mucha gente se centre en la idea menor.

La gran idea es "mensajería"... La clave para hacer sistemas grandes y crecibles es mucho más diseñar cómo se comunican sus módulos que cuáles deben ser sus propiedades y comportamientos internos.

Alan Kay

Está muy bien poder escribir un modelo de dominio para gestionar un único trozo de proceso empresarial, pero ¿qué ocurre cuando necesitamos escribir muchos modelos? En el mundo real, nuestras aplicaciones se sitúan dentro de una organización y necesitan intercambiar información con otras partes del sistema. Quizá recuerdes nuestro diagrama de contexto mostrado en la Figura II-1.

Ante esta exigencia, muchos equipos optan por microservicios integrados mediante API HTTP. Pero si no tienen cuidado, acabarán produciendo el lío más caótico de todos: la gran bola de barro distribuida.

En la Parte II, mostraremos cómo las técnicas de la Parte I pueden extenderse a los sistemas distribuidos. Nos alejaremos para ver cómo podemos componer un sistema a partir de muchos componentes pequeños que interactúan mediante el paso asíncrono de mensajes.

Veremos cómo los patrones Capa de Servicio y Unidad de Trabajo nos permiten reconfigurar nuestra aplicación para que funcione como un procesador de mensajes asíncrono, y cómo los sistemas basados en eventos nos ayudan a desacoplar los agregados y las aplicaciones entre sí. ...