Patrones

1. Estilos Arquitectonicos

1.1. Monolitica

1.1.1. Arquitectura donde la aplicación se encuentra en un único código o sistema donde tiene toda la funcionalidad necesaria para realizar la tarea para la cual fue diseñada, sin contar con dependencias externas que complementen su funcionalidad.

1.2. Orientada a servicios

1.2.1. Un enfoque arquitectónico que organiza una aplicación en servicios independientes, diseñados para realizar funciones específicas, y que se comunican entre sí a través de protocolos estándar.

1.3. Microservicios

1.3.1. Es un método de desarrollo de software que consiste en dividir una aplicación en servicios independientes y pequeños. Cada servicio tiene un ámbito de responsabilidad y se comunica con los demás a través de API.

1.4. En capas N-Tier Y NLayer

1.4.1. Modelo que divide una aplicación en capas funcionales o lógicas, como presentación, lógica de negocio y base de datos, para separar responsabilidades y facilitar el mantenimiento.

1.5. Basada en Eventos

1.5.1. Arquitectura que utiliza eventos como la principal forma de interacción entre los componentes, permitiendo respuestas en tiempo real a cambios o acciones específicas.

1.6. Micronucleo

1.6.1. Arquitectura que tiene un núcleo central con funcionalidades mínimas, mientras que las características adicionales se implementan como módulos externos que interactúan con el núcleo.

1.7. Cliente-Servidor

1.7.1. Modelo en el que una aplicación se divide entre clientes que solicitan recursos y un servidor que responde a esas solicitudes.

1.8. Arquitectura Peer To Peer

1.8.1. Sistema donde los nodos son iguales y pueden actuar tanto como clientes como servidores, compartiendo recursos de manera directa sin un servidor central.

1.9. Patrón Modelo-Vista-Controlador (MVC)

1.9.1. Modelo de diseño que organiza una aplicación en tres componentes: modelo (datos y lógica), vista (interfaz de usuario) y controlador (intermediario entre modelo y vista).

2. Patrones Arquitectonicos

2.1. Data Transfer Object (DTO)

2.1.1. Un DTO es un objeto utilizado para transportar datos entre diferentes capas de una aplicación o entre sistemas, sin incluir lógica de negocio. Su principal función es agrupar datos y optimizar el intercambio de información entre procesos.

2.2. Data Access Object (DAO)

2.2.1. Un DAO es un patrón de diseño que proporciona una interfaz abstracta para acceder a los datos de una fuente de datos (como una base de datos) y realizar operaciones CRUD (Crear, Leer, Actualizar, Eliminar).

2.3. Polling

2.3.1. El polling es una técnica en la que un sistema consulta regularmente a otro para obtener actualizaciones o verificar el estado de un recurso.

2.4. Webhook

2.4.1. Un webhook es un mecanismo de comunicación en el que un servidor envía automáticamente datos a otro sistema en respuesta a un evento específico, generalmente a través de una solicitud HTTP.

2.5. Load Balancer

2.5.1. Un balanceador de carga distribuye el tráfico o las solicitudes entrantes entre múltiples servidores o recursos para mejorar la disponibilidad y el rendimiento de un sistema.

2.6. Service Registry

2.6.1. Un Service Registry es un componente que almacena y mantiene información sobre los servicios disponibles dentro de una infraestructura, incluyendo detalles como la ubicación (dirección IP) de los servicios y su estado.

2.7. Service Discovery

2.7.1. Service Discovery es el proceso por el cual los servicios dentro de una red se localizan y se comunican entre sí, utilizando una base de datos o registro dinámico de servicios.

2.8. API Gateway

2.8.1. Un API Gateway es un componente que actúa como punto de entrada único para un conjunto de microservicios, manejando solicitudes, autenticación, enrutamiento, carga y respuestas de manera centralizada.

2.9. Access Token

2.9.1. Un token de acceso es una pieza de información que se utiliza para autenticar y autorizar a un usuario o una aplicación para que acceda a recursos o servicios de una API.

2.10. Single Sign-On (SSO)

2.10.1. El SSO es un sistema de autenticación que permite a un usuario iniciar sesión una vez y obtener acceso a múltiples aplicaciones sin necesidad de volver a autenticarse.

2.11. Store and Forward

2.11.1. "Store and Forward" es un patrón en el que los datos se almacenan temporalmente en un sistema intermedio (servidor) antes de ser enviados a su destino final.

2.12. Circuit Breaker

2.12.1. El patrón Circuit Breaker previene fallos en cascada dentro de un sistema distribuidos, deteniendo las llamadas a un servicio que está fallando y evitando que la carga aumente mientras se resuelve el problema.

2.13. Log Aggregation

2.13.1. La agregación de registros (Log Aggregation) consiste en recolectar y centralizar los registros (logs) generados por diferentes servicios o componentes de un sistema en un lugar único, para facilitar el análisis y monitoreo.

