SEPARACIÓN EN CAPAS

Ciocca, D. (2008). Separación en capas. En: Arquitectura de software y entornos de trabajo

(frameworks) de contenedores ligeros (pp. 30-35). Argentina: Universidad Nacional de Luján

1.5.2 Separación en capas

Cuando uno piensa en términos de capas, lo que se tiene que tener en cuenta es, que estas
esconden su lógica al resto de las mismas y solo brindan puntos de acceso a dicha lógica.
Es decir, una capa solo brindará servicios a la subsiguiente, mientras que la de más bajo
nivel no conocerá nada de dicha capa. Por ejemplo, suponiendo que la capa 4 es la de más
alto nivel (más cerca de la presentación que del acceso a los datos), ella usará los servicios
proporcionados por la capa 3, mientras que a su vez esta última, usará los servicios de la
capa 2, pero la capa 4 no conocerá nada de la capa 2 [MF02].

Ventajas
 Permite sustituir capas por otras implementaciones alternativas, por ejemplo, se podrá
sustituir la capa de presentación implementada con tecnologías “web” por otras
implementadas con tecnologías “swing” [MF02]. Esto permite que problemas complejos
sean distribuidos en pequeñas piezas más manejables [INT07].
 Las capas superiores brindan servicios a las capas inferiores permitiendo la reusabilidad
del código [NT07].
 Minimiza las dependencias entre las capas. Si se quiere cambiar por un framework de
O/R mapping (Object / Relational mapping, mapeos del modelo relacional a objetos),
esto no impactará en las capas superiores [MF02].
 No es necesario conocer más capas que la que se está viendo y las “colindantes”.
[MF02].
 Los detalles de implementación de cada capa son escondidos para el resto [INT07].

Desventajas
• Si sobrecargamos a la aplicación empresarial con capas, perderá performance
[MF02].
• Tienen el problema de los “cambios en cascada”. Por ejemplo, en una típica aplicación
empresarial que muestra un dato en su UI (User Interface, Interface de Usuario), que
viene desde la base de datos, si este cambia se modifica, este cambio impacta en
todas las capas por las que pasa el dato [MF02].

Se considera necesario aclarar que la separación en capas puede conducir al uso indebido de las
mismas. Si bien no se puede considerar como una desventaja en sí misma, se considera oportuno
entrever que su mal uso produce una violación del encapsulamiento: Cómo las capas ocultan los
detalles de implementación al resto de las mismas. Una violación de esto puede “costar caro”, ya
que si una capa (ej. capa A) usa directamente los detalles de implementación que se encuentran
en otra (ej. capa B), cuando se produzcan cambios en la capa B también se verá afectada la capa
A [INT07].

Según Fowler en su sitio de Internet [INT06], hace referencia a algunos principios básicos de la
separación en capas a través de una puntuación.

Los principios con mayor puntuación son:

 • Bajo acoplamiento entre las capas, alta cohesión dentro de ellas.
• Separación de responsabilidades.
• Adaptabilidad: permite el cambio de una capa.
• Las capas UI o de presentación, no contienen lógica de negocio.
 Las capas de negocio no contienen lógica de presentación ni hacen referencia a la capa
de presentación.
• No existen las referencias circulares entre las capas.
• Las capas deberán ser testeadas individualmente.
• Capas inferiores no deben depender de capas superiores.
 Las capas pueden compartir aspectos de infraestructura como ser aspectos de
seguridad.

A sí mismo, Evans en su libro [EE03], explica que la separación en capas permite: un diseño
cohesivo (donde las dependencias están hacia las capas inferiores), reduciendo el acoplamiento
entre las capas superiores y por último, aislar el modelo de dominio del resto de las capas,
permitiendo, escribir código relacionado únicamente con el dominio de la aplicación.

Como corolario de este apartado, se puede distinguir, que tanto Eric Evans como Martin Fowler
coinciden en sus principios [INT06], dándole Evans la importancia de aislar el dominio del resto de
la aplicación.

1.5.3 Capas lógicas

Como se menciona en el libro de Fowler [MF02], existen tres capas principales:
• Capa de presentación.
• Capa de negocio.
• Capa de acceso a datos.

Esta separación, mencionada por Fowler [MF02], está presente en la mayoría de los
desarrollos Web por capas. Esto no quiere decir que no tengamos más capas, sino que la
cantidad de las mismas va a depender del sistema a desarrollar. Es decir, existen grandes
variaciones en cuanto a la cantidad de capas que se utilizan en los distintos desarrollos de
aplicaciones Web. La mayoría de las arquitecturas utilizan las siguientes cuatro capas
conceptuales [EE03].

La siguiente descripción de arquitectura en capas, se encuentra en el Capítulo 4 [EE03]. Lo

interesante de esta clasificación es que le otorga una entidad específica a la Capa de
Dominio (pone énfasis en la misma).

La interface de usuario
Esta capa se encargará de resolver cómo exponer la lógica de negocio a través de una
interface. La interface más común es la Web. Por lo que se deberá tener en cuenta los
límites de la distribución de los objetos entre el browser (navegador) - cliente y el servidor
web.

La capa de aplicación
Esta capa no contiene reglas de negocio. Será la encargada de coordinar y delegar trabajo
a los objetos de dominio de la capa subsiguiente. Muchas veces, esta capa, no hace el
trabajo de coordinar y delegar, sino que tiene lógica de negocio incorporada y esto conlleva
a tener un modelo de dominio anémico (será ampliado en el apartado 1.6.3.2).
La capa de dominio (o capa de modelo)
También conocida como “capa de negocio”. Se encargará de exponer la lógica de negocio
a las capas de más alto nivel. Aquí encontraremos las reglas de negocio. Esta capa es el
corazón de la aplicación y en ella se representarán:
• Conceptos de negocio.
• Reglas de negocio.
• Información acerca de la situación del negocio.

La capa de infraestructura
Esta capa será la encargada de proporcionar las capacidades técnicas genéricas que
apoyan las capas más altas.

Provee la persistencia para el dominio. Ya sea, cómo establecer la conexión, cómo

acceder a la BD y finalizar la conexión. Básicamente en una aplicación empresarial, las
tecnologías de acceso son varias y a continuación citaremos algunas de ellas:
• Vía JDBC que viene con la API de Java.
• Utilizando algún framework de O/R Mapping como Hibernate, JDO.
• (Java Data Object), TopLink, iBattis, OJB de Apache.

Es decir, soportará la interacción entre las capas por medio de un framework de

arquitectura.

Como conclusión, algunos proyectos no tienen la distinción entre las capas de interface
de usuario y aplicación. Otros tienen múltiples capas de infraestructura. Pero lo importante
es la separación de la capa de dominio que permitirá lo que se conoce como MDA (Model
Driven Design, Diseño Dirigido por el Modelo) [EE03].