Captulo 1.

Capas

La estratificacin es una de las tcnicas ms comunes que los

diseadores de software utilizan para romper un sistema de
software complicado. Lo ve en la arquitectura de las mquinas,
donde las capas descienden desde un lenguaje de programacin hacia
llamadas al sistema operativo, y hacia conjuntos de instrucciones
de CPU y controladores de dispositivos, y hacia puertas lgicas
dentro de chips. Las redes tienen la capa FTP sobre TCP, que est
sobre IP, que est sobre Ethernet.

Cuando se piensa en un sistema en trminos de capas, imaginamos

que los subsistemas principales del software estn dispuestos en
alguna forma de pastel de capa, donde cada capa descansa sobre una
capa inferior. En este esquema la capa superior utiliza varios
servicios definidos por la capa inferior, pero la capa inferior no
tiene conocimiento de la capa superior. Adems, cada capa suele
ocultar sus capas inferiores de las capas anteriores, por lo que
la capa 4 utiliza los servicios de la capa 3, que utiliza los
servicios de la capa 2, pero la capa 4 desconoce la capa 2. (No
todas las arquitecturas de capas son opacas como sta , Pero la
mayora lo son, o ms bien la mayora son opacas).

Romper un sistema en capas tiene una serie de beneficios

importantes.

Se puede entender una sola capa como un todo coherente sin

saber mucho acerca de las otras capas. Usted puede entender
cmo construir un servicio FTP en la parte superior de TCP
sin conocer los detalles de cmo funciona Ethernet.

Puede sustituir capas por implementaciones alternativas de

los mismos servicios bsicos. Un servicio FTP puede
ejecutarse sin cambios a travs de Ethernet, PPP, o lo que
una empresa de cable utiliza.

Se minimizan las dependencias entre capas. Si la empresa de

cable cambia su sistema de transmisin fsica, siempre que
hagan que IP funcione, no tenemos que alterar nuestro
servicio FTP.

Las capas son buenos lugares para la estandarizacin. TCP e

IP son estndares porque definen cmo deben funcionar sus
capas.

Una vez que haya construido una capa, puede utilizarla para
muchos servicios de nivel superior. As, TCP / IP es
utilizado por FTP, telnet, SSH y HTTP. De lo contrario, todos
estos protocolos de nivel superior tendran que escribir sus
propios protocolos de nivel inferior.
Estratificar es una tcnica importante, pero hay desventajas.

Las capas encapsulan algunas, pero no todas, las cosas bien.

Como resultado, a veces se producen cambios en cascada. El
ejemplo clsico de esto en una aplicacin empresarial
estratificada es aadir un campo que debe mostrarse en la
interfaz de usuario, debe estar en la base de datos y, por lo
tanto, debe agregarse a cada capa intermedia.

Las capas adicionales pueden daar el rendimiento. En cada

capa las cosas tpicamente necesitan ser transformadas de una
representacin a otra. Sin embargo, el encapsular una funcin
subyacente a menudo le da ganancias de eficiencia que la
compensan. Una capa que controla las transacciones se puede
optimizar y luego har todo ms rpido.

Pero la parte ms difcil de una arquitectura en capas es decidir

qu capas tiene y cul debe ser la responsabilidad de cada capa.

La evolucin de las capas en aplicaciones empresariales

Aunque soy demasiado joven para haber hecho algn trabajo en los
primeros das de los sistemas de lote, no siento que la gente
pensara mucho en capas en esos das. Usted escriba un programa
que manipulara alguna forma de archivos (ISAM, VSAM, etc.), y esa
era su aplicacin. No se necesitaban capas.

La nocin de capas se hizo ms evidente en los aos 90 con el

aumento de los sistemas cliente-servidor. stos eran sistemas de
dos capas: El cliente tena la interfaz de usuario y otro cdigo
de aplicacin, y el servidor usualmente era una base de datos
relacional. Las herramientas comunes del cliente eran VB,
Powerbuilder y Delphi. Esto hizo particularmente fcil la
construccin de aplicaciones de datos intensivos, ya que tenan
controles de interfaz de usuario que eran conscientes de SQL. Por
lo tanto, poda crear una pantalla arrastrando los controles a un
rea de diseo y luego usar hojas de propiedades para conectar los
controles a la base de datos.

Si la aplicacin tena que ver con la visualizacin y la simple

