Arquitecturasoftware Sample

Introducción a la Arquitectura de Software
Conceptos Fundamentales e Implementación
Enrique Pablo Molinari

Este libro está a la venta en http://leanpub.com/arquitecturasoftware
Esta versión se publicó en 2020-12-05
Éste es un libro de Leanpub. Leanpub anima a los autores y publicadoras con el proceso de
publicación. Lean Publishing es el acto de publicar un libro en progreso usando herramientas
sencillas y muchas iteraciones para obtener retroalimentación del lector hasta conseguir el libro
adecuado.
© 2019 - 2020 Enrique Pablo Molinari

Índice general
1. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
I Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
¿Otro libro sobre Arquitectura de Software? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
¿Qué contenidos abordamos en este libro? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
¿Quién debería leer este libro? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Ordenando ideas sobre arquitectura de software . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Arquitectura de Software: Definiciones Esenciales . . . . . . . . . . . . . . . . . . . . . . . 7

¿Qué entendemos por Arquitectura de Software? . . . . . . . . . . . . . . . . . . . . . . . . . 7
Estructuras y Visualización de la Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Modelo de Vistas 4+1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Propuesta de Estructuras y Vistas del SEI . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Visualización en UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Modelo C4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Conclusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Estilos de Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Diseño vs Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
II Conceptos e Implementación . . . . . . . . . . . . . . . . . . . . 9
4. Arquitectura Modular, en Capas y Estilos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Espacio de Nombres, Paquetes, Capas y Módulos . . . . . . . . . . . . . . . . . . . . . . . . . 10
Separación Lógica vs Física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Java Module System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Particiones Horizontales vs Particiones Verticales . . . . . . . . . . . . . . . . . . . . . . . . . 10
¿Por qué partir una aplicación? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
¿Es lo mismo un módulo o una capa (layer)? . . . . . . . . . . . . . . . . . . . . . . . . . 10
Arquitectura en Capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Definiciones y Estilo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
ÍNDICE GENERAL
Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Arquitectura Hexagonal: Clean Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Arquitectura en Capas Invertida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Estilo e Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Arquitectura Modular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Arquitecturas Monolíticas, Distribuidas y Estilos . . . . . . . . . . . . . . . . . . . . . . . 13

