Arquitectura en Capas – Análisis completo + Tradicional vs Modernas, DDD, DIP (Cap 5)

Introducción

La arquitectura en capas es una de las técnicas más comunes que los Diseñadores/ Desarrolladores de software utilizan para separar un sistema de software muy complejo, principalmente para aplicaciones empresariales. Esta separación se conoce como LAYERING, que simplemente significa descomponer un sistema de software en sus partes, es decir, separar un sistema en capas según preocupaciones y responsabilidades.

“Generalmente” existen 3 capas principales de aplicación y una de soporte, la capa de presentación, la capa de Negocio o Dominio y la capa de Acceso a datos o Persistencia, donde cada capa descansa sobre otra, la capa superior solo puede acceder a la capa inferior y utilizar varios servicios definidos, pero la capa inferior no es consciente de la capa superior, es decir:

La capa inferior no puede y no debería acceder a la capa superior. Por ejemplo, la capa de presentación solo puede acceder a la capa de dominio, pero la capa de dominio no puede acceder a capa de presentación, de igual manera dominio solo es consciente de la capa de acceso de datos, pero la capa de datos no puede acceder a capa de dominio y utilizar los servicios definidos.

Esta teoría es totalmente cierta, es uno de los principios básicos de la arquitectura en capas, para lograr bajo desacoplamiento entre componentes. A esta separación se le conoce como la estratificación estricta, Arquitectura en capas Tradicional arquitectura en capas puro. Pero hay otros enfoques menos puros, pero ofrece mejores resultados, como la estratificación flexible o aplicar el principio de la inversión de dependencia (DIP) a nivel arquitectónico, donde hablaremos de ello más adelante. Por otro lado, esta separación se hizo popular como programación en capas o programación en 3 capas, aunque es un término informal.

Capa de presentación o IU

Es responsable de manejar la interfaz gráfica de usuario como vistas renderizadas, archivos HTML de una página web, la interfaz de línea de comandos o los formularios de una aplicación de escritorio. En esta capa puedes aplicar patrones (Opcional) como.

Modelo vista controlador (MVC)
Modelo jerárquico vista controlador (HMVC – PAC)
Modelo vista presentador (MVP)
Modelo vista – vista modelo (MVVM)
Modelo vista presentador vista modelo
Page controller
Front controller
Application controller
Entre otras…

Capa de negocio o dominio

Es el componente más importante, es el corazón de la aplicación, codifica las reglas comerciales y el flujo de trabajo del mundo real, que determinan como se pueden crear, almacenar y cambiar los datos de un objeto comercial. Las reglas comerciales describen las operaciones y restricciones que se aplica a una organización. El flujo de trabajo consta de las tareas, los pasos de procedimiento, la información de entrada y salida requerida y las herramientas necesarias para cada paso de ese procedimiento.

Si resulta que la capa de dominio es muy compleja, es decir tiene un montón de métodos con lógica de negocio podemos agregar la capa de servicio o aplicación, que es una capa delgada que sirve como fachada y envuelve la capa de dominio, lo cual se encarga del flujo de operaciones, coordina todas las transacciones. En esta capa se puede usar patrones (Opcional) como:

Entidad de dominio, modelo de dominio u objeto de negocio
Objeto de valor
Ruta agregada.
Script de transacción
Tabla modular
El objeto de transferencia de datos
Delegado de negocios
Unidad de trabajo
Entre otras…

Capa de acceso de datos o persistencia

Se encarga de almacenar u obtener datos desde un almacén de datos, como una base de datos, un servicio externo o un archivo plano. Esta capa también es conocida como capa de persistencia o capa de integración, en ella podemos utilizar patrones (Opcional) como:

Enlace a datos de tabla
Registro activo
Mapeado de datos
Objeto de consulta
Objeto de acceso a datos
Repositorio
Entre otras…

Bueno estas son las 3 capas principales de aplicación. Hay una cuarta capa de soporte que también estará siempre presente, sobre todo en las aplicaciones web, es la capa corte transversal, también conocido como la capa común o capa de soporte.

Capa Común de Soporte o Corte Transversal

Esta capa es común para todas las capas, es decir tanta presentación dominio y acceso a datos pueden acceder a ella. La responsabilidad de esta capa es la gestión de seguridad y operaciones, como autenticación, autorización, almacenamiento en cache, comunicación, gestión de configuración, gestión de excepciones, administración del estado y validaciones de seguridad.

En las últimas décadas se hizo muy popular usar la capa común solo para la persistencia de datos de la entidad empresarial, conocida como CAPA ENTIDAD, me parece una buena estrategia, lo he usado muchas veces, ya que se obtiene mayor flexibilidad, la cantidad de código y clases disminuye considerablemente, puesto que solo se necesita declarar los atributos de la entidad una vez y cualquier capa puede reutilizar las clases definidas, pero estamos violando los principios de la arquitectura en capas y la programación orientada objetos, más aun si se tiene mucha lógica de negocio, de esta manera ya no se tiene bajo acoplamiento.

