lunes, 20 de mayo de 2013

Arquitecturas para Domain-Driven Design - Parte VI

Capa de Persistencia.
Esta capa sirve como puente entre la lógica de negocio (servicios y entidades) y el proveedor de datos. Históricamente es una capa que se usa para encapsular las especificaciones del proveedor de datos. Aunque esto sigue siendo, en cierta manera, así, gracias a nuevas tecnologías como los ORM (los cuales ya realizan una abstracción del proveedor de datos) su propósito puede llegar a ser el de abstraerse de los detalles de implementación del ORM y proporcionar mecanismos para la satisfacción de consultas utilizando el ORM escogido.



La capa de Acceso a Datos debe proporcionar mecanismos -indepedientemente de la tecnología que se esté usando para la persistencia- que permitan realizar las consultas a base de datos de modo que se devuelvan agregados raíces, agregar entidades nuevas a la Persistencia, sacar entidades de la Persistencia, borrar entidades y almacenar en Persistencia los cambios que se hayan realizado en las entidades.

En el post sobre la implementación de la capa daré más detalles para que así se llegue a una comprensión total sobre las responsabilidades de esta capa y como llevarlas a cabo.

Colaboración entre capas.

Una vez definidas las capas básicas de la arquitectura y sus responsabilidades nos podemos hacer una idea de como se coordinan para realizar una operación.

Vista

Partimos de la Vista, su modelo de Vista, sus controladores o presentadores y los comandos de acción; todo esto se utiliza para mostrar datos al usuario, recopilar los input del mismo, realizar todo el feedback visual (mensajes de error, mensajes informativos, mensajes de espera, de petición de información contextual, control de wizards, validación de entradas, etc) y montar la infraestructura de comandos para encapsular toda la información necesaria para la acción requerida.

Aplicación

Con la información del comando se llamaría al método de la capa de Aplicación que realiza la acción. Este método se encarga de la autorización de seguridad, logs y trazas de aplicación, así como de controlar las transacciones necesarias, recuperar las entidades de dominio implicadas desde los repositorios, coordinar las llamadas a los servios de dominio (pasándole las entidades para que trabajen con ellas), llamar a las validaciones de los estados de las entidades y cerrar la transacción. Es importante remarcar que cualquier excepción con la que no podamos o no debamos lidiar en nuestro dominio, tiene que fluir hasta la capa de Aplicación. Ésta se encargará de realizar los logs y trazas pertinentes y de pasar al controlador o presentador de la Vista un código de error, o bien de relanzar alguna excepción personalizada (relevante al contexto de la acción). El controlador/presentador se encargará de indicarle a la Vista que muestre un error a través de los mecanismos de notificación de errores que se hayan creado para el feedback del usuario.

Persistencia

Esta capa es llamada por la capa de Aplicación para recuperar los agregados raíz con los que vamos a trabajar para realizar la acción. La capa de Aplicación sabe que información debe recuperar de la Persistencia, y la Persistencia debe ofrecer mecanismos para recuperar esta información. Después de modificar las entidades de dominio esta capa se encarga de guardar o desacer los cambios en el motor de Persistencia.

Dominio

Esta capa es llamada por la capa de Aplicación después de haber utilizado la capa de Persistencia para recuperar las entidades con las que vamos a trabajar. Es la encargada de realizar las operaciones que representan el negocio en el sistema. Normalmente implica un cambio de estado en una o varias entidades raíces Esta capa será la encargada de aplicar las invariantes del sistema, cuya responsabilidad no sea propia de una entidad raíz, y de llamar a los métodos de las entidades para que apliquen sus propias reglas. En caso de que una acción implique más de una entidad, esta capa será la encargada de la coordinación de este proceso.

Infraestructura

¿Necesita la aplicación acceder al sistema de ficheros locales? ¿Debe escribir o leer del registro del SO? Todas estas cosas y muchas más de este estilo recaerán en la capa de Infraestructura. Casi cualquier sistema externo al que tengamos que acceder debe tener su punto de entrada en la capa de Infraestructura, y preferentemente se debe exponer a través de un patrón fachada, una versión simplificada de este sistema que nos permita hacer lo estrictamente necesario para las operaciones que necesitamos. Esta capa debe ser consumida por la capa de Aplicación, y la información que retorne pasada a la capa de Dominio en caso de esta información sea necesaria para tomar alguna decisión relevante al negocio del sistema.

No hay comentarios:

Publicar un comentario