book

Arquitectura de software: Las partes difíciles

by Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani

September 2024

Intermediate to advanced

462 pages

14h 2m

Spanish

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

Convenciones utilizadas en este libroUtilizar ejemplos de códigoAprendizaje en línea O'ReillyCómo contactar con nosotrosAgradecimientosAgradecimientos de Mark RichardsAgradecimientos de Neal FordAgradecimientos de Pramod SadalageAgradecimientos de Zhamak Dehghani
¿Por qué "Las partes difíciles"?Dar consejos atemporales sobre arquitectura de softwareLa importancia de los datos en la arquitecturaRegistros de decisiones arquitectónicasFunciones de adecuación de la arquitecturaUtilizar funciones de aptitudArquitectura frente a Diseño: Simplificar las definicionesPresentación de la Saga Sysops SquadFlujo de trabajo sin emisión de billetesFlujo de trabajo de la gestión de incidenciasUn mal escenarioComponentes arquitectónicos del Escuadrón SysopsModelo de datos del Escuadrón Sysops
Arquitectura (Quantum | Quanta)Implementación independienteAlta cohesión funcionalAcoplamiento estático elevadoAcoplamiento Cuántico DinámicoSaga Sysops Squad: Comprender Quanta
Impulsores de la modularidadMantenibilidadComprobabilidadImplementabilidadEscalabilidadDisponibilidad/Tolerancia a fallosSaga Sysops Squad: Crear un caso empresarial
¿Es descomponible el código base?Acoplamiento aferente y eferenteAbstracción e inestabilidadDistancia de la secuencia principalDescomposición por componentesBifurcación tácticaContrapartidasSaga Sysops Squad: Elegir un enfoque de descomposición
Identificar y dimensionar los componentes PatrónDescripción del patrónFunciones de aptitud para la gobernanzaSaga Sysops Squad: Dimensionar los componentesReunir componentes de dominio común PatrónDescripción del patrónFunciones de aptitud para la gobernanzaSaga Sysops Squad: Reunir componentes comunesAplanar Componentes PatrónDescripción del patrónFunciones de aptitud para la gobernanzaSaga Escuadrón de Sysops: Aplanar componentesDeterminar el patrón de dependencia de los componentesDescripción del patrónFunciones de aptitud para la gobernanzaSysops Squad Saga: Identificar las dependencias de los componentesCrear patrón de dominios de componentesDescripción del patrónFunciones de aptitud para la gobernanzaSaga Sysops Squad: Crear dominios de componentesCrear patrón de servicios de dominioDescripción del patrónFunciones de aptitud para la gobernanzaSaga Sysops Squad: Crear servicios de dominioResumen
Descomponedores de datosDesintegradores de datosIntegradores de datosSaga Sysops Squad: Justificar la descomposición de la base de datosDescomponer datos monolíticosPaso 1: Analizar la base de datos y crear dominios de datosPaso 2: Asignar Tablas a Dominios de DatosPaso 3: Separar las Conexiones de Base de Datos a los Dominios de DatosPaso 4: Trasladar los esquemas a servidores de bases de datos separadosPaso 5: Cambiar a servidores de bases de datos independientesSeleccionar un tipo de base de datosBases de datos relacionalesBases de datos clave-valorBases de datos de documentosBases de datos familiares de columnasBases de datos gráficasBases de datos NewSQLBases de datos nativas de la nubeBases de datos de series temporalesSaga Sysops Squad: Bases de datos políglotas
Desintegradores de granularidadAlcance y función del servicioCódigo VolatilidadEscalabilidad y rendimientoTolerancia a fallosSeguridadExtensibilidadIntegradores de granularidadTransacciones de la base de datosFlujo de trabajo y coreografíaCódigo compartidoRelaciones de datosEncontrar el equilibrio adecuadoSysops Squad Saga: Granularidad de la asignación de ticketsSysops Squad Saga: Granularidad del registro de clientes

