Modelo C4 y Diagramas de Arquitectura

Diagrama de nivel superior que muestra la vista general del sistema y sus límites.

Componentes autónomos de un sistema, como bases de datos, servicios o aplicaciones.

Diagrama que describe los contenedores de un sistema, sus interacciones y estructura.

Diagrama que muestra el funcionamiento interno de un contenedor, incluyendo sus componentes y comunicación.

Un modelo de arquitectura de software que utiliza diagramas jerárquicos para visualizar el sistema.

Proporciona una estructura clara, facilita la comunicación, se centra en la esencia, es escalable y ayuda a la toma de decisiones.

Diagrama que proporciona una vista general del sistema, incluyendo diagramas de despliegue, servicios y componentes.

Un diagrama que proporciona información específica sobre el funcionamiento interno de un componente.

Diagramas más específicos que muestran la funcionalidad y jerarquía de la interacción entre servicios de una arquitectura de software.

Patrones que se enfocan en la composición de clases y objetos para crear estructuras más complejas y escalables.

Permite la comunicación entre interfaces o clases incompatibles convirtiendo una entrada en otra.

Separa una abstracción de su implementación, permitiendo un crecimiento independiente y optimizado.

Permite la composición de objetos en estructuras de árbol, tratándolos como objetos individuales.

Diagramas que muestran el flujo de la interacción entre objetos de un sistema.

Diagramas que describen la estructura estática de un sistema mostrando clases, atributos y métodos.

Agrega funcionalidades a objetos existentes, colocándolos dentro de objetos encapsulados que contienen esas funcionalidades, ofreciendo una alternativa a la herencia.

Proporciona una interfaz simplificada a un grupo de interfaces en un sistema, ocultando la complejidad a los clientes.

Crea objetos ligeros reutilizando partes compartidas. Reduce memoria al reutilizar objetos existentes.

Controla el acceso a un objeto original, permitiendo acciones antes o después de la solicitud al objeto original.

Guarda y restaura el estado previo de un objeto sin revelar su implementación.

Ejemplo de Fachada: un operador actúa como interfaz entre el cliente y los diferentes departamentos de la tienda.

Objeto que utiliza partes compartidas con otros objetos.

Ejemplo de Proxy: El sistema solicita un objeto al Factory, el cual crea un Proxy para controlar el objeto original, realizando acciones adicionales antes y después de ejecutarlo.

El patrón Singleton garantiza que una clase solo tenga una instancia y proporciona un punto de acceso global a ella.

El cliente solicita la instancia a través de un método estático. Si la instancia ya existe, se devuelve. De lo contrario, se crea una nueva.

Este método permite a los clientes obtener la instancia Singleton.

Almacena la única instancia de la clase Singleton.

Previene la creación de instancias directas de la clase Singleton.

Evita que varios hilos creen simultáneamente instancias del Singleton.

El Singleton puede definir operaciones específicas para su única instancia.

Una única instancia de una conexión de base de datos para todo el programa.

Un patrón de diseño que separa la construcción de un objeto complejo en pasos individuales, permitiendo crear diferentes representaciones del mismo objeto.

Un patrón de diseño que permite crear nuevos objetos a partir de un prototipo existente, sin tener que reescribir todo el código.

Un patrón de diseño que permite que una solicitud se procese por una cadena de objetos, pasando la solicitud al siguiente objeto en la cadena hasta que se encuentre un objeto que la maneje.

Un patrón de diseño que encapsula una solicitud como un objeto, permitiendo parametrizar clientes con diferentes solicitudes, programar o registrar solicitudes, y soportar operaciones deshacer.

Un patrón de diseño que proporciona una forma de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representación interna.

Un patrón de diseño que define una interfaz para crear objetos, pero permite a las subclases decidir qué tipo de objeto crear. Es ideal cuando una clase no puede predecir el tipo de objetos que debe crear.

Un patrón de diseño para crear familias de objetos relacionados sin especificar sus clases concretas. Garantiza que los objetos creados sean compatibles entre sí.

El patrón Factory Method define una creación de un objeto, pero la clase concreta del objeto que se creará dependerá de la subclase que implemente el método.

El patrón Factory Method es útil cuando una clase no puede predecir el tipo de objetos que debe crear.

Abstract Factory se usa para crear familias de objetos relacionados sin especificar sus clases concretas.

Abstract Factory se usa cuando una clase no puede predecir qué tipo de objetos de una familia debe crear.

Factory Method crea un solo tipo de objeto, mientras que Abstract Factory crea una familia de objetos relacionados.

Elija Factory Method cuando necesite crear objetos de un solo tipo, y Abstract Factory cuando necesite crear objetos de una familia de tipos relacionados, aunque no se necesite crear todos los tipos dentro de la familia.