Arquitecturas Monolíticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Modular Monolith . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Arquitecturas Distribuidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
¿Por qué distribuir? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Fallas Parciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Transacciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Distributed Monolith . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Microservicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Arquitectura Modular vs Microservicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
III Atributos de Calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6. Disponibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Cálculo de Disponibilidad de un Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Otras Cuestiones que Afectan la Disponibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Disponibilidad en Microservicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Escalabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Escalando Aplicaciones Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Escalando Bases de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Teorema CAP y PACELC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Escalando las lecturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Sharding: Escalando las escrituras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Feedback
Este contenido no está disponible en el libro de muestra. El libro se puede comprar en Leanpub en
http://leanpub.com/arquitecturasoftware.
I Introducción
2. Introducción
En 1986 Frederick Brooks escribió “No Silver Bullet”1 donde afirmaba que no existían soluciones
(balas de plata) únicas para lidiar de forma efectiva con las dificultades esenciales del software
como por ejemplo la complejidad. Él utilizó la analogía de la bala de plata cómo el elemento
que podía terminar definitivamente con el temible Hombre Lobo porque al igual que sucede en el
desarrollo de software, este al inicio era alguien familiar y amigable, que se transforma dando lugar
a algo espantoso. También en este artículo se referencia como una de las prometedoras soluciones,
una posible bala de plata, a los buenos diseñadores de software. Brooks señalaba, “Los mejores
diseñadores producen estructuras que funcionan más rápido, son más simples, sencillas, limpias y
con menor esfuerzo”. Hoy, 34 años después de aquel artículo, la búsqueda de estructuras de software
(funciones, módulos, clases, etc) simples y limpias, sigue siendo un objetivo permanente para la
comunidad de desarrolladores.
Con el correr de los años se fueron popularizando distintos términos que daban cuenta de la
frustración que generaba a los desarrolladores de software el tedioso trabajo de actualizar y mantener
código a medida que se iban agregando nuevos requerimientos en el tiempo. En 1997 se popularizó
la expresión “Big Ball of Mud”2 , algo así como “una gran bola de barro”, y desde aún antes ya
se utilizaba el término “spaghetti-code”. Ambos refiriéndose a sistemas de software sin una clara
definición de su estructura y donde todos los elementos están conectados entre sí, sin un orden o
reglas claras. Esto obviamente, dificulta enormemente la posibilidad de modificarlo.
En 1999 surgió un concepto que definiría estas apreciaciones: entropía del software3 . De esta forma
se define al proceso por el cual los sistemas de software, luego de varios años de mantenimiento
donde han pasado por cambios en requerimientos y han agregado nuevos se convierten en algo
caótico y complejo, difícil de mantener. Por regla general, cuando la entropía llega al sistema de
software, es cuando los programadores, frustrados, comienzan a evaluar otras ofertas de trabajo,
ya que realizar cambios allí es tan complicado que implica destinar horas extras, fuera de horario
laboral, descuidando otros aspectos de la vida cotidiana. Por otro lado, en los casos donde existe
presupuesto para ellos, la empresa decide comenzar en paralelo la re-implementación del mismo
sistema con “mejores prácticas” o tecnología moderna y así comienza una nueva iteración hacia la
(casi siempre) inevitable entropía.
Los años pasan, surgen nuevos términos, pero los problemas y las complicaciones, siguen siendo las
mismas. Y la pregunta sigue siendo la misma ¿Cómo estructurar un sistema de software y mantenerlo
en el tiempo, de modo tal que permita modificarlo sin grandes complicaciones?
A lo largo de este libro se presentarán distintas prácticas, conceptos e implementaciones que buscan
dar respuesta a esta pregunta.
Considero que producir un sistema de software que en el tiempo no se vuelva complejo de modificar
es un objetivo muy perseguido (casi inalcanzable) para todo programador, diseñador o arquitecto de
Introducción 4
software. Gran parte de lo expuesto en este libro está dedicado especialmente a intentar evitar que
la entropía del software gane.
¿Otro libro sobre Arquitectura de Software?

En 1994 David Garlan y Mary Shaw4 escribieron un artículo sobre la importancia de la arquitectura
de software como disciplina emergente. Ellos decían lo siguiente:
“A medida que se incrementa el tamaño y la complejidad de los sistemas de software, los problemas
de diseño van más allá de algoritmos y estructuras de datos. Diseñar y especificar la estructura
general de todo un sistema de software emerge como un nuevo desafío de diseño”.
Desde dicho artículo a hoy se han publicado decenas de libros sobre arquitectura de software. Sin
embargo, la mayoría de ellos se centran en el desarrollo teórico, carecen de ejemplos de código y de
implementación. Es usual encontrar casos donde se explica con un gráfico el estilo de arquitectura
en capas, pero no se hace mención a cómo representar las capas en código fuente, es decir, cómo
se implementan. Desde mi punto de vista, esto es una omisión no menor. Creo que es necesario
expresar y ejemplificar con claridad el conjunto de construcciones sintácticas que se pueden utilizar
para definir una capa y sus límites. En la actualidad los lenguajes de programación de un mismo
paradigma poseen un conjunto muy similar de elementos sintácticos que podemos utilizar, con lo
cual es posible explicar estos conceptos utilizando un lenguaje de forma general y será aplicable en
forma análoga a cualquier otro.
¿Qué contenidos abordamos en este libro?