Replicación de códigoCuándo utilizarBiblioteca compartidaGestión de la dependencia y control de cambiosEstrategias de control de versionesCuándo utilizarloServicio compartidoRiesgo de cambioRendimientoEscalabilidadTolerancia a fallosCuándo utilizarSidecars y malla de servicioCuándo utilizarSaga Sysops Squad: Lógica de la infraestructura comúnReutilización del código: ¿Cuándo añade valor?Reutilización a través de plataformasSaga Sysops Squad: Funcionalidad de dominio compartido
Asignar la propiedad de los datosHipótesis de propiedad únicaEscenario de propiedad comúnEscenario de copropiedadTabla Técnica de divisiónTécnica de dominio de datosTécnica DelegadaTécnica de consolidación de serviciosResumen de la propiedad de los datosTransacciones distribuidasPatrones de Consistencia EventualPatrón de sincronización de fondoPatrón orquestado basado en peticionesPatrón basado en sucesosSaga Sysops Squad: Propiedad de los datos para el procesamiento de entradas
Patrón de comunicación entre serviciosPatrón de replicación del esquema de columnasPatrón de Caché ReplicadoPatrón de dominio de datosSysops Squad Saga: Acceso a datos para la asignación de entradas
Orquestación Estilo de comunicaciónCoreografía Estilo de comunicaciónGestión del estado del flujo de trabajoCompromisos entre orquestación y coreografíaEstado Propietario y AcoplamientoSysops Squad Saga: Gestión de flujos de trabajo
Patrones de Saga TransaccionalPatrón de la Saga Épica(sao)Patrón Phone Tag Saga(sac)Saga de cuentos de hadas(seo) PatrónSaga de viajes en el tiempo(sec) PatrónFantasía Ficción Saga(aao) PatrónPatrón de Historias de terror(aac)Patrón Paralelo Saga(aeo)Patrón Anthology Saga(aec)Gestión del Estado y Coherencia EventualMáquinas de Estado SagaTécnicas para gestionar sagasSaga Sysops Squad: Transacciones atómicas y actualizaciones compensatorias
Contratos estrictos frente a contratos laxosCompromisos entre contratos estrictos y laxosContratos en microserviciosAcoplamiento del selloSobreacoplamiento mediante acoplamiento de sellosAncho de bandaAcoplamiento de sellos para la gestión del flujo de trabajoSysops Squad Saga: Gestión de contratos de venta de entradas
Enfoques anterioresEl almacén de datosEl Lago de DatosLa malla de datosDefinición de malla de datosDatos Producto QuantumMalla de datos, acoplamiento y arquitectura QuantumCuándo utilizar la malla de datosSaga Sysops Squad: Malla de datos
Encontrar dimensiones entrelazadasAcoplamientoAnalizar los puntos de acoplamientoEvaluar las contrapartidasTécnicas de compensaciónAnálisis cualitativo frente a análisis cuantitativoListas MECELa trampa "fuera de contextoModelar casos de dominio relevantesPrefiere el resultado final a la evidencia abrumadoraEvitar el aceite de serpiente y el evangelismoSaga del Escuadrón de Sysops: Epílogo

Content preview from Arquitectura de software: Las partes difíciles

Capítulo 1. ¿Qué ocurre cuandono hay "buenas prácticas"?

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

¿Por qué un tecnólogo, como un arquitecto de software, presenta una conferencia o escribe un libro? Porque han descubierto lo que coloquialmente se conoce como "buenas prácticas", un término tan manido que quienes lo pronuncian experimentan cada vez más reacciones en contra. Independientemente del término, los tecnólogos escriben libros cuando han descubierto una solución novedosa a un problema general y quieren difundirla a un público más amplio.

Pero, ¿qué ocurre con ese vasto conjunto de problemas que no tienen buenas soluciones? Existen clases enteras de problemas en la arquitectura del software que no tienen soluciones buenas en general, sino que presentan un conjunto desordenado de compensaciones contra otro conjunto (casi) igual de desordenado.

Los desarrolladores de software adquieren habilidades extraordinarias para buscar en Internet soluciones a un problema actual. Por ejemplo, si necesitan averiguar cómo configurar una herramienta concreta en su entorno, el uso experto de Google encuentra la respuesta.

Pero eso no es cierto para los arquitectos.

Para los arquitectos, muchos problemas presentan retos únicos porque combinan el entorno y las circunstancias exactas de su organización: ¿qué posibilidades hay de que alguien se haya encontrado exactamente con este escenario y lo haya publicado en un blog ...