actualizacin de datos relacionales, estos sistemas cliente-
servidor funcionaban muy bien. El problema vino con la lgica de
dominio: reglas de negocio, validaciones, clculos y similares.
Por lo general, la gente escriba esto en el cliente, pero esto
era incmodo y normalmente se haca incrustando la lgica
directamente en las pantallas de la interfaz de usuario. A medida
que la lgica del dominio se hizo ms compleja, este cdigo se
volvi muy difcil de trabajar. Adems, la incorporacin de la
lgica en pantallas facilit la duplicacin de cdigo, lo que
signific que los cambios simples resultaron en la bsqueda de
cdigo similar en muchas pantallas.
Una alternativa fue poner la lgica del dominio en la base de
datos como procedimientos almacenados. Sin embargo, los
procedimientos almacenados tienen mecanismos estructurales
limitados, lo que condujo de nuevo a cdigo incmodo. Adems, a
muchas personas les gustaban las bases de datos relacionales
porque SQL era un estndar que les permitira cambiar su proveedor
de base de datos. A pesar del hecho de que pocas personas
realmente lo hicieron, a muchos les gustaba tener la opcin de
cambiar de proveedor sin un costo de transicin demasiado alto.
Debido a que son todos propietarios, los procedimientos
almacenados eliminaron esa opcin.

Al mismo tiempo que cliente-servidor estaba ganando popularidad,

el mundo orientado a objetos estaba aumentando. La comunidad de
objetos tena una respuesta al problema de la lgica de dominio:
Moverse a un sistema de tres capas. Este enfoque tiene una capa de
presentacin para su interfaz de usuario, una capa de dominio para
su lgica de dominio y un origen de datos. De esta manera usted
podra mover toda esa lgica intrincada del dominio fuera de la
interfaz de usuario y ponerla en una capa donde usted podra
estructurarla correctamente con los objetos.

A pesar de esto, la corriente del diseo con objetos hizo poco

progreso. La verdad era que muchos sistemas eran simples, o por lo
menos comenzaban de esa manera. Y aunque el enfoque de tres capas
tena muchos beneficios, la herramienta para cliente-servidor era
convincente si su problema era simple. Las herramientas cliente-
servidor tambin eran difciles, o incluso imposibles, de utilizar
en una configuracin de tres capas.

Creo que el choque ssmico aqu fue el surgimiento de la Web. De

repente la gente quera desplegar aplicaciones cliente-servidor
con un navegador web. Sin embargo, si toda su lgica de negocio
estaba enterrada en un cliente rico, entonces toda su lgica de
negocio necesitaba ser rehecha para poder tener una interfaz Web.
Un sistema bien diseado de tres capas podra agregar una nueva
capa de presentacin y hacerse con ella. Adems, con Java vimos un
lenguaje orientado a objetos golpear sin vergenza a la corriente
principal. Las herramientas que aparecieron para crear pginas web
estaban mucho menos ligadas a SQL y por lo tanto ms susceptibles
a una tercera capa.

Cuando la gente habla de capas, a menudo hay cierta confusin

sobre los trminos capa y nivel. A menudo los dos se usan como
sinnimos, pero la mayora de la gente ve a nivel como implicando
una separacin fsica. Los sistemas cliente-servidor a menudo se
describen como sistemas de dos niveles, y la separacin es fsica:
El cliente es un escritorio y el servidor es un servidor. Yo uso
capa para hacer hincapi en que no tiene que ejecutar las capas en
diferentes mquinas. Una capa distinta de lgica de dominio a
menudo se ejecuta en un escritorio o en el servidor de base de
datos. En esta situacin tiene dos nodos pero tres capas
distintas. Con una base de datos local puedo ejecutar las tres
capas en un solo ordenador porttil, pero todava habr tres capas
distintas.

Las tres capas principales

Para este libro estoy centrando mi discusin en torno a una

arquitectura de tres capas principales: presentacin, dominio y
origen de datos. (Estoy siguiendo los nombres utilizados en [Brown
et al.]). La Tabla 1.1 resume estas capas.

La lgica de la presentacin trata de cmo manejar la interaccin

entre el usuario y el software. Esto puede ser tan simple como un
sistema de mens de lnea de comandos o basado en texto, pero en
estos das es ms probable que sea una interfaz grfica de usuario
de cliente enriquecido o una interfaz de usuario de navegador
basada en HTML. (En este libro utilizo el cliente enriquecido para
significar una interfaz de usuario Windows / Swing / fat-client,
en contraposicin a un navegador HTML). Las principales
responsabilidades de la capa de presentacin son mostrar
informacin al usuario e interpretar comandos del usuario en
Acciones sobre el dominio y la fuente de datos.

La lgica de origen de datos es acerca de la comunicacin con