Las entidades pertenecen a la capa de negocio, y no se puede exponer de esa manera, a futuro tendrá escalabilidad limitada y difícil mantenimiento. Sin embargo, no tiene nada de malo, se puede hacer de esta manera siempre en cuando se tenga muy poca lógica de negocio y está pensado para aplicaciones pequeñas.

La separación en capas facilita la creación de roles y modelos de responsabilidad, como también facilita el desarrollo, prueba, control y mantenimiento. Un error muy común es mezclar responsabilidades de una capa y otra. La capa de presentación solo se ocupa de la lógica de presentación, no puede tener nada de lógica empresarial, como cálculos. La capa de negocio solo se ocupa de la lógica empresarial, la capa de acceso a datos solo se ocupa con la comunicación con alguna fuente de datos.

Una pregunta muy frecuente es: ¿Donde debería ir la validación de datos?, como no permitir datos vacíos, solo números o email, ese tipo de validaciones puede ir en la capa de presentación si es necesario, o en la capa de dominio (Negocio).

Modelos de la Arquitectura en Capas

Existen muchos modelos de arquitectura en capas, lo divido en 2 categorías: Estratificación Estricta y Estratificación Flexible.

Estratificación Estricta – Capas Tradicional

La ley de leyes desde su origen, el principio arcaico y tradicional: La estratificación estricta, donde una capa solo conoce de la capa debajo de ella, por ejemplo la capa de negocio solo debe depender de la capa de acceso a datos, pero acceso a datos no puede depender de negocio, a eso se le conoce como la dependencia única para lograr bajo acoplamiento entre componentes es uno de los principios básicos principales de capas tradicional y coincide con los conceptos del introducción.

Bueno la arquitectura en capas aparece en los años 1970 y comenzaron a ser una práctica generalizada durante la década de 1990, con el cambio generalizado a un contexto de nube, el aumento en usuarios de aplicaciones, complejidad de aplicaciones y complejidad de infraestructura terminamos viendo una evolución principalmente a un esquema de 3 capas, o las capas necesarias. Muchos grupos de programadores publicaron libros como documentación y guías sobre esta arquitectura, están los libros:

Designing Component-Based Applications – Microsoft DNA (Mary Kirtland-1998)
Enterprise Java Programming with IBM WebSphere (Kyle Brown – 2001)
.NET Enterprise Design with VB.NET and SQL Server (Jimmy Nilson – 2001)
J2EE Design Patterns – Second Edition (Java – 2002)
EJB Design Patterns (Floyd Marinescu – 2002)
Patterns of Enterprise Application Architecture (Martin Fowler – 2003)

Estratificación Flexible

Tenemos otro enfoque, la estratificación flexible o relajada, donde una capa puede acceder a cualquier capa debajo de ella, es decir la capa de presentación puede acceder tanto a la capa de negocio y acceso a datos, si se tuviese 7 capas, la séptima capa podrá usar los servicios de las capas 6, 5, 4, 3, 2, o 1 (Podría ser todas o algunas, depende de criterios). Este enfoque se puso en práctica desde los años 1995 con el fin de evitar el anti patrón espagueti y el uso de métodos proxy. Inclusive Martin Fowler realiza un comentario interesante en su libro Patterns of Enterprise Application Architecture (2003) sobre este tema.

“A veces, las capas se organizan de modo que la capa de dominio oculte completamente la fuente de datos de la presentación. Más a menudo, sin embargo, la presentación accede directamente al almacén de datos. Si bien esto es menos puro, tiende a funcionar mejor en la práctica. La presentación puede interpretar un comando del usuario, usar la fuente de datos para extraer los datos relevantes de la base de datos y luego dejar que la lógica del dominio manipule esos datos antes de presentarlos en el cristal”

Ese mismo año en el 2003, Eric Evans publica su libro más emblemático, la DDD: Diseño Impulsado por el Dominio, abordando la complejidad en el corazón del software, este libro no trata específicamente de la arquitectura en capas, la DDD es una prescripción de metodología que trata de cómo hacer un modelo de software muy complejo a partir de procesos del mundo real, cuyo enfoque es el mapeo de actividades, tareas, eventos y datos dentro de un dominio de problemas, implica la colaboración entre expertos en dominios, La DDD proporciona guías claras sobre cómo deberían interactuar sus objetos y ayuda a dividir sus objetos en 3 categorías claves. Objetos de valor, entidad de dominio y raíces agregados, también recomienda el uso de patrones como repositorios, servicio y fabrica. No debemos intentar usar DDD en ningún proyecto para el cual tenga una fecha límite o está destinado en un proyecto menor de 6 meses de desarrollo, además debemos estar familiarizado con patrones de diseño y los patrones de diseño empresarial.

Sin embargo, también hubo una visión para la crear un sistema de software en la arquitectura en capas, la DDD identifica 4 capas, la capa de interfaz de usuario, aplicación, dominio e infraestructura.

Pero debemos tener muy cuenta este enfoque tiene ciertas reglas.

