Universidad Cristiana Evangélica

Nuevo Milenio

Asignatura: Laboratorio de Programación RAD

Catedrático: Leonel Ivan Hércules Morel

Tema: Patrones de diseño y arquitectura software

Alumna: Rosmary Yamileth Villanueva Rodas

N° de cuenta: 120450022

Sede: Santa Rosa de Copan

Fecha: 24/2/2024
 PATRONES DE DISEÑO Y ARQUITECTURA SOFTWARE
Patrones de diseño software
Singleton (Singleton):
El patrón Singleton es uno de los patrones de diseño más simples y
ampliamente utilizados en el desarrollo de software.
Características:
 Única Instancia: Garantiza que una clase tenga solo una instancia y
proporciona un punto de acceso global a esa instancia.
 Constructor Privado: El constructor de la clase Singleton es privado para
evitar que se creen instancias adicionales fuera de la clase.
 Método de Acceso Estático: Proporciona un método estático que
devuelve la única instancia de la clase.
Ventajas:
 Control de Acceso: Proporciona un punto de acceso global controlado a
una única instancia, lo que evita la creación de múltiples instancias de la
clase y garantiza la coherencia del estado.
 Ahorro de Recursos: Reduce el uso de recursos al limitar la creación de
una sola instancia, especialmente útil para clases que requieren una
inicialización costosa.
 Facilidad de Acceso: Permite acceder a la instancia única desde
cualquier parte del código sin necesidad de pasar la instancia como
parámetro o utilizar variables globales.
Desventajas:
 Acoplamiento Fuerte: Puede introducir acoplamiento fuerte en el código,
ya que el Singleton se convierte en un punto de acceso global que
puede ser accedido desde cualquier lugar del código.
 Dificultad en Pruebas Unitarias: Puede dificultar las pruebas unitarias, ya
que el Singleton puede introducir dependencias ocultas en el código que
complican la creación de mocks o stubs.
 Potencial para Problemas de Concurrencia: Si no se implementa
correctamente, el Singleton puede introducir problemas de concurrencia
en aplicaciones multi-hilo.
Diseño:
 Constructor Privado: Oculta el constructor de la clase para evitar la
creación de instancias externas.
 Instancia Estática: Declara una variable estática privada de la misma
clase dentro de la clase.
 Método Estático de Acceso: Proporciona un método estático público que
devuelva la instancia única. Si la instancia aún no está creada, crea una
nueva; de lo contrario, devuelve la instancia existente.
Factory Method (Método de Fábrica):
Es un patrón de diseño creacional que se utiliza para definir una interfaz para
crear un objeto, pero permite a las subclases decidir qué clase instanciar.
Características:
 Interfaz Común: Define una interfaz común para la creación de objetos,
pero delega la responsabilidad de la creación a las subclases.
 Método de Fábrica: Proporciona un método de fábrica en la clase base
que las subclases implementan para crear objetos.
 Desacoplamiento: Permite desacoplar el código que utiliza los objetos de
su implementación específica, lo que facilita la extensión y la adición de
nuevas implementaciones.
Ventajas:
 Flexibilidad: Permite agregar nuevas variantes de productos (objetos) sin
modificar el código existente, simplemente creando nuevas subclases y
sus correspondientes fábricas.
 Desacoplamiento: Desacopla el código que utiliza los objetos de su
creación, lo que facilita la gestión de cambios y extensiones en el
código.
 Reusabilidad: Facilita la reutilización del código al permitir la creación de
objetos a través de una interfaz común en lugar de instanciar clases
directamente.
Desventajas:
  Complejidad Adicional: Introduce una capa adicional de abstracción y
complejidad en el código, lo que puede aumentar la dificultad de
comprensión para algunos desarrolladores.
 Sobrecarga de Clases: Puede resultar en la creación de múltiples