otros sistemas que llevan a cabo las tareas en nombre de la
aplicacin. Estos pueden ser monitores de transaccin, otras
aplicaciones, sistemas de mensajera, y as sucesivamente. Para la
mayora de las aplicaciones empresariales la mayor parte de la
lgica de origen de datos es una base de datos que es
principalmente responsable del almacenamiento persistente de los
datos.

La pieza restante es la lgica de dominio, tambin referida como

la lgica de negocios. Esta es el trabajo que la aplicacin tiene
que hacer para el dominio con el que est trabajando. Implica
clculos en base a los datos ingresados y almacenados, la
validacin de los datos que vienen de la presentacin y averiguar
exactamente la lgica de origen de datos que debe ejecutar,
dependiendo de los comandos que recibida de la presentacin
A veces las capas estn dispuestas de manera que la capa de
dominio esconde completamente el origen de datos de la
presentacin. Ms a menudo, sin embargo, la presentacin accede al
origen de datos directamente. Mientras que esto es menos puro,
tiende a trabajar mejor en la prctica. La presentacin puede
interpretar un comando del usuario, utilizar el origen de datos
para recuperar los datos relevantes desde la base de datos, y
luego dejar que la lgica de dominio manipule los datos antes de
presentarlos en la pantalla.

Una sola aplicacin a menudo puede tener mltiples paquetes de

cada una de estas tres capas. Una aplicacin diseada para ser
manipulada no slo por los usuarios finales, a travs de una
interfaz de cliente enriquecido, sino tambin a travs de una
lnea de comandos tendra dos presentaciones: una para la interfaz
de cliente enriquecido y otra para la lnea de comandos. Pueden
estar presentes mltiples componentes de origen de datos para
diferentes bases de datos, pero seran particularmente para la
comunicacin con paquetes existentes. Incluso el dominio podra
estar dividido en distintas reas relativamente separadas entre
s. Ciertos paquetes de origen de datos slo podran ser
utilizados por ciertos paquetes de dominio.

Hasta ahora he hablado acerca de un usuario. Esto naturalmente

plantea la cuestin de lo que sucede cuando no hay un ser humano
conduciendo el software. Esto podra ser algo nuevo, y de moda
como un servicio web o algo mundano y til como un proceso por
lotes. En este ltimo caso el usuario es el programa cliente. En
este punto se hace evidente que hay mucha similitud entre las
capas de presentacin y de origen de datos en que ambas estn
relacionadas con la conexin con el mundo exterior. Esta es la
lgica detrs del patrn de Arquitectura Hexagonal de Alistair
Cockburn, que visualiza cualquier sistema como un ncleo rodeado
de interfaces con sistemas externos. En la Arquitectura Hexagonal
todo lo externo es fundamentalmente una interfaz externa, y por lo
tanto es una visin simtrica en lugar de mi esquema de capas
asimtricas.

Encuentro esta asimetra de utilidad, sin embargo, porque creo que

se debe hacer una clara distincin entre la interfaz que le
proporciona un servicio a los dems y el uso de un servicio
proporcionado por otra persona. Regresando al ncleo, esta es la
verdadera distincin que hago entre la presentacin y el origen de
datos. La presentacin es una interfaz externa para un servicio
que su sistema ofrece a otra persona, ya sea un complejo humanos o
un simple programa remoto. El origen de datos es la interfaz de
las cosas que le estn proporcionando un servicio a usted. Resulta
beneficioso pensar esto de manera diferente porque la diferencia
en los clientes altera la forma en que se opina sobre el servicio.
Aunque podemos identificar las tres capas comunes de
responsabilidad: presentacin, dominio y origen de datos, en cada
aplicacin empresarial, la forma en que se separan depende de la
complejidad de la aplicacin. Un simple script para extraer datos
de una base de datos y mostrarlos en una pgina Web puede ser un
procedimiento. Todava me esforzara por separar las tres capas,
pero en ese caso podra hacerlo slo colocando el comportamiento
de cada capa en subrutinas separadas. A medida que el sistema se
vuelve ms complejo, rompera las tres capas en clases separadas.
A medida que aumenta la complejidad, dividira las clases en
paquetes separados. Mi consejo general es elegir la forma ms
apropiada de separacin para su problema, pero asegrese de hacer
algn tipo de separacin, al menos en el nivel de subrutina.

Junto con la separacin, tambin hay una regla estable sobre las
dependencias: El dominio y el origen de datos nunca deben depender
de la presentacin. Es decir, no debera haber ninguna llamada de
subrutina desde el cdigo del dominio o del origen de datos al
cdigo de la presentacin. Esta regla facilita la sustitucin de
diferentes presentaciones sobre la misma base y facilita la
modificacin de la presentacin sin mayores ramificaciones. La
relacin entre el dominio y el origen de datos es ms compleja y
depende de los patrones arquitectnicos utilizados para el origen
de datos.

