Conceptos clave
Nota en la Figura 1-2 que cada una de las capas de la arquitectura está marcada como cerrada. Este es un concepto muy importante en el patrón de arquitectura por capas. Una capa cerrada significa que cuando una petición se mueve de capa a capa, debe pasar por la capa justo debajo de ella para llegar a la siguiente capa por debajo de esa. Por ejemplo, una solicitud originada en la capa de presentación debe pasar primero por la capa de negocio y luego por la capa de persistencia antes de llegar finalmente a la capa de base de datos.
Figura 1-2. Capas cerradas y acceso a peticiones
Entonces, ¿por qué no permitir que la capa de presentación acceda directamente a la capa de persistencia o a la de base de datos? Después de todo, el acceso directo a la base de datos desde la capa de presentación es mucho más rápido que pasar por un montón de capas innecesarias sólo para recuperar o guardar información de la base de datos. La respuesta a esta pregunta se encuentra en un concepto clave conocido como capas de aislamiento.
El concepto de capas de aislamiento significa que los cambios realizados en una capa de la arquitectura generalmente no impactan o afectan a los componentes de otras capas: el cambio está aislado a los componentes dentro de esa capa, y posiblemente a otra capa asociada (como una capa de persistencia que contiene SQL). Si se permite el acceso directo de la capa de presentación a la capa de persistencia, los cambios realizados en SQL dentro de la capa de persistencia afectarían tanto a la capa de negocio como a la capa de presentación, produciendo así una aplicación muy acoplada con muchas interdependencias entre los componentes. Este tipo de arquitectura se vuelve entonces muy difícil y costosa de cambiar.
El concepto de capas de aislamiento también significa que cada capa es independiente de las otras capas, teniendo así poco o ningún conocimiento del funcionamiento interno de otras capas en la arquitectura. Para entender el poder y la importancia de este concepto, considere un gran esfuerzo de refactorización para convertir el marco de presentación de JSP (Java Server Pages) a JSF (Java Server Faces). Suponiendo que los contratos (por ejemplo, el modelo) utilizados entre la capa de presentación y la capa de negocio siguen siendo los mismos, la capa de negocio no se ve afectada por la refactorización y permanece completamente independiente del tipo de marco de interfaz de usuario utilizado por la capa de presentación.
Aunque las capas cerradas facilitan las capas de aislamiento y, por lo tanto, ayudan a aislar el cambio dentro de la arquitectura, hay veces que tiene sentido que ciertas capas sean abiertas. Por ejemplo, suponga que quiere añadir una capa de servicios compartidos a una arquitectura que contiene componentes de servicio comunes a los que acceden los componentes dentro de la capa de negocio (por ejemplo, clases de utilidad de datos y cadenas o clases de auditoría y registro). Crear una capa de servicios suele ser una buena idea en este caso porque arquitectónicamente restringe el acceso a los servicios compartidos a la capa de negocio (y no a la capa de presentación). Sin una capa separada, no hay nada arquitectónico que restrinja a la capa de presentación el acceso a estos servicios comunes, lo que hace difícil gobernar esta restricción de acceso.
En este ejemplo, la nueva capa de servicios probablemente residiría debajo de la capa de negocio para indicar que los componentes en esta capa de servicios no son accesibles desde la capa de presentación. Sin embargo, esto presenta un problema en el sentido de que la capa de negocio se requiere ahora para ir a través de la capa de servicios para llegar a la capa de persistencia, que no tiene ningún sentido. Este es un viejo problema con la arquitectura de capas, y se resuelve mediante la creación de capas abiertas dentro de la arquitectura.
Como se ilustra en la Figura 1-3, la capa de servicios en este caso está marcada como abierta, lo que significa que se permite que las peticiones pasen por alto esta capa abierta y vayan directamente a la capa inferior. En el siguiente ejemplo, dado que la capa de servicios está abierta, ahora se permite que la capa de negocio la salte y vaya directamente a la capa de persistencia, lo cual tiene mucho sentido.
Figura 1-3. Capas abiertas y flujo de peticiones
Aprovechar el concepto de capas abiertas y cerradas ayuda a definir la relación entre las capas de la arquitectura y los flujos de peticiones y también proporciona a los diseñadores y desarrolladores la información necesaria para entender las distintas restricciones de acceso a las capas dentro de la arquitectura. Si no se documenta o se comunica adecuadamente qué capas de la arquitectura están abiertas y cerradas (y por qué), normalmente se obtienen arquitecturas muy acopladas y frágiles que son muy difíciles de probar, mantener y desplegar.