subclases y fábricas, lo que aumenta la cantidad de clases en el sistema
y la complejidad de su gestión.
Diseño:
 Interfaz o Clase Abstracta: Define una interfaz común o una clase
abstracta que declara el método de fábrica abstracto.
 Clases de Productos: Crea clases que implementen la interfaz o
extiendan la clase abstracta para representar los productos que la
fábrica puede crear.
 Clase de Fábrica: Implementa una clase de fábrica que contiene el
método de fábrica para crear objetos. Esta clase puede ser una clase
concreta o una clase abstracta que puede tener múltiples subclases.
 Implementaciones de Fábrica: Crea subclases de la clase de fábrica
para proporcionar implementaciones específicas del método de fábrica
que crean instancias de diferentes tipos de productos.

Observer (Observador):
Es un patrón de diseño de comportamiento que establece una relación de uno
a muchos entre objetos, de modo que cuando un objeto cambia de estado,
todos sus dependientes son notificados y actualizados automáticamente.
Características:
  Relación Uno a Muchos: Establece una relación donde un objeto,
denominado sujeto u observable, mantiene una lista de dependientes,
denominados observadores.
 Notificación Automática: Cuando el sujeto cambia de estado, notifica
automáticamente a todos sus observadores, permitiéndoles actualizar su
estado o realizar otras acciones.
 Desacoplamiento: Desacopla los objetos observadores del sujeto,
permitiendo que los observadores se registren y se eliminen
dinámicamente.
Ventajas:
 Desacoplamiento: Permite que el sujeto y los observadores operen de
forma independiente, lo que facilita la modificación y la reutilización del
código.
 Flexibilidad: Permite que un sujeto tenga un número variable de
observadores y que los observadores sean añadidos o eliminados
dinámicamente en tiempo de ejecución.
 Actualización Automática: Garantiza que los observadores se actualicen
automáticamente cuando el estado del sujeto cambia, lo que reduce la
necesidad de lógica adicional de notificación.
Desventajas:
 Potencial de Fugas de Memoria: Si los observadores no se gestionan
adecuadamente, puede haber referencias circulares que impidan la
liberación de memoria, lo que podría provocar fugas de memoria.
 Notificaciones Excesivas: Si el sujeto realiza cambios de estado
frecuentes, los observadores podrían recibir notificaciones excesivas, lo
que podría afectar al rendimiento.
Diseño:
 Interfaz Sujeto: Define una interfaz que permite a los observadores
registrarse, des registrarse y recibir notificaciones del sujeto.
 Clase Sujeto Concreto: Implementa la interfaz del sujeto y mantiene una
lista de observadores. Proporciona métodos para añadir, eliminar y
notificar observadores.
 Interfaz Observador: Define una interfaz que permite al sujeto notificar a
los observadores cuando cambia de estado.
 Clases Observadoras Concretas: Implementan la interfaz del observador
y definen cómo responder a las notificaciones del sujeto.
Decorator (Decorador):
Es un patrón de diseño estructural que permite agregar funcionalidad a objetos
individuales de manera dinámica y transparente, sin afectar a otros objetos del
mismo tipo.
Características:
 Extensión Dinámica: Permite extender la funcionalidad de un objeto sin
modificar su estructura básica.
 Composición: Utiliza la composición en lugar de la herencia para agregar
nuevas funcionalidades a los objetos.
 Transparencia: El cliente no necesita conocer la estructura interna del
objeto decorado, ya que la decoración se realiza de manera
transparente.
Ventajas:
 Flexibilidad: Permite agregar o quitar responsabilidades de forma
dinámica durante el tiempo de ejecución.
 Desacoplamiento: El patrón permite que las clases se mantengan
independientes entre sí, ya que la funcionalidad se agrega a través de
objetos decoradores independientes.
 Reutilización de Código: Las clases decoradoras y los componentes
básicos pueden reutilizarse de manera independiente, lo que aumenta el
modularidad y la reutilización del código.
Desventajas:
  Posible Sobrecarga: El uso excesivo de decoradores puede introducir
