Arquitectura de software

Puntos clave a implementar al area:

---

1. Planificación del diseño de software

   • Diseñar de manera anticipada las clases, métodos y patrones de diseño a implementar.
   • Elegir patrones que garanticen modularidad, escalabilidad y simplicidad.

2. Optimización y especificaciones del dispositivo objetivo

   • Identificar rangos de optimización necesarios según el dispositivo target.
   • Establecer las capacidades y especificaciones mínimas requeridas para garantizar un funcionamiento óptimo.

3. Identificación de riesgos y desafíos técnicos

   • Analizar posibles casos de uso para detectar riesgos o dificultades técnicas.
   • Anticipar soluciones viables para los problemas identificados durante el desarrollo.

4. Mantenibilidad del proyecto

   • Diseñar el software pensando en su fácil mantenimiento y actualización.
   • Asegurarse de que el código sea limpio, legible y documentado para facilitar futuras modificaciones.

5. Testeabilidad del proyecto

   • Implementar estrategias que permitan probar el sistema de manera rápida y eficiente.
   • Diseñar componentes con bajo acoplamiento para permitir pruebas unitarias, de integración y funcionales de forma independiente.

6. Documentación de decisiones de diseño

   • Registrar las razones detrás de cada decisión de diseño tomada durante el desarrollo.
   • Incluir alternativas consideradas y justificar la elección final para mejorar la trazabilidad.

7. Uso estratégico de herramientas y plugins

   • Aprovechar herramientas y plugins para mejorar la productividad y el desarrollo.
   • Diseñar el sistema desacoplado de dependencias externas para evitar que su funcionamiento dependa exclusivamente de estas herramientas.

---

Que significa la arquitectura de software?

La arquitectura de software, en su esencia, va más allá de la mera selección de tecnologías o el diseño de estructuras visuales. Es una disciplina integral dentro de la ingeniería de software que implica la creación de una estructura conceptual y técnica para un sistema informático, que asegura que cumpla con los requisitos funcionales y no funcionales, tanto actuales como futuros.

Uno de los principios fundamentales de la arquitectura de software es su independencia tecnológica. Esto significa que la arquitectura debe estar diseñada de manera que no esté atada a una tecnología específica, lo que permite una mayor flexibilidad y adaptabilidad a medida que evoluciona el panorama tecnológico. En lugar de centrarse en herramientas o lenguajes de programación específicos, la arquitectura se enfoca en los principios y patrones de diseño que permiten la construcción de sistemas sólidos y escalables.

ORGANIZAR, ESTRUCTURAR, DAR UN SENTIDO AL SOFWARE Y QUE CUMPLA CON CIERTOS REQUISITOS DE CALIDAD COMO ESCALABILIDAD, MANTENIMIENTO Y RASTREO DE ERRORES

Tipos de enfoques

1. Codificación bottom-up: Enfoque de desarrollo de software que comienza con la implementación de componentes individuales y gradualmente los integra en un sistema completo.
2. Codificación top-down: Estrategia de desarrollo de software que comienza con una visión global del sistema y luego descompone su diseño en componentes más pequeños y manejables para su implementación.

GRASP

En arquitectura de software, GRASP (General Responsibility Assignment Software Patterns) se refiere a un conjunto de patrones de diseño que ayudan a asignar responsabilidades específicas a las clases y objetos en un sistema. Estos patrones proporcionan pautas claras para mejorar la modularidad, la reutilización y la mantenibilidad del código, al tiempo que promueven un diseño orientado a objetos sólido y flexible. Los principios GRASP son herramientas útiles para los arquitectos y diseñadores de software en la toma de decisiones sobre cómo asignar responsabilidades de manera efectiva en un sistema.

Principios:

Algunos de los principios más importantes en arquitectura de software incluyen:

1. Separación de preocupaciones (Separation of Concerns): Este principio establece que un sistema debe estar dividido en componentes o módulos distintos, cada uno de los cuales se ocupa de una preocupación específica. Esto facilita la comprensión, el mantenimiento y la evolución del sistema.
2. Modularidad: La modularidad implica dividir un sistema en partes más pequeñas y manejables, llamadas módulos, que pueden ser desarrolladas, probadas, modificadas y reutilizadas de forma independiente. Esto promueve la flexibilidad y la escalabilidad del sistema.
3. Abstracción: La abstracción consiste en ocultar los detalles internos de un componente y exponer solo la información relevante y necesaria para su uso. Esto ayuda a simplificar la complejidad del sistema y facilita su comprensión y uso.
4. Reusabilidad: La reusabilidad implica diseñar componentes de software de manera que puedan ser utilizados en diferentes partes del sistema o en diferentes proyectos. Esto reduce el esfuerzo de desarrollo y mejora la consistencia y la calidad del software.
5. Encapsulamiento: El encapsulamiento consiste en agrupar los datos y los métodos que operan sobre esos datos en una unidad coherente, llamada clase. Esto ayuda a proteger los datos internos de un objeto y a garantizar su coherencia y consistencia.
6. Acoplamiento mínimo: El acoplamiento mínimo implica reducir las interdependencias entre los distintos componentes del sistema. Esto hace que el sistema sea más flexible, ya que los cambios en un componente tienen un impacto mínimo en otros componentes.
7. Cohesión alta: La cohesión alta implica que los elementos dentro de un módulo o componente están altamente relacionados y trabajan juntos para lograr un objetivo común. Esto mejora la claridad y la mantenibilidad del código.
8. Principio DRY (Don't Repeat Yourself): Este principio promueve la reutilización del código y la eliminación de duplicación, lo que ayuda a mantener el código más limpio, legible y fácil de mantener.

Pasos

1. Requisitos: En esta fase, se recopilan y analizan las necesidades y expectativas del cliente para el sistema de software que se va a desarrollar. Es como dibujar un mapa antes de comenzar un viaje, para saber a dónde queremos llegar.

• Se hace la mayor identificación de riesgos
• Riesgos técnicos y atributos de calidad
• Identificación de sistemas, drivers, plugins, etc.
• Definición de perfiles
• Riesgos tecnológicos y estimación tiempos

1. Diseño: Durante esta etapa, se crea un plan detallado para cómo se construirá el software. Esto implica decidir qué partes va a tener, cómo se van a comunicar entre sí y cómo se van a ver y funcionar para los usuarios. Es como diseñar los planos de una casa antes de empezar a construirla.

• Decision de arquitectura
• Prototipos, maqueta Insumo: requerimientos Salida: Arquitectura candidata

2. Implementación: Aquí es donde se escribe realmente el código del software según el diseño establecido en la fase anterior. Es como construir la casa usando los planos que se hicieron previamente.
3. Pruebas: Después de escribir el código, se realizan pruebas para asegurarse de que el software funciona como se espera y cumple con los requisitos del cliente. Es como hacer una inspección final en una casa antes de entregarla al propietario.

• Verificación y validación de funcionamiento y calidad
• Endurance

4. Despliegue: Una vez que el software ha sido probado y aprobado, se pone en funcionamiento para que los usuarios finales puedan utilizarlo. Es como abrir la puerta de la casa y permitir que la gente entre a vivir en ella.
5. Mantenimiento: Esta fase implica corregir errores, hacer mejoras y agregar nuevas características al software una vez que está en uso. Es como realizar reparaciones y remodelaciones en una casa a medida que pasa el tiempo y las necesidades cambian.

Diseño arquitectónico vs Diseño detallado de software

1. Diseño Arquitectónico:

   • Definición: El diseño arquitectónico se enfoca en establecer la estructura general y las principales características del sistema de software. En esta etapa, se toman decisiones de alto nivel sobre la organización del sistema, como los componentes principales, las interacciones entre ellos y las tecnologías a utilizar.
   • Propósito: El objetivo del diseño arquitectónico es proporcionar una visión clara y amplia del sistema, identificando los elementos clave y cómo se relacionan entre sí para cumplir con los requisitos del cliente.
   • Ejemplo: En el diseño arquitectónico de un sistema de comercio electrónico, se podrían definir los componentes principales como la interfaz de usuario, la lógica de negocio y la base de datos, junto con las tecnologías a utilizar, como un framework MVC (Modelo-Vista-Controlador) y una base de datos relacional.

2. Diseño Detallado:

   • Definición: El diseño detallado se centra en los aspectos específicos de implementación de cada componente del sistema. Aquí, se definen en detalle las estructuras de datos, los algoritmos y las interfaces de cada módulo o clase.
   • Propósito: El objetivo del diseño detallado es traducir las decisiones de alto nivel del diseño arquitectónico en especificaciones concretas que guíen la implementación del software. Se concentra en cómo se van a realizar las funcionalidades del sistema.
   • Ejemplo: En el diseño detallado del componente de autenticación de un sistema de comercio electrónico, se podrían definir las clases específicas, como Usuario y Autenticador, junto con los métodos y algoritmos para verificar credenciales de usuario.

Non-Functional Requirements / Requerimientos de calidad

Los requisitos no funcionales (Non-Functional Requirements, NFRs) son criterios que describen la calidad del sistema de software en lugar de sus funciones específicas. Estos requisitos definen características importantes que no se relacionan directamente con las funcionalidades del sistema, pero que son fundamentales para su éxito y aceptación por parte de los usuarios. Algunos ejemplos comunes de requisitos no funcionales en arquitectura de software incluyen:

1. Rendimiento: Especificaciones relacionadas con la velocidad, la capacidad de procesamiento y la eficiencia del sistema. Esto puede incluir tiempos de respuesta, capacidad de manejo de cargas de trabajo pesadas y optimización de recursos.
2. Disponibilidad: Requisitos relacionados con la confiabilidad y la disponibilidad del sistema. Esto puede incluir el tiempo de actividad objetivo, la tolerancia a fallos y los mecanismos de recuperación ante desastres.
3. Seguridad: Especificaciones relacionadas con la protección de los datos y la prevención de accesos no autorizados. Esto puede incluir la autenticación de usuarios, el cifrado de datos, la gestión de permisos y el cumplimiento de regulaciones de seguridad.
4. Escalabilidad: Requisitos relacionados con la capacidad del sistema para crecer y adaptarse a cambios en la demanda o en el tamaño de la base de usuarios. Esto puede incluir la capacidad de agregar recursos de manera incremental y la distribución de carga entre múltiples servidores.
5. Mantenibilidad: Especificaciones relacionadas con la facilidad de mantenimiento y modificación del sistema. Esto puede incluir la claridad del código, la documentación adecuada y la facilidad para realizar cambios sin afectar otras partes del sistema.
6. Usabilidad: Requisitos relacionados con la facilidad de uso y la experiencia del usuario. Esto puede incluir la accesibilidad para personas con discapacidades, la claridad de la interfaz de usuario y la eficiencia en la realización de tareas.
7. Interoperabilidad: Especificaciones relacionadas con la capacidad del sistema para interactuar con otros sistemas o componentes externos. Esto puede incluir la compatibilidad con estándares y protocolos de comunicación.

Tipos de cambios a considerar cuando se diseña un software

• por defecto : propiedades de la aplicación que tiene para identificar y permitir cambios sobre ese defecto (Mantenibilidad)
• Características nuevas, extensibilidad
• Modificaciones a características existentes, flexibilidad
• Escalabilidad (flujo de usuarios)

Historias de usuario

Las Historias de Usuario son descripciones breves de características de software desde la perspectiva del usuario. Por ejemplo: "Como usuario, quiero poder iniciar sesión con mi correo electrónico y contraseña para acceder a mi cuenta".

INVEST

En arquitectura de software, "invest" (también conocido como INVEST) es un acrónimo que representa una serie de características deseables para las historias de usuario:

• Independiente: La historia de usuario debe ser independiente de otras para poder ser desarrollada y entregada de manera aislada.
• Negociable: Debe ser lo suficientemente flexible para ser negociada entre el equipo de desarrollo y los stakeholders.
• Valiosa: Debe agregar valor al usuario o al negocio.
• Estimable: Es necesario poder estimar el esfuerzo necesario para su implementación.
• Pequeña: Debería ser lo suficientemente pequeña para ser completada en una iteración corta.
• Testeable: Debe ser posible probar y verificar que la historia de usuario ha sido implementada correctamente.

Estas características ayudan a asegurar que las historias de usuario sean claras, factibles y valiosas para el desarrollo de software.

Casos de uso:

Los casos de uso en arquitectura de software son una técnica utilizada para capturar y describir las interacciones entre un sistema y sus actores externos (usuarios, sistemas externos, etc.). Estos casos de uso describen cómo se utiliza el sistema para lograr ciertos objetivos o realizar ciertas tareas. Cada caso de uso generalmente se representa en forma de un escenario narrativo que describe una secuencia de interacciones entre el usuario y el sistema.

Por ejemplo, en un sistema de gestión de biblioteca, un caso de uso podría ser "Prestar libro", donde un usuario (el bibliotecario o el cliente) interactúa con el sistema para registrar la solicitud de préstamo de un libro, verificar la disponibilidad del libro, registrar la transacción y actualizar el estado del libro en el sistema. Los casos de uso son útiles para comprender y documentar los requisitos funcionales del sistema y son una herramienta importante durante el diseño y desarrollo del software.

Escenarios

En arquitectura de software, un escenario es una descripción detallada de cómo interactúan los usuarios (o actores) con el sistema para lograr un objetivo específico. Los escenarios suelen describirse en un lenguaje natural y narrativo, mostrando la secuencia de pasos que el usuario sigue para realizar una tarea dentro del sistema.

Un escenario en arquitectura de software puede describirse generalmente con la siguiente estructura:

• Evento: Describe la acción o evento que inicia el escenario, es decir, lo que el usuario o actor hace para interactuar con el sistema.
• Condiciones: Especifica las condiciones o situaciones que pueden influir en el desarrollo del escenario, como el estado actual del sistema, la información disponible, etc.
• Respuesta del Sistema: Describe cómo responde el sistema ante el evento y las condiciones establecidas. Esto incluye las acciones que realiza el sistema y cualquier salida o resultado que se genere como respuesta al evento.

Elemento	Descripción
Origen del Evento	Quién o qué genera el estímulo.
Evento	Acción o condición que se da para iniciar el escenario. Es la acción que se quiere llevar a cabo.
Entorno	Condiciones dentro de las cuales se presenta el evento.
Artefacto	Sistema o componente del sistema que se ve afectado por el evento.
Respuesta	Acción que ejecuta el artefacto luego de la llegada del evento.
Medida de la Respuesta	Métrica cuantificable que sirve para verificar y validar el requerimiento.

Ejemplos:

Elemento	Descripción
Origen del Evento	Usuarios
Evento	1000 transacciones de tipo X por minuto
Artefacto	Sistema
Entorno	Bajo condiciones normales, de 9 am a 6 pm
Respuesta	Procesar la transacción mostrando el resultado en pantalla
Medida de la Respuesta	Latencia menor a 3 segundos

Por ejemplo, consideremos un escenario de "Inicio de sesión en un sistema de gestión de documentos":

Evento: Un usuario introduce su nombre de usuario y contraseña en el formulario de inicio de sesión. Condiciones: Las credenciales proporcionadas por el usuario son válidas y activas en el sistema. Respuesta del Sistema: El sistema verifica las credenciales, autentica al usuario y muestra el panel de control con las opciones disponibles para el usuario.

Esta estructura permite describir de manera clara y concisa cómo se comporta el sistema en diferentes situaciones y cómo responde a las acciones de los usuarios.

Tipos de fallas:

1. Por Caída: Ocurre cuando un sistema deja de funcionar completamente.
2. Por Omisión: Se da cuando el sistema no realiza una acción esperada o necesaria.
3. Fallas por Tiempo: Suceden cuando el sistema no responde dentro de un período esperado.
4. Falla por Respuesta: Ocurre cuando la respuesta del sistema no es la correcta o esperada.

• Recuperación Ante fallos: Modo sombra

  El "modo sombra" (también conocido como "modo de sombra" o "modo de operación en sombra") es una estrategia utilizada en la recuperación ante fallos de un sistema informático o de red. En este modo, una réplica del sistema principal (o sus componentes críticos) está en funcionamiento simultáneo con el sistema principal, pero no se utiliza activamente para procesar datos o responder a las solicitudes de los usuarios. En cambio, está listo para entrar en acción inmediatamente si el sistema principal experimenta una falla.

  En otras palabras, el sistema en modo sombra se mantiene sincronizado con el sistema principal para garantizar una transición fluida en caso de que el sistema principal falle. Cuando se detecta una falla en el sistema principal, el sistema en modo sombra puede activarse rápidamente para tomar su lugar y minimizar el tiempo de inactividad. Esto ayuda a garantizar la disponibilidad y la continuidad del servicio, lo que es especialmente importante en entornos donde el tiempo de inactividad puede resultar costoso o crítico.

• Attribute Driven Design

  Según la arquitectura de software, el "Attribute Driven Design" (ADD) es un enfoque para diseñar la arquitectura de un sistema basado en sus atributos de calidad, como el rendimiento, la seguridad, la usabilidad, la escalabilidad, etc. En lugar de centrarse únicamente en la funcionalidad del sistema, ADD considera cómo se pueden satisfacer los atributos de calidad clave a través de decisiones arquitectónicas.

  La "fase de decisión" en el contexto de ADD es cuando se toman las decisiones arquitectónicas fundamentales sobre cómo se estructurará el sistema para satisfacer sus atributos de calidad. Durante esta fase, los arquitectos identifican los atributos de calidad críticos, evalúan diferentes alternativas arquitectónicas y eligen la mejor solución para el sistema.

  La "fase de documentación" implica la creación de documentos arquitectónicos detallados que describen la arquitectura del sistema, las decisiones tomadas durante la fase de decisión, y cómo se espera que el sistema satisfaga sus atributos de calidad. Estos documentos pueden incluir diagramas arquitectónicos, descripciones de componentes, análisis de riesgos, etc. La documentación arquitectónica es crucial para comunicar eficazmente la arquitectura del sistema a todas las partes interesadas y para guiar el desarrollo y la evolución del sistema a lo largo del tiempo.

• Tubes and Pipes Architecture Pattern

  El patrón de arquitectura "Tubes and Pipes" (Tubos y Tuberías) es un enfoque que se basa en la idea de dirigir flujos de datos a través de componentes que actúan como "tuberías" (pipes) y "tubos" (tubes). Este patrón se utiliza para diseñar sistemas donde los datos fluyen a través de una serie de etapas de procesamiento.

  En este modelo:

  • Tubos (Tubes): Representan los canales de comunicación entre las diferentes etapas del sistema. Los datos fluyen a través de estos tubos, y cada tubo puede tener diferentes propiedades, como la capacidad de transformar o filtrar los datos.
  • Tuberías (Pipes): Son los componentes que realizan operaciones específicas en los datos que fluyen a través de ellos. Cada tubería recibe datos de un tubo, realiza algún tipo de procesamiento o transformación en esos datos, y luego los pasa al siguiente tubo.

  Este patrón es especialmente útil en sistemas donde el procesamiento de datos se puede dividir en una serie de pasos discretos y secuenciales. Al utilizar el patrón de "Tubes and Pipes", se puede lograr un diseño modular y escalable, donde cada componente (tubería) puede ser reutilizado en diferentes contextos y las diferentes etapas de procesamiento pueden ser fácilmente modificadas o extendidas sin afectar al resto del sistema.

Arquitectura por capas

La arquitectura por capas es un estilo arquitectónico comúnmente utilizado en el diseño de sistemas de software, donde el sistema se divide en capas o niveles lógicos, cada uno con una responsabilidad específica. Cada capa se comunica solo con las capas adyacentes, lo que promueve la modularidad, la separación de preocupaciones y la reutilización de código.

Las capas comunes en una arquitectura por capas incluyen:

1. Capa de Presentación (UI): Es la capa más externa que interactúa con los usuarios finales. Se encarga de mostrar la interfaz de usuario y de capturar las interacciones del usuario.

   

2. Capa de Lógica de Negocio (Business Logic): Contiene la lógica de negocio y las reglas de negocio de la aplicación. Procesa los datos recibidos de la capa de presentación y realiza operaciones relacionadas con la lógica del dominio de la aplicación.

   

3. Capa de Acceso a Datos (Data Access): Se encarga de acceder y manipular los datos almacenados en la base de datos u otros sistemas de almacenamiento de datos. Proporciona interfaces para realizar operaciones de lectura, escritura, actualización y eliminación de datos.

A veces, se pueden agregar capas adicionales como:

1. Capa de Servicios (Services Layer): Proporciona servicios reutilizables que pueden ser consumidos por otras capas de la aplicación. Estos servicios encapsulan la funcionalidad común que puede ser utilizada por diferentes partes del sistema.
2. Capa de Infraestructura (Infrastructure Layer): Incluye componentes que brindan soporte técnico a la aplicación, como la gestión de la configuración, la seguridad, el registro y la gestión de errores.

La arquitectura por capas promueve la modularidad, la escalabilidad y la mantenibilidad del sistema al organizar la aplicación en componentes separados y bien definidos, lo que facilita su desarrollo, prueba y evolución a lo largo del tiempo.

Conceptos Extra mencionados en el curso:

• Peer To Peer Architecture Pattern (arquitectura basada en eventos)

  En el contexto de la arquitectura basada en eventos, la arquitectura peer-to-peer se refiere a un modelo donde los eventos son distribuidos y procesados de manera descentralizada entre los nodos de la red. Cada nodo puede generar, enviar y recibir eventos, y puede actuar como un emisor o receptor de eventos según sea necesario.

  Este modelo permite una comunicación más directa entre los nodos y una mayor flexibilidad en la distribución y procesamiento de eventos en la red. Es especialmente útil en situaciones donde se requiere una alta disponibilidad y resistencia a fallos, ya que no depende de un servidor centralizado que pueda convertirse en un punto de fallo único.

  En resumen, en una arquitectura basada en eventos, la arquitectura peer-to-peer permite la distribución descentralizada y el procesamiento de eventos entre los nodos de la red, lo que proporciona una mayor flexibilidad y escalabilidad en la gestión de eventos en sistemas distribuidos.

• Patrón broker

  El patrón de Broker, también conocido como el patrón de Correo, es un patrón de diseño utilizado en arquitectura de software para facilitar la comunicación entre componentes de un sistema distribuido. En este patrón, un componente centralizado llamado "broker" actúa como intermediario para dirigir y gestionar las interacciones entre los diferentes componentes del sistema.

  El patrón de Broker se compone de los siguientes elementos:

  1. Broker: Es el componente central que recibe las solicitudes de los clientes y las dirige a los servicios correspondientes para su procesamiento. El broker también puede realizar funciones como la transformación de datos, el enrutamiento y la gestión de transacciones.
  2. Clientes: Son los componentes o aplicaciones que envían solicitudes al broker para realizar alguna acción o recibir algún servicio.
  3. Servicios: Son los componentes o aplicaciones que proporcionan funcionalidades específicas y que son invocados por el broker para atender las solicitudes de los clientes.

  El patrón de Broker proporciona varios beneficios, incluyendo la desacoplamiento entre los clientes y los servicios, la centralización de la lógica de enrutamiento y la capacidad de añadir o eliminar servicios sin afectar a los clientes existentes. Este patrón es especialmente útil en sistemas distribuidos donde se necesita gestionar la complejidad de la comunicación entre componentes heterogéneos.

• Capa anti corrupción

  La Capa Anti-Corrupción (también conocida como "Anti-Corruption Layer" en inglés) es un patrón arquitectónico utilizado en el diseño de sistemas de software para separar y mitigar el impacto de las dependencias externas o sistemas legados que pueden tener interfaces y modelos de datos no deseados o incompatibles con la arquitectura del sistema actual.

  Cuando un sistema interactúa con otros sistemas externos, especialmente aquellos con diseños obsoletos o interfaces incompatibles, puede resultar complicado integrarlos sin comprometer la integridad y coherencia de la propia arquitectura del sistema.

  La Capa Anti-Corrupción actúa como una interfaz entre el sistema principal y los sistemas externos, traduciendo y adaptando los datos y las operaciones entre las diferentes representaciones y modelos de datos. Esto permite que el sistema principal interactúe con los sistemas externos de manera más limpia y coherente, sin verse afectado negativamente por sus peculiaridades o limitaciones.

  Algunas características y funciones de la Capa Anti-Corrupción incluyen:

  1. Mapeo de datos: Convertir los datos recibidos de los sistemas externos a un formato más adecuado para el sistema principal, y viceversa.
  2. Transformación de operaciones: Adaptar las operaciones y llamadas de funciones entre los sistemas para que sean compatibles y coherentes.
  3. Encapsulación de lógica: Ocultar la complejidad y las peculiaridades de los sistemas externos detrás de una interfaz más simple y coherente para el sistema principal.
  4. Gestión de errores: Manejar y traducir los errores y excepciones que puedan surgir al interactuar con los sistemas externos.

• Patron repository

  El patrón Repository (Repositorio) es un patrón de diseño utilizado en el desarrollo de software para separar la lógica empresarial de la lógica de acceso a datos. Su objetivo principal es proporcionar una capa de abstracción entre la lógica de la aplicación y los detalles de cómo se almacenan y recuperan los datos en la fuente de datos, ya sea una base de datos, un servicio web, un archivo, etc.

  En esencia, el patrón Repository proporciona una interfaz común y coherente para interactuar con los datos, independientemente de la tecnología subyacente utilizada para almacenarlos. Esto facilita el cambio de la fuente de datos subyacente sin necesidad de modificar la lógica de la aplicación.

  Las principales características y responsabilidades del patrón Repository incluyen:

  1. Abstracción de la fuente de datos: El Repository oculta los detalles específicos de cómo se accede y se manipulan los datos en la fuente de datos.
  2. Centralización de la lógica de acceso a datos: Todas las operaciones de lectura y escritura de datos se implementan en el Repository, proporcionando un único punto de acceso para la lógica de acceso a datos.
  3. Desacoplamiento de la lógica de la aplicación: Permite que la lógica de la aplicación se centre en las operaciones del negocio, sin preocuparse por los detalles de cómo se almacenan y recuperan los datos.
  4. Promoción de la reutilización y la modularidad: Al proporcionar una interfaz coherente para interactuar con los datos, el Repository facilita la reutilización de la lógica de acceso a datos en diferentes partes de la aplicación.

  El patrón Repository es especialmente útil en aplicaciones de gran escala y complejidad, donde la separación clara entre la lógica de negocio y la lógica de acceso a datos es fundamental para mantener la mantenibilidad y la escalabilidad del sistema.

• Patron DAO

  El patrón DAO (Data Access Object) es un patrón de diseño utilizado en el desarrollo de software para separar la lógica de acceso a datos de la lógica de negocio. Su objetivo principal es proporcionar una capa de abstracción entre la aplicación y la fuente de datos subyacente (como una base de datos, servicio web, archivo, etc.), facilitando así la manipulación de datos de manera independiente de la tecnología de almacenamiento utilizada.

  Las principales características y responsabilidades del patrón DAO incluyen:

  1. Abstracción de la fuente de datos: El DAO oculta los detalles específicos de cómo se accede y se manipulan los datos en la fuente de datos.
  2. Centralización de la lógica de acceso a datos: Todas las operaciones de lectura y escritura de datos se implementan en el DAO, proporcionando un único punto de acceso para la lógica de acceso a datos.
  3. Desacoplamiento de la lógica de la aplicación: Permite que la lógica de la aplicación se centre en las operaciones del negocio, sin preocuparse por los detalles de cómo se almacenan y recuperan los datos.
  4. Promoción de la reutilización y la modularidad: Al proporcionar una interfaz coherente para interactuar con los datos, el DAO facilita la reutilización de la lógica de acceso a datos en diferentes partes de la aplicación.

  En resumen, el patrón DAO es una forma efectiva de organizar y gestionar la lógica de acceso a datos en una aplicación, lo que facilita la mantenibilidad, la escalabilidad y la flexibilidad del sistema.

• Lazy loading

  El "lazy loading" (carga perezosa) es una técnica de programación utilizada en el desarrollo de software para retrasar la carga de objetos o datos hasta el momento en que sean necesarios. En lugar de cargar todos los datos al principio, el lazy loading posterga la carga hasta que se solicite explícitamente.

  Esta técnica es particularmente útil cuando se trabaja con grandes conjuntos de datos o cuando la carga de ciertos recursos puede ser costosa en términos de tiempo o recursos computacionales. Al cargar los datos solo cuando se necesitan, se puede mejorar el rendimiento general de la aplicación y reducir el uso de memoria.

  Un ejemplo común de lazy loading se encuentra en la carga de imágenes en aplicaciones web. En lugar de cargar todas las imágenes de una página web al mismo tiempo, se pueden cargar solo las imágenes visibles en la pantalla inicialmente. A medida que el usuario se desplaza hacia abajo en la página, las imágenes adicionales se cargan a medida que son necesarias, reduciendo así el tiempo de carga inicial de la página y mejorando la experiencia del usuario.

  En resumen, el lazy loading es una técnica de optimización que retrasa la carga de recursos hasta que se necesiten, lo que puede mejorar el rendimiento y la eficiencia de una aplicación.

• Estrategia de arquitectura vs Tácticas de arquitectura

  En la arquitectura de software, tanto las estrategias como las tácticas son enfoques utilizados para abordar diferentes aspectos del diseño y la implementación de sistemas de software. Aunque están interrelacionadas y a menudo se usan juntas, hay una diferencia fundamental entre ambas:

  1. Estrategias de Arquitectura: Las estrategias de arquitectura son decisiones de alto nivel que guían la dirección general del diseño arquitectónico de un sistema. Estas estrategias establecen los principios generales, las directrices y los objetivos arquitectónicos que deben seguirse para lograr los resultados deseados. Por ejemplo, una estrategia de arquitectura puede incluir la elección de un paradigma de diseño (como la arquitectura de microservicios o la arquitectura monolítica), la selección de tecnologías clave o la definición de patrones arquitectónicos a seguir.
  2. Tácticas de Arquitectura: Las tácticas de arquitectura son acciones específicas y prácticas que se utilizan para implementar y cumplir con las estrategias de arquitectura. Estas tácticas representan decisiones más detalladas y concretas sobre cómo se diseñará y se construirá el sistema para cumplir con los objetivos arquitectónicos establecidos. Por ejemplo, algunas tácticas comunes incluyen la implementación de cachés, la división en capas, el uso de patrones de diseño específicos, la optimización de consultas de base de datos, entre otros.

  En resumen, las estrategias de arquitectura definen la visión general y los objetivos arquitectónicos de un sistema, mientras que las tácticas de arquitectura se refieren a las acciones específicas y prácticas utilizadas para implementar esas estrategias y alcanzar esos objetivos. Ambas son importantes en el proceso de diseño y desarrollo de sistemas de software, trabajando juntas para garantizar que el sistema resultante cumpla con los requisitos y expectativas establecidos.

• Documentación basada en perspectivas

  La documentación basada en perspectivas en arquitectura de software se refiere a crear documentos que describen la arquitectura de un sistema desde diferentes puntos de vista o perspectivas. Cada perspectiva aborda un aspecto específico del sistema, lo que permite a diferentes partes interesadas comprender y analizar el sistema desde diferentes ángulos.

  Imagina un edificio: una persona interesada en la estructura física podría querer ver los planos y diseños arquitectónicos, mientras que alguien interesado en la seguridad podría querer ver los planos de seguridad y acceso. En el contexto del software, diferentes partes interesadas, como desarrolladores, arquitectos de software, gerentes de proyecto y usuarios finales, pueden tener diferentes preocupaciones y necesidades de información sobre el sistema.

  Las perspectivas comunes en la documentación de arquitectura de software incluyen:

  1. Perspectiva de estructura: Describe la organización de los componentes del sistema y cómo interactúan entre sí.
  2. Perspectiva de comportamiento: Se centra en cómo el sistema se comporta en respuesta a diferentes estímulos y eventos.
  3. Perspectiva de despliegue: Describe cómo se instala y se ejecuta el sistema en el entorno de producción.
  4. Perspectiva de datos: Se enfoca en la estructura y el flujo de los datos dentro del sistema.
  5. Perspectiva de seguridad: Detalla las medidas de seguridad implementadas en el sistema para protegerlo contra amenazas y vulnerabilidades.
  6. Perspectiva de rendimiento: Analiza el rendimiento del sistema, incluyendo tiempo de respuesta, carga y escalabilidad.

Extras:

1. SSO (Single Sign-On)

Es un método de autenticación que permite a los usuarios acceder a múltiples aplicaciones con una sola sesión de inicio de sesión, eliminando la necesidad de credenciales múltiples.

2. Modelamiento Ágil

En el contexto de desarrollo ágil, es la creación rápida de modelos simples (diagramas, bocetos, prototipos) para guiar el desarrollo, sin detener el flujo del proyecto, manteniendo la flexibilidad y adaptabilidad.

3. Esqueleto que Camina (Walking Skeleton)

Un enfoque donde se crea una versión mínima funcional de una aplicación que recorre de manera básica todos los componentes principales del sistema, proporcionando una base funcional para futuras iteraciones.

4. DTO (Data Transfer Object)

Es un objeto usado para transferir datos entre capas de una aplicación, generalmente evitando exponer entidades internas directamente y mejorando la eficiencia al evitar datos innecesarios.

5. Interfaces

En programación, una interfaz define un contrato que las clases deben cumplir, especificando los métodos y propiedades que deben implementar, sin proporcionar detalles de la implementación.

6. Microservicios

Una arquitectura donde una aplicación se divide en pequeños servicios independientes, cada uno enfocado en una funcionalidad específica, que se comunican entre sí generalmente mediante APIs.

7. ORM (Object-Relational Mapping)

Una técnica que permite interactuar con bases de datos relacionales utilizando objetos en lugar de escribir directamente consultas SQL, simplificando la persistencia de datos.

8. Reglas de Negocio

Son las condiciones, restricciones o lógicas específicas que definen cómo debe operar un sistema en función de los requerimientos del negocio o de los usuarios.

9. Mapper

En programación, un mapper transforma datos de una estructura u objeto a otra, generalmente usado para convertir DTOs en entidades de negocio o viceversa.

10. Inyección de Dependencias (Dependency Injection)

Es un patrón de diseño donde las dependencias de una clase (como objetos o servicios necesarios) se proporcionan desde el exterior, en lugar de ser creadas dentro de la misma clase, facilitando pruebas y mantenimiento.

11. UML (Unified Modeling Language)

Es un lenguaje visual estándar utilizado para modelar sistemas de software. Incluye diagramas como casos de uso, clases, secuencias y actividades, que ayudan a representar la estructura y comportamiento de un sistema de manera comprensible para desarrolladores y partes interesadas.

12. Vista de Asignación/Despliegue (Deployment View)

En arquitectura de software, es una representación de cómo los componentes de software se asignan y despliegan en la infraestructura física (servidores, dispositivos, red). Incluye detalles sobre nodos, conexiones y dependencias entre hardware y software.

MVC

(Modelo-Vista-Controlador) es un patrón en el diseño de software comúnmente utilizado para implementar interfaces de usuario, datos y lógica de control. Enfatiza una separación entre la lógica de negocios y su visualización. Esta "separación de preocupaciones" proporciona una mejor división del trabajo y una mejora de mantenimiento.

Mas Videos: ARQUITECTURA de SOFTWARE vs DISEÑO de SOFTWARE

¿Por qué Debes Aprender ARQUITECTURA de SOFTWARE?

¿Qué es una CAPA en Arquitectura de Software? Explicación con código

Patrones de Arquitectura vs Patrones de Diseño