3. Patrones de Diseño

3.1. creacionales

3.1.1. Factory Method

3.1.1.1. técnica de programación orientada a objetos que define una interfaz para crear objetos en una superclase, pero permite que las subclases alteren el tipo de objetos que se crearán

3.1.2. Abstract Factory

3.1.2.1. Patrón que proporciona una interfaz para crear familias de objetos relacionados o dependientes sin especificar sus clases concretas.

3.1.3. Builder

3.1.3.1. Patrón de creación que separa la construcción de un objeto complejo de su representación, permitiendo crear diferentes representaciones del mismo objeto paso a paso

3.1.4. Prototype

3.1.4.1. Patrón que permite crear nuevos objetos clonando una instancia existente (el prototipo) en lugar de construir uno desde cero.

3.1.5. Singleton

3.1.5.1. Patrón de diseño que asegura que una clase solo tenga una instancia y proporciona un punto de acceso global a esa instancia.

3.2. Estructurales

3.2.1. Adapter

3.2.1.1. El patrón Adapter actúa como un intermediario que permite que dos clases con interfaces incompatibles puedan trabajar juntas.

3.2.2. Bridge

3.2.2.1. El patrón Bridge separa una abstracción (la funcionalidad de alto nivel) de su implementación (cómo se realiza) para que ambas puedan desarrollarse independientemente. Funciona como un "puente" entre estas dos partes.

3.2.3. Composite

3.2.3.1. El patrón Composite permite organizar objetos en una estructura de árbol para representar relaciones jerárquicas entre ellos. De esta forma, los objetos individuales y las composiciones (grupos de objetos) pueden tratarse de manera uniforme.

3.2.4. Facade

3.2.4.1. El patrón Facade proporciona una interfaz simplificada y unificada para un conjunto complejo de clases, bibliotecas o subsistemas. La fachada actúa como un punto de entrada único, ocultando los detalles internos del sistema.

3.2.5. Decorator

3.2.5.1. El patrón Decorator permite añadir funcionalidades a un objeto de forma dinámica, sin alterar su estructura original. Esto se logra envolviendo el objeto en una serie de "decoradores" que añaden o modifican su comportamiento.

3.2.6. Flyweight

3.2.6.1. El patrón Flyweight minimiza el uso de memoria compartiendo instancias de objetos que son idénticos o muy similares. Utiliza una estructura interna para diferenciar las partes compartidas y las únicas de cada instancia

3.2.7. Proxy

3.2.7.1. El patrón Proxy proporciona un sustituto o representante de un objeto real para controlar su acceso, añadir funcionalidad o mejorar el rendimiento. Puede actuar como intermediario o proteger al objeto real de accesos no autorizados o costosos.

3.3. Comportamiento

3.3.1. Chain of Responsibility

3.3.1.1. Este patrón permite que múltiples objetos tengan la oportunidad de procesar una solicitud, pasando esta secuencialmente a lo largo de una cadena de manejadores hasta que uno la gestione.

3.3.2. Command

3.3.2.1. El patrón Command encapsula una solicitud como un objeto, permitiendo parametrizar objetos con operaciones, deshacer comandos y mantener un historial de operaciones.

3.3.3. Iterator

3.3.3.1. Este patrón permite recorrer elementos de una colección sin exponer su representación interna, proporcionando una interfaz uniforme para recorrer diferentes estructuras de datos.

3.3.4. Mediator

3.3.4.1. El patrón Mediator define un objeto que centraliza la comunicación entre múltiples componentes, evitando referencias directas entre ellos y reduciendo el acoplamiento.

3.3.5. Memento

3.3.5.1. El patrón Memento permite capturar y restaurar el estado interno de unob objeto sin violar su encapsulamiento, útil para implementar funcionalidades de deshacer y rehacer.

3.3.6. Observer

3.3.6.1. El patrón Observer establece una relación de "suscripción" entre objetos, donde un objeto (sujeto) notifica a otros (observadores) sobre cambios en su estado.

3.3.7. State

3.3.7.1. El patrón State permite que un objeto cambie su comportamiento según su estado interno, pareciendo que cambia de clase en tiempo de ejecución.

3.3.8. Strategy

3.3.8.1. Este patrón permite definir un conjunto de algoritmos intercambiables y encapsularlos en clases separadas, permitiendo que un cliente elija dinámicamente cuál usar.

3.3.9. Template Method

3.3.9.1. El patrón Template Method define el esqueleto de un algoritmo en una clase base y permite que las subclases implementen o modifiquen ciertos pasos sin cambiar la estructura general.

3.3.10. Visitor

3.3.10.1. El patrón Visitor permite añadir nuevas operaciones a una estructura de objetos sin modificar las clases de esos objetos, utilizando una clase externa (visitante) que define las operaciones.