una sobrecarga de complejidad y rendimiento debido a la necesidad de
gestionar múltiples capas de objetos decoradores.
 Dificultad de Comprensión: A veces, puede resultar difícil comprender la
funcionalidad completa de un objeto decorado, ya que puede estar
compuesta por múltiples capas de decoradores.
Diseño:
 Interfaz Componente: Define una interfaz común para los componentes
básicos y los decoradores.
 Componente Concreto: Implementa la interfaz del componente para
representar el objeto base al que se agregará funcionalidad.
 Decorador Abstracto: Define una clase abstracta que implementa la
interfaz del componente y contiene una referencia a un objeto del mismo
tipo. Esta clase actúa como la base para todos los decoradores
concretos.
 Decorador Concreto: Extiende el decorador abstracto e implementa la
funcionalidad adicional que se agregará al componente base.
Strategy (Estrategia):
Es un patrón de diseño de comportamiento que permite definir una familia de
algoritmos, encapsular cada uno de ellos y hacer que sean intercambiables.
Características:
Familia de Algoritmos: Define una serie de algoritmos encapsulados que
realizan tareas similares, pero de formas diferentes.
Interfaz Común: Define una interfaz común que permite que los
algoritmos sean intercambiables y utilizados de manera transparente por
el cliente.
Desacoplamiento: Permite que los algoritmos varíen
independientemente de los clientes que los utilizan, lo que facilita la
extensión y la modificación del código.
Ventajas:
Flexibilidad: Permite intercambiar fácilmente diferentes algoritmos en
tiempo de ejecución sin afectar al código cliente.
Reutilización de Código: Facilita la reutilización de algoritmos y
componentes de código al encapsularlos en clases separadas.
Desacoplamiento: Desacopla el código que utiliza los algoritmos de su
implementación específica, lo que facilita la gestión de cambios y
extensiones en el código.
Desventajas:
Complejidad Adicional: Introduce una capa adicional de abstracción y
complejidad en el código, lo que puede aumentar la dificultad de
comprensión para algunos desarrolladores.
Número de Clases: Puede resultar en la creación de un gran número de
clases si hay una gran variedad de algoritmos y estrategias diferentes.
Diseño:
Interfaz Estrategia: Define una interfaz común para todos los algoritmos,
especificando un método que ejecuta la acción.
Clases de Estrategia Concreta: Implementa la interfaz de estrategia para
cada algoritmo específico.
Contexto: Contiene una referencia a un objeto de estrategia y
proporciona un método para cambiar el objeto de estrategia en tiempo
de ejecución.
Patrones de Arquitectura de Software
Arquitectura Monolítica:
Es un enfoque de diseño de software en el que todas las funcionalidades de
una aplicación se desarrollan y se despliegan como un solo sistema,
típicamente en un solo código base y un solo proceso de ejecución.
Características:
 Implementación Única: Todas las funcionalidades de la aplicación están
integradas en un único código base y un único proceso de ejecución.
 Acoplamiento Fuerte: Los componentes de la aplicación están
estrechamente acoplados, lo que significa que los cambios en un
componente pueden afectar a otros componentes.
 Despliegue Monolítico: La aplicación se despliega como una sola unidad
en un entorno de ejecución, como un servidor de aplicaciones.
Ventajas:
 Simplicidad: La arquitectura monolítica es relativamente simple de
entender y de desarrollar, ya que todas las funcionalidades están
contenidas en un único sistema.
 Facilidad de Despliegue: Al ser una sola unidad, el despliegue de una
aplicación monolítica es más sencillo en comparación con arquitecturas
distribuidas.
 Facilidad de Depuración: Depurar una aplicación monolítica puede ser
más sencillo, ya que todos los componentes están en un solo lugar.
Desventajas:
 Dificultad para Escalar: Escalar una aplicación monolítica puede ser
