# data[].attributes.body
QUE ES LA ARQUITECTURA DE MICROSERVICIOS ?

Es un método de desarrollo de aplicaciones software que funciona como un conjunto de pequeños servicios que se ejecutan de manera independiente y autónoma, proporcionando una funcionalidad de negocio completa. En ella, cada microservicio es un código que puede estar en un lenguaje de programación diferente, y que desempeña una función específica. Los microservicios se comunican entre sí a través de APIs, y cuentan con sistemas de almacenamiento propios, lo que evita la sobrecarga y caída de la aplicación.

CAPAS DE LA ARQUITECTURA

Dominio

contiene únicamente el código relativo a entidades, value objects, interfaces de servicios… básicamente los contratos que deberá de cumplir el código. En otros contextos lo podemos relacionar con el core de una aplicación.

Apilcacion

Son las implementaciones de los contratos definidos en Dominio. Por ejemplo, si tenemos una interfaz del servicio de repositorio UserRepository, en infraestructura podemos tener distintas implementaciones del mismo, por ejemplo RedisUserRepository, DoctrineUserRepository, o ElasticSearchUserRepository por citar algunos ejemplos.

Infraestructura

contiene la implementación de casos de uso de nuestra aplicación, como por ejemplo Registrar un Usuario o Publicar un Post. Esta capa solo conoce los contratos definidos en Dominio con lo que cualquier implementación de Infraestructura deberá de ser inyectada como una interfaz de Dominio. Así, para por ejemplo Registrar un usuario necesitaríamos un UserRepository, no importa qué implementación, ya que cualquiera de ellas cumplirá con el contrato y sabremos de qué métodos disponemos.

CQRS (Separacion de consultas de comando)

La idea básica es que las operaciones de un sistema se pueden dividir en dos categorías claramente diferenciadas:

Consultas (Queries). Devuelven un resultado sin cambiar el estado del sistema y no tienen efectos secundarios (side effects).

Comandos (Command). Cambian el estado de un sistema (y pueden tener side effects).

con CQRS se puede tener una base de datos para operaciones de lectura (queries) distinta de la de operaciones de escritura (commands), o distintos modelos de datos para las respuestas de las queries o las peticiones de los commands.

# data[].attributes.body
QUE ES LA ARQUITECTURA HEXAGONAL?

La arquitectura Hexagonal es un patrón de diseño de software que tiene como objetivo principal separar las responsabilidades de cada componente de un sistema. Esta arquitectura se basa en la idea de que las aplicaciones deben ser independientes de la tecnología subyacente y, por lo tanto, fácilmente intercambiables.

CAPAS DE LA ARQUITECTURA

Dominio

Conceptos que estan en nuestro contexto y reglas de negocio que vienen determinadas en exclusiva por nosotros

Apilcacion

Es donde viven los casos de uso de nuestra aplicacion

Infraestructura

En esta capa viviran las implementaciones de las interfaces que definiremos a nivel de dominio, para poder desacoplarnos de las dependencias externas.

PUERTOS Y ADAPTADORES

La Arquitectura Hexagonal también se denomina “Ports and adapters”. De hecho, en nuestra opinión este término es más acertado ya que tiene connotaciones más cercanas a lo que podríamos pensar al ver cómo queda el código, y no implica un número finito como sí lo hace la palabra hexágono. En ese sentido, podemos pensar que:

Los puertos son las interfaces definidas en la capa de dominio para desacoplarnos de nuestra infraestructura. Ejemplo: UserRepository.

Los adaptadores son las implementaciones posibles de esos puertos. Estas implementaciones traducirán esos contratos definidos en la interfaz a la lógica necesaria a ejecutar en base a un determinado proveedor. Ejemplo: MySqlUserRepository.

REGLA DE DEPENDENCIA

Esta regla nos dice que el código que viva en cada una de nuestras capas sólo deberá conocer las clases que se ubican en la capa inmediatamente siguiente. Entendemos el orden de las capas desde fuera hacia dentro del círculo: Infraestructura -> Aplicación -> Dominio.