Una de las partes ms difciles de trabajar es con la lgica de

dominio, parece ser que a la gente a menudo les resulta difcil
reconocer lo que es lgica del dominio y lo que es otras formas de
lgica. Una prueba informal que me gusta es imaginar la adicin de
una capa radicalmente diferente a una aplicacin, como una
interfaz de lnea de comandos para una aplicacin web. Si hay
alguna funcionalidad que tiene que duplicar para hacer esto, eso
es una seal de dnde se ha filtrado la lgica de dominio en la
presentacin. De manera similar, tiene que duplicar la lgica
para reemplazar una base de datos relacional con un archivo XML?

Un buen ejemplo de esto es un sistema del que me contaron que

contena una lista de productos en los que todos los productos que
se vendan ms del 10 por ciento que el mes anterior estaban
coloreados en rojo. Para ello, los desarrolladores colocaron la
lgica en la capa de presentacin que compar las ventas de este
mes con las ventas del mes pasado y si la diferencia era de ms
del 10 por ciento, establecieron el color en rojo.

El problema con eso es que est poniendo la lgica del dominio en

la presentacin. Para separar correctamente las capas, necesita un
mtodo en la capa de dominio para indicar si un producto tiene
ventas mejoradas. Este mtodo realiza la comparacin entre los dos
meses y devuelve un valor booleano. La capa de presentacin
simplemente llama a este mtodo booleano y, si es cierto, resalta
el producto en rojo. De esta manera, el proceso se divide en sus
dos partes: decidir si hay algo destacable y elegir cmo resaltar.

Estoy incmodo con ser demasiado dogmtico sobre esto. Al revisar

este libro, Alan Knight coment que estaba "indeseado entre si
simplemente poner eso en la interfaz de usuario era el primer paso
en una pendiente resbaladiza al infierno o una cosa perfectamente
razonable de hacer que slo un purista dogmtico se opondra". La
razn por la que estamos inquietos es porque es ambas.

Cmo elegir dnde ejecutar sus capas

En la mayor parte de este libro hablar de capas lgicas, es

decir, dividir un sistema en piezas separadas para reducir el
acoplamiento entre diferentes partes de un sistema. La separacin
en capas es til incluso si las capas estn todas ejecutndose en
una mquina fsica. Sin embargo, hay lugares donde la estructura
fsica de un sistema hace una diferencia.

Para la mayora de las aplicaciones IS la decisin es si ejecuta

el procesamiento en un cliente, en una mquina de escritorio, o en
un servidor.

A menudo, el caso ms sencillo es ejecutar todo en los servidores.

Una interfaz HTML que utiliza un navegador Web es una buena manera
de hacerlo. La gran ventaja de correr en el servidor es que todo
es fcil de actualizar y corregir porque est en una cantidad
limitada de lugares. No tiene que preocuparse por la
implementacin en muchos escritorios y mantenerlos todos
sincronizados con el servidor. No tiene que preocuparse por las
compatibilidades con otros programas de escritorio.

El argumento general a favor de ejecutar en un cliente es la

capacidad de respuesta o el funcionamiento desconectado. Cualquier
lgica que se ejecute en el servidor necesita un viaje de ida y
vuelta del servidor para responder a cualquier cosa que el usuario
haga. Si el usuario quiere probar la respuesta y ver la
retroalimentacin inmediata, ese ida y vuelta se interpone en el
camino. Tambin necesita una conexin de red para ejecutarse. La
red puede estar en casi todas partes, pero al momento de escribir
estas lneas no est a 31.000 pies de altura. Puede estar pronto
en todas partes, pero hay gente que quiere hacer el trabajo ahora
sin esperar a que la cobertura inalmbrica alcance Dead End Creek.
La operacin desconectada plantea desafos particulares, y me temo
que he decidido dejarlos fuera del alcance de este libro.

Con esos asuntos generales en su lugar, podemos ver las opciones

de capa a capa. EL origen de datos prcticamente siempre se
ejecuta slo en servidores. La excepcin es cuando se puede
duplicar la funcionalidad del servidor en un cliente
convenientemente potente, normalmente cuando se desea una
operacin desconectada. En este caso, los cambios en el origen de
datos en el cliente desconectado necesitan sincronizarse con el
servidor. Como mencion anteriormente, decid dejar esas
cuestiones para otro da -u otro autor.