Evoluciones

El diagrama de un enfoque flexible fue el origen de muchas evoluciones de la arquitectura en capas, por ejemplo, aplicar el principio de la inversión de dependencia a nivel arquitectónico, de ello, aparece la arquitectura hexagonal, Onion y Clean.

Arquitectura en Capas + DIP

Sin embargo, los esquemas anteriores (Dirección de dependencia arriba abajo) violan el principio de inversión de dependencia porque la capa de dominio depende de la capa de acceso a datos, y el principio de inversión de dependencia dice: Las abstracciones no deben depender de los detalles los detalles deben depender de las abstracciones. Como ya sabemos la capa de dominio o negocio es la abstracción de algún dominio del mundo real y no debe depender de los detalles como la capa de datos, aplicación o presentación.

No obstante, este problema ya se resolvía con la estratificación flexible como Martín lo dice claramente en su comentario: La presentación puede interpretar un comando del usuario, usar la fuente de datos para extraer los datos relevantes de la base de datos y luego dejar que la lógica del dominio manipule esos datos antes de presentarlos en el cristal. Por lo tanto, capa de dominio no depende de la capa de acceso a datos, entonces no incumple el principio de inversión de dependencia, sin embargo no es buena idea que la capa de presentación pueda acceder directamente a la capa de acceso a datos, lo mejor manera es crear la capa de aplicación para que se encargue de ello y/o aplicar el principio de inversión dependencia a nivel arquitectónico donde la capa de dominio no depende de ninguna capa, las otras capas dependen de ella.

Arquitectura Hexagonal

La arquitectura hexagonal, manejado por adaptadores y puertos, fue pensado por el programador Alistair Cockburn, por los años 2002, pero lo hizo público mediante su blog en el año 2005. Si bien en la publicación de Alistair no se comenta nada de la arquitectura tradicional en capas, pero sigue siendo layering, una estratificación que separa responsabilidades del sistema y tiene el objetivo de aislar la lógica empresarial con el principio de la dirección de dependencia de la arquitectura tradicional, donde las capas externas dependen de las capas internas pero las capas internas no saben sobre las capas externas.

Arquitectura Onion

En el año 2008 Jeffrey Palermo publica la arquitectura onion, la cebolla, esta arquitectura está basada en la arquitectura en capas tradicional, la arquitectura hexagonal, la DDD y el principio de la inversión de dependencia a nivel arquitectónico, la dirección del acoplamiento es hacia el centro.

Arquitectura Clean

En el año 2012 Robert Martin, publica en su blog sus ideas sobre la arquitectura limpia, donde propone crear una arquitectura estándar, donde intenta integrar las ideas de las arquitectura más recientes en una sola idea accionable, es decir incorpora las reglas de la arquitectura hexagonal y la arquitectura de la cebolla, como también se apoya en los patrones MVC y EBI.

Conclusión

Bueno en conclusion, Layering o Capas, es un estilo de arquitectura, es la abstracción del más alto nivel del sistema, separa un sistema complejo en capas en función de sus responsabilidades o roles. Los beneficios que ofrece son, bajo acoplamiento, alta cohesión, reutilización, mayor flexibilidad, facilita el mantenimiento, mayor escalabilidad y agiliza el desarrollo.

Cabe mencionar que en estas arquitecturas modernas es muy importante saber y usar patrones de arquitectura, patrones diseño empresarial, patrones de diseño base, programación orientada a objetos y programación orientada a aspectos, como también el uso de interfaces y clases abstractas, donde las capas internas definen interfaces y las Capas externas implementan interfaces.

Sin embargo, la regla de oro es: Use solo las capas que necesite, los niveles que necesite, No debemos dejarnos llevar por un santo grial arquitectónico de los libros u otra fuente, a menudo puede ser que no se necesite esta arquitectura, además recordemos que estas arquitecturas están destinadas a sistemas a gran escala.

Ejemplo – Aplicación Buscar/Filtrar Datos C#, SQL Server

Pasemos a un pequeño ejemplo, haremos el mismo ejercicio de los tutoriales anteriores, una pequeña aplicación de mostrar, búsqueda y filtro de datos. Usaremos una arquitectura intermedia entre lo tradicional y lo moderno, me refiero a la arquitectura en capas reconocido por la DDD (diseñado impulsado por el dominio) + el principio de inversión de dependencia a nivel arquitectónico (en la capa de dominio e infraestructura).

Ver Video Tutorial:

Libros de Referencia

Designing Component-Based Applications – Microsoft DNA (Mary Kirtland-1998)
Enterprise Java Programming with IBM WebSphere (Kyle Brown – 2001)
.NET Enterprise Design with VB.NET and SQL Server (Jimmy Nilson – 2001)
J2EE Design Patterns – Second Edition (Java – 2002)
EJB Design Patterns (Floyd Marinescu – 2002)
Patterns of Enterprise Application Architecture (Martin Fowler – 2003)
Domain-driven design-DDD (Eric Evans -2003)