Cuando el profesor Garlan y a la profesora Shaw hacen referencia a las dificultades de diseñar
y especificar la estructura general de un sistema de software, mencionan la organización global
del sistema, la asignación de responsabilidades o funcionalidades a los elementos de software, la
sincronización entre ellos, los protocolos para comunicarlos, performance y escalabilidad. Éste es el
siguiente nivel de diseño: la arquitectura de software.
En línea con esta definición, la siguiente imagen muestra cuatro diagramas de una misma aplicación
con la intención de visualizar ese siguiente nivel de diseño, la arquitectura:
Introducción 5
Figura 1.1: Código, Diseño y Arquitectura
El primer nivel es claro, no genera dudas. Se escribe software utilizando lenguajes de programación
con una sintaxis y semántica específica, dentro de un paradigma de programación. En el siguiente
nivel de abstracción se observa un diseño orientado a objetos, expresado en un diagrama de clases.
Tampoco aquí surge duda alguna. En el tercer nivel de abstracción es donde comienzan a aparecer
algunas preguntas, ¿esto es arquitectura, o es diseño? ¿Qué describe exactamente este diagrama de
la aplicación? En principio vamos a convenir que representa la estructura en capas de la aplicación,
donde en cada capa se agrupan clases según si están relacionadas a lógica de negocio o a acceso a
datos. Donde además, las clases de la capa de la lógica de negocio dependen de algunas clases de
la capa de acceso a datos, y no al revés. En la cuarta y última imagen es posible observar un nivel
de abstracción más alto que el anterior. En este caso, Calc Application representa la aplicación en
ejecución y Database a la unidad de almacenamiento persistente en ejecución. La flecha indica una
relación de dependencia entre ellos, una comunicación de la forma entre procesos (Inter-Process
Communication).
En este libro se abordan principalmente cuestiones relacionadas a entender, describir e implementar
estructuras de software pertenecientes a los dos últimos niveles de abstracción, que ilustra la figura
1.1. El objetivo es responder las siguientes preguntas:
¿Qué es arquitectura de software? ¿Dónde termina el diseño y comienza la arquitectura? ¿Cómo
graficar la arquitectura del sistema que se quiere implementar? ¿Cómo diseñar un sistema con
los conceptos de arquitectura limpia? ¿Qué son las capas? ¿y los módulos? ¿Estoy implementando
realmente una arquitectura en capas? ¿Son una mala práctica las arquitecturas monolíticas? ¿Son los
microservicios la única opción? ¿Qué es alta disponibilidad? ¿Único punto de falla? ¿Cómo escalar
una aplicación para soportar mejor la demanda en crecimiento?
Este libro no incluye discusiones detalladas de todos los diferentes estilos y patrones de arquitectura
existentes. Si no que se dedica a profundizar mediante ejemplos implementados en el lenguaje
Introducción 6
Java aquellos más utilizados en aplicaciones de empresa. Por otro lado, una vez comprendidos los
conceptos expuestos el lector podrá manejar sin inconvenientes cualquier otro estilo de arquitectura
no incluido en este libro.
¿Quién debería leer este libro?

Este es un libro para desarrolladores de software. Si además pasaste por la mala experiencia de
mantener una aplicación compleja con código spaghetti y que a su vez requería de releases con
nuevas funcionalidades cada cuatro semanas, entonces vas a comprender mejor la importancia que
da tener una arquitectura sólida.
Si tenés experiencia como desarrollador creando buenos diseños orientados a objetos, basándote
en los consejos encontrados en los libros como Design Patterns5 , Clean Code6 , Refactoring7 , Test
Driven Design8 , pero tenés dudas sobre cómo estructurar una aplicación, como reconocer diferentes
estructuras, como diagramar la estructura de una aplicación o de pronto te encontrás en la posición
de arquitecto donde además pasas a ser responsable de la disponibilidad, performance, escalabilidad,
entre otras cuestiones, entonces este libro es para vos.
Ordenando ideas sobre arquitectura de software

3. Arquitectura de Software:
Definiciones Esenciales
¿Qué entendemos por Arquitectura de Software?

Estructuras y Visualización de la Arquitectura

Modelo de Vistas 4+1

Propuesta de Estructuras y Vistas del SEI

Visualización en UML
Modelo C4
Arquitectura de Software: Definiciones Esenciales 8
Conclusión
Estilos de Arquitectura
Diseño vs Arquitectura
II Conceptos e
Implementación
4. Arquitectura Modular, en Capas y
Estilos
Espacio de Nombres, Paquetes, Capas y Módulos

Separación Lógica vs Física

Java Module System

Particiones Horizontales vs Particiones Verticales

¿Por qué partir una aplicación?

¿Es lo mismo un módulo o una capa (layer)?