Esta regla lo que nos proporciona es la posibilidad de cambiar elementos de nuestras capas más externas sin que las internas se vean afectadas. Por esto adquiere más sentido que los aspectos que más variabilidad tienen ya que no dependen de nosotros estén en la capa más externa (infraestructura).

# data[].attributes.body
1. CAPA DE INFRAESTRUCTURA DE PERSISTENCIA DE DATOS

Los componentes de persistencia de datos proporcionan acceso a datos que están hospedados dentro de las fronteras  nuestra base de datos principal, pero también datos expuestos fuera de las fronteras de nuestra base de datos , como Servicios Web de sistemas externos. Contiene, por lo tanto, componentes de tipo Repositorio que proporcionan la funcionalidad de acceder a los datos  o bien Agentes de Servicio que consumirán Servicios Web que expongan otros sistemas back-end externos. Adicionalmente, esta capa dispondrá normalmente de componentes/clases base con código reutilizable por todas las clases repositorio.

Patrones de la Capa persistencia de datos

Patron Repositorio

Este patrón, es uno de los más habituales hoy en día, sobre todo si pensamos en Domain Driven Design, puesto que nos permite de una forma sencilla, hacer que nuestras capas de datos sean „testables‟ y trabajar de una forma más simétrica a la orientación a objetos con nuestros modelos relaciones .

Active Record

Este patron podemos comprenderlo de manera mas simple como un objeto que transporta no solamente datos sino también el comportamiento. Es decir, un Active Record deposita la lógica de su persistencia dentro del propio dominio del objeto

Table Data Gateway

El patron Table Data Gateway  separa el propio transporte de datos de las operaciones sobre el mantenimiento de los mismos , al delegar en un intermediario o gateway todo el trabajo de interacción con la base de datos.

Data Mapper

El patrón Data Mapper tiene como objetivo separar las estructuras de los objetos de las estructuras de los modelos relacionales y realizar la transferencia de datos entre ambos. Con el uso de un Data Mapper, los objetos que consumen los componentes „DataMapper‟, son ignorantes del esquema presente en la base de datos y, por supuesto, no necesitan hacer uso de código SQL.

2. CAPA DE MODELO DE DOMINIO

Esta capa debe es responsable de representar conceptos de negocio, información sobre la situación de los procesos de negocio e implementación de las reglas del dominio. También debe contener los estados que reflejan la situación de los procesos de negocio, aun cuando los detalles técnicos de almacenamiento se delegan a las capas inferiores de infraestructura.

Patrones de la capa de modelo de dominio

Patrón Objeto-Valor

El patron de describe como objetos que son instanciados para representar elementos del diseño y que nos importan solo de forma temporal, tambien puede ser también un conjunto de otros valores o incluso de referencias a otras entidades. Por ejemplo, en una aplicación donde se genere una Ruta para ir de un punto a otro, dicha ruta sería un OBJETO-VALOR (porque sería una foto de puntos a pasar por dicha ruta, pero dicha ruta no tendrá identidad ni queremos persistirla, etc.), aun cuando internamente está referenciando a Entidades (Ciudades, Carreteras, etc.).

Patrón Aggregate

El agregado es un patrón de dominio que se utiliza para definir pertenencia y fronteras de objetos del modelo de dominio. El agregado se delimita por una frontera que separa los objetos internos de los objetos externos. Cada agregado tendrá un objeto raíz que será la entidad raíz y será el único objeto accesible, de forma inicial, desde el exterior. El objeto entidad raíz tendrá referencias a cualquiera de los objetos que componen el agregado, pero un objeto externo solo puede tener referencias al objeto-entidad raíz. Si dentro de la frontera del agregado hay otras entidades , la identidad de esos objetos-entidad es solo local y tienen solamente sentido perteneciendo a dicho agregado y no de forma aislada.

Patrón ESPECIFICACION

Este patron consiste en separar la sentencia de qué tipo de objetos deben ser seleccionados en una consulta del propio objeto que realiza la selección. El objeto 'Especificación' tendrá una responsabilidad clara y limitada que deberá estar separada y desacoplada del objeto de Dominio que lo usa.

3. CAPA DE APLICACIÓN