La decisin de dnde ejecutar la presentacin depende

principalmente de qu tipo de interfaz de usuario desea. Ejecutar
un cliente enriquecido significa ejecutar la presentacin en el
cliente. Ejecutar una interfaz web significa que funciona en el
servidor. Existen excepciones -por ejemplo, operacin remota de
software cliente (como los servidores X en el mundo de Unix) que
ejecuta un servidor Web en el escritorio- pero estas excepciones
son raras.

Si est construyendo un sistema B2C, no tiene opcin. Cualquiera:

Tom, Dick o Harriet, puede conectarse a su servidor y Ud. no
querr rechazar a nadie porque insiste en hacer sus compras en
lnea con un TRS-80. En este caso, se realiza todo el
procesamiento en el servidor y se ofrece HTML al navegador para
que trate con l. Su limitacin con la opcin HTML es que cada
pequea decisin necesita un ida y vuelta desde el cliente al
servidor, y eso puede perjudicar la capacidad de respuesta. Puede
reducir algunos de los retrasos con los scripts del navegador y
los applets descargables, pero aquellos reducen la compatibilidad
de su navegador y tienden a agregar otros dolores de cabeza.
Mientras ms HTML estndar utilice, ms fcil ser la vida.

Esa vida fcil es atractiva incluso si cada uno de sus clientes de

escritorio es cuidadosamente construido por su departamento de IS.
Mantener los clientes actualizados y evitar errores de
compatibilidad con otro software son problemas que incluso los
sistemas con cliente-ricos simples tienen.

La razn principal por la que la gente desea una presentacin de

cliente enriquecido es que algunas tareas son complicadas para los
usuarios y, para tener una aplicacin utilizable, necesitarn ms
de lo que una GUI Web puede proporcionar. Cada vez ms, sin
embargo, se est logrando formas de hacer las interfaces Web ms
utilizables, y eso reduce la necesidad de una presentacin de
cliente enriquecido. Mientras escribo esto, estoy a favor de la
presentacin en la Web si es posible y del cliente enriquecido si
es necesario.

Esto nos deja con la lgica del dominio. Puede ejecutar toda la
lgica empresarial en el servidor o en el cliente, o puede
dividirla. Una vez ms, todo en el servidor es la mejor opcin
para facilitar el mantenimiento. La demanda para moverlo al
cliente es por la capacidad de respuesta o para el uso
desconectado.
Si tiene que ejecutar alguna lgica en el cliente, puede
considerar ejecutar todo all, al menos de esa manera, todo estar
en un solo lugar. Por lo general, esto va de la mano con un
cliente enriquecido: ejecutar un servidor Web en una mquina
cliente no va a ayudar mucho a la capacidad de respuesta, aunque
puede ser una forma de lidiar con la operacin desconectada. En
este caso, puede mantener su lgica de dominio en mdulos
independientes de la presentacin, ya sea con Transaction Script o
Domain Model. El problema con poner toda la lgica de dominio en
el cliente es que tiene ms que actualizar y mantener.

La divisin entre el cliente y el servidor suena como el peor de

ambos mundos porque no se sabe dnde pueda estar cualquier pieza
de lgica. La razn principal para hacerlo es que slo tiene una
pequea cantidad de lgica de dominio que necesita ejecutarse en
el cliente. El truco entonces es aislar esta pieza de lgica en un
mdulo autnomo que no dependa de ninguna otra parte del sistema.
De esta manera puede ejecutar ese mdulo en el cliente o en el
servidor. Esto requerir un poco de fastidiosa manipulacin del
cdigo, pero es una buena manera de hacer el trabajo.

Una vez que haya elegido sus nodos de procesamiento, debera

intentar mantener todo el cdigo en un nico proceso, ya sea en un
nodo o copiado en varios nodos de un clster. No trate de separar
las capas en procesos discretos, a menos que sea absolutamente
necesario. Hacer eso degradar el rendimiento y agregar
complejidad, ya que tendr que agregar cosas como Remote Facades y
Data Transfer Objects.

Es importante recordar que muchas de estas cosas son lo que Jens

Coldewey refiere como multiplicadores de la complejidad:
distribucin, procesamiento multi-hilos explcito, diferencias de
paradigma (como objeto / relacin), desarrollo multiplataforma y
requisitos de rendimiento extremos (como ms de 100 transacciones
por segundo ). Todos estos tienen un alto costo. Ciertamente hay
momentos en que tiene que hacerlo, pero nunca olvidar que cada uno
lleva una carga tanto en el desarrollo y en subsecuente
mantenimiento.