Arquitectura Modular, en Capas y Estilos 11
Arquitectura en Capas
Definiciones y Estilo
Implementación
Arquitectura Hexagonal: Clean Architecture

Implementación
Arquitectura en Capas Invertida

Arquitectura Modular, en Capas y Estilos 12
Estilo e Implementación
Arquitectura Modular
Implementación
5. Arquitecturas Monolíticas,
Distribuidas y Estilos
Arquitecturas Monolíticas
Definiciones
Modular Monolith
Arquitecturas Distribuidas
¿Por qué distribuir?

Fallas Parciales
Arquitecturas Monolíticas, Distribuidas y Estilos 14
Transacciones
Distributed Monolith
Microservicios
Implementación
Comentarios sobre la implementación
Arquitectura Modular vs Microservicios

III Atributos de Calidad
6. Disponibilidad
Introducción
Cálculo de Disponibilidad de un Sistema

Otras Cuestiones que Afectan la Disponibilidad

Disponibilidad en Microservicios
7. Escalabilidad
Escalando Aplicaciones Web

Escalando Bases de Datos

Teorema CAP y PACELC

Escalando las lecturas

Sharding: Escalando las escrituras

Notas
1 No Silver Bullet, Essence and Accident in Software Engineering. Frederick P. Brooks. 1986.
2 Big Ball of Mud. Brian Foote and Joseph Yoder, Fourth Conference on Patterns Languages of Programs Monticello, Illinois,
September 1997.
NOTAS 18
3 The Pragmatic Programmer: From Journeyman to Master. Andrew Hunt, David Thomas. 1999.
4 An Introduction to Software Architecture. David Garlan, Mary Shaw. CMU Software Engineering Institute Technical
Report. 1994.
5 Design Patterns: Elements of Reusable Object-Oriented Software. 1994.
6 Clean Code: A Handbook of Agile Software Craftsmanship. Robert C. Martin. 2008.
7 Refactoring: Improving the Design of Existing Code. Martin Fowler. 1999.
8 Test Driven Development: By Example. Kent Benck. 2002.

Arquitecturasoftware Sample

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Arquitecturasoftware Sample

Cargado por

Copyright:

Formatos disponibles

Introducción a la Arquitectura de Software

Conceptos Fundamentales e Implementación

Enrique Pablo Molinari

Esta versión se publicó en 2020-12-05

© 2019 - 2020 Enrique Pablo Molinari

3. Arquitectura de Software: Definiciones Esenciales . . . . . . . . . . . . . . . . . . . . . . . 7

5. Arquitecturas Monolíticas, Distribuidas y Estilos . . . . . . . . . . . . . . . . . . . . . . . 13

III Atributos de Calidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

¿Otro libro sobre Arquitectura de Software?

¿Qué contenidos abordamos en este libro?

Figura 1.1: Código, Diseño y Arquitectura

¿Quién debería leer este libro?

Ordenando ideas sobre arquitectura de software

¿Qué entendemos por Arquitectura de Software?

Estructuras y Visualización de la Arquitectura

Modelo de Vistas 4+1

Propuesta de Estructuras y Vistas del SEI

Espacio de Nombres, Paquetes, Capas y Módulos

Separación Lógica vs Física

Java Module System

Particiones Horizontales vs Particiones Verticales

¿Por qué partir una aplicación?

¿Es lo mismo un módulo o una capa (layer)?

Arquitectura Hexagonal: Clean Architecture

Arquitectura en Capas Invertida

¿Por qué distribuir?

Comentarios sobre la implementación

Arquitectura Modular vs Microservicios

Cálculo de Disponibilidad de un Sistema

Otras Cuestiones que Afectan la Disponibilidad

Escalando Aplicaciones Web

Escalando Bases de Datos

Teorema CAP y PACELC

Escalando las lecturas

Sharding: Escalando las escrituras

5 Design Patterns: Elements of Reusable Object-Oriented Software. 1994.

6 Clean Code: A Handbook of Agile Software Craftsmanship. Robert C. Martin. 2008.

7 Refactoring: Improving the Design of Existing Code. Martin Fowler. 1999.

8 Test Driven Development: By Example. Kent Benck. 2002.

También podría gustarte