Esta Capa de Aplicación,  define las tareas que se supone debe hacer el software, como tal, lo cual normalmente está ligado finalmente a realizar llamadas a la Capa de Dominio e Infraestructura. Sin embargo, las tareas que sean exclusivas de la aplicación y no del Dominio son las tareas que debemos coordinar en esta capa.

patron Unit Of Work

El patrón de UNIT OF WORK encaja perfectamente con las transacciones, pues podemos hacer coincidir un UNIT OF WORK con una transacción, de forma que justo antes del commit de una transacción aplicaríamos con el UoW las diferentes operaciones, agrupadas todas de una vez, con lo que el rendimiento se optimiza y especialmente se minimizan los bloqueos en base de datos

El  funcionamiento del patron  UNIT OF WORK puede  consiste en que los Repositorios deleguen al UNIT OF WORK el trabajo de acceder al almacén de datos. Es decir, el UoW será el que realice efectivamente las llamadas al almacén (en bases de datos, comunicar al servidor de base de datos que ejecute sentencias SQL). El mayor beneficio de esta aproximación es que los mensajes que manda el UoW son transparentes al consumidor de los repositorios, puesto que los repositorios solamente le dicen al UoW operaciones que deberá hacer cuando decida aplicar la unidad de trabajo.

4. CAPA DE SERVICIOS DISTRIBUIDOS

La capa de servicios distribuidos es responsable de la comunicación y la integración entre distintos componentes y sistemas distribuidos en una aplicación, facilita la interacción y la colaboración entre los diferentes módulos de dominio y otros servicios externos, ya sea a través de redes locales o de conexiones remotas. Su objetivo principal es proporcionar una infraestructura que permita la interoperabilidad y la comunicación entre los distintos componentes distribuidos.

5. CAPA DE PRESENTACION

La capa de presentación se encarga de la interacción entre los usuarios y el sistema, mostrando la información y recopilando las acciones del usuario. Es la capa encargada de la interfaz de usuario y de presentar los datos y resultados al usuario final.

Patrón MVC (Modelo Vista Controlador)

El objetivo de este patron es separar el código responsable de la representación de los datos en pantalla, del código encargado de la ejecución de la lógica de negocio. Para ello el patrón divide la capa de presentación en tres tipos de objetos básicos: modelos, vistas y controladores. La utilidad del patrón reside en que describe los flujos de comunicación entre estos tres tipos de objetos.

Patrón MVP (Modelo Vista Presentador)

El objetivo de este patron es separar el modelo del dominio, la presentación y las acciones basadas en la interacción con el usuario en tres clases separadas. La vista le delega a su presenter toda la responsabilidad del manejo de los eventos del usuario. El presenter se encarga de actualizar el modelo cuando surge un evento en la vista, pero también es responsable de actualizar a la vista cuando el modelo le indica que ha cambiado. El modelo no conoce la existencia del presenter.  Por lo tanto, si el modelo cambia por acción de algún otro componente que no sea el presenter, debe disparar un evento para que el Presenter se entere.

Patrón MVVM (Model-View-ViewModel)

El objetivo de este patron es separar el Modelo (Model) y la Vista (View) introduciendo una capa abstracta entre ellos, un “Modelo de la Vista” ó “ViewModel”. La vista y el modelo de la Vista son instanciados normalmente por la aplicación contenedora. La vista guarda una referencia al ViewModel. El ViewModel expone comandos y entidades „observables‟ o enlazables a los que la Vista puede enlazarse. Las interacciones del usuario con la Vista dispararán comandos contra el ViewModel y de forma análoga, las actualizaciones en el ViewModel se propagarán a la Vista de forma automática mediante enlace de datos.

6. CAPAS DE INFRAESTRUCTURA TRANSVERSAL

La capa de infraestructura transversal se encarga de aspectos técnicos y de infraestructura que son necesarios para el funcionamiento de la aplicación, pero que no están directamente relacionados con el dominio o la lógica de negocio específica. Estos aspectos pueden incluir la persistencia de datos, la comunicación con servicios externos, la seguridad, la autenticación, la gestión de errores, la configuración, entre otros.