Ing. Miguel Almeyda

Software Architect

MCTS, Dev Advisory Council VS

Módulos 12, 13

Arquitecturas N – Capas Orientadas al Dominio:

Creación de Capas

Arquitectura N-Capas con orientación

al dominio

Capa de Presentación Responsable de presentar información al usuario e

interpretar sus acciones.

Es recomendable subdividir los componentes en varias sub-capas y aplicando patrones de tipo MVC, MVP ó MVVM.

Sub capa de componentes visuales (vistas).

Componentes que formatean datos y controles visuales, reciben los datos del usuario.

Sub capa de controladores.

Ayuda a sincronizar y orquestar las acciones del usuario.

Impide que el flujo del proceso y la gestión del estado esté programado dentro del control.

Permite reutilizar dicha lógica desde otras vistas o interfaces.

Capa de Servicios Distribuidos

Ayuda a que una aplicación actúe como proveedor

de servicios para otras aplicaciones.

Normalmente se publica la lógica de negocio

mediante una capa de servicios Web.

Esta capa de servicios proporciona un medio de

acceso remoto basado en canales de comunicación

y mensajes de datos.

Esta capa debe ser lo más ligera posible y no debe

incluir ninguna lógica de negocio.

Capa de Aplicación Forma parte de la propuesta de Arquitecturas

Orientadas al Dominio.

Define los trabajos que la aplicación debe realizar y re-dirige a los objetos del dominio que son los que internamente deben resolver los problemas.

Esta capa no debe contener reglas del dominio o conocimiento de lógica de negocio.

Coordina las tareas necesarias para la aplicación.

Tampoco debe contener el estado que refleje la situación de la lógica de negocio.

Puede mantener estado del progreso de una tarea a ser mostrada al usuario.

Capa de Aplicación

Aspectos a considerar

Agrupa datos de diferentes entidades para ser enviadas de forma más eficiente por la capa superior de servicios (DTO).

Acciones que consolidan operaciones del Dominio.

Mantenimiento de estado relativos a la aplicación (no estados internos del dominio).

Coordinación de actividades entre el Dominio y algunos aspectos de infraestructura. Ejemplo: acción de transferencia bancaria y

notificación de correo a los interesados (esta acción no debe ser una lógica intrínseca del dominio)

El servicio de aplicación no se relaciona en nada con los servicios Web, que son para acceso remoto.

Capa del Dominio

Responsable de representar:

Conceptos del negocio.

Información de los procesos de negocio.

Implementación de las reglas del dominio.

Contiene los estados que reflejan la situación de los

procesos de negocio.

Aún cuando los detalles de persistencia de delegan a

la capa de infraestructura (repositorios, etc.)

Esta capa es el corazón del software.

Encapsulan toda la lógica de negocio relevante

(denominada lógica de dominio).

Capa del Dominio

Suele implementarse como:

Clases en el lenguaje seleccionado que implementan

la lógica del dominio en sus métodos.

Flujos de trabajo con tecnología especialmente

diseñada para implementar Workflows.

Sistemas dinámicos de reglas de negocio.

Esta capa tiene que ignorar completamente los

detalles de persistencia de datos.

Capa del Dominio

Elementos Disponibles

Entidades del dominio

Son entidades de datos desconectados.

Se utilizan para transferir estado entre las diferentes capas.

Es recomendable que contengan lógica de dominio relativo

a la entidad: validaciones, campos pre-calculados,

relaciones con otras entidades.

Servicios del dominio

Estos servicios son clases agrupadoras de

comportamientos y/o métodos con ejecución de lógica de

dominio.

Deben ser clases stateless.

Son clases que coordinen e inicien operaciones

compuestas.

Capa del Dominio

Elementos Disponibles

Contratos de Repositorios

Son las interfaces que indican cómo deben estar

construidos los repositorios.

Dichas interfaces son «agnósticas» de la tecnología.

Es importante que las entidades del dominio también

sean «agnósticas» de la tecnología.

Sub-capa de “Workflows de Negocio”

Procesos de negocio formados por cierto número de

pasos que deben ejecutarse de acuerdo a unas reglas

concretas.

Capa de Infraestructura de Acceso a

Datos

Proporciona la capacidad de persistir datos y

acceder lógicamente a ellos.

Pueden ser datos propios del sistema o datos

expuestos por sistemas externos (servicios).

Esta capa expone la persistencia a datos

principalmente a la capa de dominio.

Esta exposición debe realizarse de una forma

desacoplada.

Capa de Infraestructura de Acceso a Datos

Elementos

Subcapa de “repositorios”

Un repositorio es una clase encargada de operaciones de persistencia y acceso a datos.

Se liga a una tecnología concreta: ORM como Entity Framework.

NHibernate.

ADO.NET.

Normalmente debemos crear un Repository por cada entidad del dominio.

El acceso a un Repository debe realizarse mediante una interfaz de forma que podríamos sustituir un repositorio por otro que implemente otras tecnologías.

Difiere de un objeto Data Access.

Capa de Infraestructura de Acceso a Datos

Elementos

Componentes Base

Puede implementar lógica común de acceso a datos.

Minimiza el código a mantener.

Este componente se puede aplicar a cualquier tipo de

capa.

Modelo de Datos

Contiene el modelo de datos, estableciendo la

entidad-relación.

Los sistemas ORM (como Entity Framework) disponen

de técnicas de definición de modelo de datos a nivel

de diagramas.

Capa de Infraestructura de Acceso a Datos

Elementos

Agentes de Servicios Externos

Empleado para consumir servicios de terceros.

Implementa código que gestiona la semántica de

comunicación con servicios externos.

Estos agentes, aíslan dicha idiosincrasia de forma que

permita reemplazar estos servicios.

Capa de Infraestructura

Transversal/Horizontal

Proporcionan capacidades técnicas que dan

soporte a capas superiores.

Son bloques de construcción ligados a una

tecnología concreta para desempeñar sus

funciones.

Aspectos horizontales típicos:

Seguridad.

Tareas de gestión de operaciones.

Capa de Infraestructura Transversal/Horizontal

Elementos

Subcapas de “Servicios de Infraestructura”

Se encargan de agrupar acciones de infraestructura,

como: mandar e-mail, controlar aspectos de

seguridad, logging, etc.

Subcapas de objetos de infraestructura.

Son objetos necesarios para implementar los tipos de

infraestructura transversal a ocupar.