difícil, ya que toda la aplicación debe ser escalada en su conjunto,
incluso si solo una parte de ella experimenta una carga alta.
 Acoplamiento Fuerte: El acoplamiento fuerte entre los componentes
puede hacer que la aplicación sea más difícil de mantener y de modificar
a medida que crece en tamaño y complejidad.
 Limitaciones Tecnológicas: La elección de tecnologías está más
limitada, ya que toda la aplicación debe utilizar la misma pila tecnológica.
Diseño:
 Capa de Presentación: Interfaz de usuario y lógica de presentación.
 Capa de Negocio: Lógica de negocio y procesamiento de datos.
 Capa de Acceso a Datos: Acceso a la base de datos u otros sistemas de
almacenamiento.
Arquitectura de Microservicios:
Es un enfoque de diseño de software en el que una aplicación se descompone
en una colección de servicios pequeños e independientes, cada uno
ejecutándose en su propio proceso y comunicándose entre sí a través de
mecanismos ligeros, como HTTP o mensajes.
Características:
o Descomposición en Servicios: La aplicación se divide en una serie de
servicios independientes, cada uno responsable de una función
específica de negocio.
o Despliegue Independiente: Cada servicio se puede implementar y
escalar de forma independiente, lo que permite una mayor flexibilidad y
eficiencia operativa.
o Comunicación Basada en Protocolos Ligeros: Los servicios se
comunican entre sí a través de protocolos ligeros, como HTTP o
mensajes, lo que facilita la integración y la interoperabilidad.
Ventajas:
o Escalabilidad: Permite escalar servicios individualmente en función de la
carga de trabajo específica que enfrentan, lo que mejora la eficiencia y
reduce los costos.
o Resiliencia: Al ser servicios independientes, un fallo en un servicio no
afecta a los demás, lo que mejora la resiliencia y la tolerancia a fallos del
sistema en su conjunto.
o Facilidad de Desarrollo: Los equipos pueden desarrollar, probar y
desplegar servicios de forma independiente, lo que agiliza el proceso de
desarrollo y mejora la velocidad de entrega.
Desventajas:
 o Complejidad Operativa: La gestión de un gran número de servicios
puede introducir complejidad operativa, incluyendo la gestión de la
comunicación entre servicios, la monitorización y el descubrimiento de
servicios.
o Consistencia de Datos: Mantener la consistencia de los datos entre
servicios puede ser un desafío, ya que cada servicio puede tener su
propia base de datos y modelo de datos.
o Pruebas y Depuración: Las pruebas y la depuración pueden ser más
complejas en comparación con una arquitectura monolítica, ya que
implican múltiples servicios que se comunican entre sí.
Diseño:
En un diseño típico de arquitectura de microservicios, cada servicio se
desarrolla, despliega y escala de forma independiente. Cada servicio suele
estar enfocado en una función de negocio específica y puede tener su propia
base de datos.
La comunicación entre servicios se realiza generalmente a través de protocolos
ligeros, como HTTP/REST o mensajería basada en colas. Los servicios pueden
exponer una API para que otros servicios puedan consumirlos, lo que permite
una fácil integración y flexibilidad.
Es común utilizar contenedores (como Docker) y herramientas de orquestación
de contenedores (como Kubernetes) para gestionar y desplegar los servicios
de manera eficiente. Además, se pueden utilizar patrones de diseño como
Circuit Breaker y Service Discovery para mejorar la resiliencia y la escalabilidad
del sistema.
La arquitectura de microservicios es especialmente adecuada para
aplicaciones grandes y complejas que requieren escalabilidad, flexibilidad y
mantenibilidad a largo plazo. Sin embargo, también introduce desafíos
adicionales en términos de gestión y operaciones, que deben abordarse
cuidadosamente para obtener los beneficios completos de esta arquitectura.
Arquitectura Orientada a Servicios (SOA):
Es un enfoque de diseño de software en el que los componentes de una
aplicación se organizan como servicios independientes que se comunican a
través de estándares de comunicación, como SOAP (Simple Object Access
Protocol) o REST (Representational State Transfer).
Características:
 Servicios Independientes: Los componentes de la aplicación se
