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

Capítulo 3. Un breve interludio: Sobre acoplamiento y abstracciones

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com

Permítenos una breve digresión sobre el tema de las abstracciones, querido lector. Hemos hablado bastante de abstracciones. El patrón Repositorio es una abstracción sobre el almacenamiento permanente, por ejemplo. Pero, ¿en qué consiste una buena abstracción? ¿Qué queremos de las abstracciones? ¿Y cómo se relacionan con las pruebas?

Consejo

El código de este capítulo está en la rama chapter_03_abstractions de GitHub:

git clone https://github.com/cosmicpython/code.git
git checkout chapter_03_abstractions

Un tema clave de este libro, oculto entre los patrones extravagantes, es que podemos utilizar abstracciones sencillas para ocultar detalles desordenados. Cuando escribimos código por diversión, o en una kata,¹ podemos jugar con las ideas libremente, martilleando las cosas y refactorizando agresivamente. Sin embargo, en un sistema a gran escala, nos vemos limitados por las decisiones tomadas en otras partes del sistema.

Cuando no podemos cambiar el componente A por miedo a romper el componente B, decimos que los componentes se han acoplado. Localmente, el acoplamiento es algo bueno: es señal de que nuestro código funciona conjuntamente, cada componente apoya a los demás, todos encajan en su sitio como los engranajes de un reloj. En la jerga, decimos que esto funciona cuando hay una gran cohesión ...