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

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 . 

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 

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.
 

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

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.). 

 

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. 

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. 

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.

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.

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. 

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.

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: 

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). 

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:

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.