encapsulan como servicios independientes, cada uno con su propia
lógica de negocio y datos.
 Interoperabilidad: Los servicios se comunican a través de estándares de
comunicación interoperables, lo que permite la integración fácil entre
sistemas heterogéneos.
  Reutilización: Los servicios pueden ser reutilizados en diferentes
contextos y por diferentes aplicaciones, lo que mejora la eficiencia y
reduce la duplicación de esfuerzos.
Ventajas:
 Reutilización de Servicios: Permite reutilizar los servicios existentes en
diferentes aplicaciones y contextos, lo que mejora la eficiencia y reduce
el tiempo de desarrollo.
 Interoperabilidad: Facilita la integración entre sistemas heterogéneos al
utilizar estándares de comunicación interoperables, como SOAP y
REST.
 Flexibilidad: Permite a las organizaciones adaptarse rápidamente a los
cambios empresariales al desacoplar la lógica de negocio en servicios
independientes.
Desventajas:
 Complejidad: La implementación de una arquitectura SOA puede ser
compleja, especialmente al gestionar la interoperabilidad entre sistemas
y la gestión de servicios.
 Desempeño: La comunicación entre servicios a través de la red puede
introducir latencia y afectar al rendimiento, especialmente en
aplicaciones de alto rendimiento.
 Gestión de Versiones: La gestión de versiones de servicios puede ser un
desafío, especialmente cuando se utilizan en múltiples aplicaciones y
contextos.
Diseño:
En un diseño típico de arquitectura SOA, los componentes de la aplicación se
organizan como servicios independientes, cada uno con su propia interfaz y
lógica de negocio. Los servicios suelen exponer una interfaz estándar, como
una API web, que permite a otras aplicaciones y servicios consumirlos.
La comunicación entre servicios se realiza generalmente a través de protocolos
estándar como SOAP o REST, utilizando tecnologías como HTTP, XML o
JSON para el intercambio de datos. Los servicios pueden ser implementados
utilizando diferentes tecnologías y plataformas, lo que permite una mayor
flexibilidad y diversidad en el desarrollo de la aplicación.
Es común utilizar un Registro de Servicios (Service Registry) para gestionar y
descubrir servicios disponibles en la arquitectura SOA. Además, se pueden
utilizar patrones de diseño como Gateway, Orquestación de Servicios y
Coreografía de Servicios para facilitar la comunicación y coordinación entre
servicios.
La arquitectura SOA es especialmente adecuada para entornos empresariales
complejos que requieren integración entre sistemas heterogéneos y flexibilidad
para adaptarse a los cambios empresariales. Sin embargo, también introduce
desafíos adicionales en términos de gestión y complejidad, que deben ser
abordados cuidadosamente para obtener los beneficios completos de esta
arquitectura.
Arquitectura de Capas:
Es un enfoque de diseño de software que organiza una aplicación en una serie
de capas o niveles lógicos, donde cada capa tiene una responsabilidad
específica.
Características:
 Separación de Responsabilidades: Cada capa se encarga de una parte
específica de la funcionalidad de la aplicación, lo que facilita la
comprensión y la mantenibilidad del sistema.
 Desacoplamiento: Las capas están diseñadas para ser independientes
entre sí, lo que permite cambios en una capa sin afectar a las demás.
 Modularidad: La aplicación se divide en módulos o componentes lógicos,
lo que facilita la reutilización y la extensibilidad del código.
Ventajas:
 Separación de Preocupaciones: La arquitectura de capas facilita la
separación de preocupaciones al organizar la aplicación en partes
lógicas bien definidas, como la presentación, la lógica de negocio y el
acceso a datos.
 Reutilización de Componentes: Los componentes en cada capa pueden
ser reutilizados en diferentes partes de la aplicación o en otras
aplicaciones, lo que mejora la eficiencia del desarrollo.
 Facilidad de Mantenimiento: La estructura modular de la arquitectura de
capas facilita la identificación y corrección de errores, así como la
incorporación de nuevas funcionalidades.
Desventajas:
 Acoplamiento entre Capas: Si las capas están demasiado acopladas, los
cambios en una capa pueden afectar a otras capas, lo que reduce la
flexibilidad y la capacidad de mantenimiento del sistema.
 Posible Sobrecarga de Comunicación: La comunicación entre capas
puede introducir sobrecarga, especialmente en aplicaciones distribuidas,
lo que puede afectar al rendimiento.
 Complejidad Potencial: La arquitectura de capas puede introducir una
complejidad adicional en el diseño y la implementación del sistema,
especialmente en aplicaciones grandes y complejas.
Diseño:
 Capa de Presentación: Se encarga de la interfaz de usuario y la
interacción con el usuario final.
 Capa de Lógica de Negocio: Contiene la lógica de negocio y las reglas
de negocio de la aplicación.
  Capa de Acceso a Datos: Se encarga de acceder y manipular los datos
almacenados, como bases de datos o servicios externos.
Arquitectura Hexagonal (Puertos y Adaptadores):
Características:
 Desacoplamiento: La Arquitectura Hexagonal promueve el
desacoplamiento de la lógica de negocio de los detalles de
implementación externos, como la interfaz de usuario y las bases de
datos.
 Centrado en el Dominio: Se centra en el dominio del negocio, separando
las preocupaciones relacionadas con la lógica de negocio de las
tecnologías específicas de implementación.
 Capas Independientes: Se organiza en capas independientes, con el
núcleo del dominio en el centro y adaptadores en el exterior para
interactuar con elementos externos.
Ventajas:
 Flexibilidad: Permite cambios en los componentes externos, como la
interfaz de usuario o las bases de datos, sin afectar al núcleo de la
lógica de negocio.
 Pruebas Facilitadas: Facilita las pruebas unitarias y de integración, ya
que el núcleo de la lógica de negocio puede probarse de forma
independiente de los adaptadores externos.
 Desacoplamiento: El desacoplamiento entre las capas facilita la
reutilización del código y la evolución independiente de cada
componente.
Desventajas:
 Complejidad Agregada: La introducción de múltiples capas y
adaptadores puede aumentar la complejidad del sistema en
comparación con una arquitectura monolítica más simple.
 Costo de Desarrollo: El diseño y la implementación de una arquitectura
hexagonal pueden requerir más esfuerzo inicial en comparación con
enfoques más simples.
 Posible Sobrecarga: La introducción de adaptadores adicionales puede
introducir cierta sobrecarga en el rendimiento y el consumo de recursos.
Diseño:
En el diseño de la Arquitectura Hexagonal, se organiza el sistema alrededor del
núcleo del dominio (también conocido como hexágono). El núcleo del dominio
contiene toda la lógica de negocio y está completamente desacoplado de los
elementos externos.
Los adaptadores se utilizan para conectar el núcleo del dominio con elementos
externos, como la interfaz de usuario, las bases de datos, servicios externos,
etc. Estos adaptadores traducen las llamadas desde y hacia el núcleo del
dominio en un formato que sea comprensible para el elemento externo.
El diseño típico de la Arquitectura Hexagonal implica la siguiente estructura:
 Núcleo del Dominio: Contiene toda la lógica de negocio y las reglas del
dominio.
 Adaptadores de Entrada: Convierten las solicitudes de entrada del
usuario en llamadas al núcleo del dominio.
 Adaptadores de Salida: Convierten las respuestas del núcleo del
dominio en un formato adecuado para los elementos externos, como
bases de datos o servicios externos.
Este enfoque permite que el núcleo del dominio se mantenga puro y sin
dependencias externas, lo que facilita las pruebas y la evolución independiente
del resto del sistema. Además, proporciona una mayor flexibilidad y
adaptabilidad a los cambios en los requisitos y tecnologías externas.
CUADRO COMPARATIVO

Nombre Características Ventajas Desventajas Diseño

Singleton Única Instancia Control de Acoplamiento Constructor
(Singleton): Acceso Fuerte Privado
Constructor
Privado Ahorro de Dificultad en Instancia Estática
Recursos Pruebas
Método de Unitarias Método Estático
Acceso Estático Facilidad de de Acceso
Acceso Potencial para
Problemas de
Concurrencia
El patrón Interfaz Común Flexibilidad Complejidad Interfaz o Clase
Factory Adicional Abstracta
Method Método de Desacoplamiento
(Método de Fábrica Sobrecarga de Clases de
Fábrica) Reusabilidad Clases Productos
Desacoplamiento
Clase de Fábrica

Implementaciones
de Fábrica
User Relación Uno a Desacoplamiento Potencial de Interfaz Sujeto
Observer Muchos Fugas de
(Observador) Flexibilidad Memoria Clase Sujeto
Notificación Concreto
Automática Actualización Notificaciones
Automática Excesivas Interfaz
Desacoplamiento Observador
Decorator Extensión Flexibilidad Posible Interfaz
(Decorador) Dinámica Sobrecarga Componente
Desacoplamiento
Composición Dificultad de Componente
Reutilización de Comprensión Concreto
Transparencia Código
Decorador
Abstracto

Decorador
Concreto
Strategy Familia de Flexibilidad Complejidad Interfaz Estrategia
(Estrategia) Algoritmos Adicional
Reutilización de Clases de
Interfaz Común Código Número de Estrategia
Clases Concreta
Desacoplamiento Desacoplamiento
Contexto
Arquitectura Implementación Simplicidad Dificultad para Capa de
Monolítica Única Escalar Presentación
Facilidad de
Acoplamiento Despliegue Acoplamiento Capa de Negocio
Fuerte Fuerte
Facilidad de Capa de Acceso a
Despliegue Depuración Limitaciones Datos
Monolítico Tecnológicas
Arquitectura Descomposición Escalabilidad Complejidad En un diseño
de en Servicios Operativa típico de
Microservicios Resiliencia arquitectura de
Despliegue Consistencia microservicios,
Independiente Facilidad de de Datos cada servicio se
Desarrollo desarrolla,
Comunicación Pruebas y despliega y escala
Basada en Depuración de forma
Protocolos Ligeros independiente.
La Servicios Reutilización de Complejidad En un diseño
Arquitectura Independientes Servicios típico de
Orientada a Desempeño arquitectura SOA,
Servicios Interoperabilidad Interoperabilidad los componentes
(SOA) Gestión de de la aplicación se
Reutilización Flexibilidad Versiones organizan como
servicios
independientes,
cada uno con su
propia interfaz y
lógica de negocio.
Arquitectura Separación de Separación de Acoplamiento Capa de
de Capas Responsabilidades Preocupaciones entre Capas Presentación

Desacoplamiento Reutilización de Capa de Lógica de

Componentes Negocio
 Modularidad Facilidad de Posible Capa de Acceso a
Mantenimiento Sobrecarga de Datos
Comunicación

Complejidad
Potencial
Arquitectura Desacoplamiento Flexibilidad Complejidad En el diseño de la
Hexagonal Agregada Arquitectura
(Puertos y Centrado en el Pruebas Hexagonal, se
Adaptadores) Dominio Facilitadas Costo de organiza el
Desarrollo sistema alrededor
Capas Desacoplamiento del núcleo del
Independientes Posible dominio (también
Sobrecarga conocido como
hexágono). El
núcleo del
dominio contiene
toda la lógica de
negocio y está
completamente
desacoplado de
los elementos
externos.