Los límites arquitectónicos
complejos son caros. Ellos requieren interfaces de límites polimórficos
recíprocos, estructuras de datos de entrada y salida, y toda la gestión de
dependencia necesaria para aislar los dos lados en componentes que se pueden
compilar y desplegar independientemente. Esto conlleva un montón de trabajo y
mantenimiento.
En muchas situaciones, un buen arquitecto podría juzgar que el gasto de dicho límite es
demasiado alto pero aún así podría querer mantener un lugar para dicho límites
en caso de que sea necesario más adelante.
Este tipo de diseño anticipado está mal visto por muchos en la comunidad ágil como una
violación de YAGNI: “You aren’t going to need it.” Los arquitectos sin embargo,
a veces miran el problema y piensan: “vale, pero podría.” En estos casos ellos
pueden implementar un límite parcial.
Saltar el último paso
Una manera de construir un límite parcial es hacer todo el trabajo necesario para crear
componentes que se puedan compilar y desplegar de forma independiente, y
entonces simplemente mantenerlos juntos en el mismo componente. Las interfaces
recíprocas están allí, las estructuras de datos están allí, y todo está
preparado pero se compila se despliega todo en un único componente.
Obviamente, este tipo de límite parcial requiere de la misma cantidad de código y trabajo
de diseño preparatorio que un límite completo. Sin embargo este no requiere la
administración de múltiples componentes. No hay una versión del número de
tracking o la carga de la administración de versiones. Esta diferencia no debe
tomarse a la ligera.
Esta fue la estrategia inicial detrás de “finesse”. El componente de servidor web de
“FitNesse” fue diseñado para ser separable de la wiki y comprobar par de
“FitNesse”. La idea fue que se podía querer crear otras aplicaciones web que
usaran este componente. Al mismo tiempo no se quería que los usuarios tengan
que descargar dos componentes. Hay que recordar que uno de los objetivos del
diseño era “descargar y listo”. Este fue nuestro intento en que los usuarios
descargarían un archivo “jar” y ejecutarían este sin tener que añadir otros ficheros
“jar”, resolver compatibilidades de versiones, etc.
La story de “fitnesse” también señala uno de los peligros de este enfoque. A medida que
pasó el tiempo, quedo claro que nunca sería necesario un componente web
separado, la separación entre el componente web y el componente wiki comenzó a
debilitarse. Las dependencias comenzaron a cruzar la línea en la dirección
incorrecta. Actualmente, separarlos sería una tarea difícil.
Límites de una dimensión
El límite arquitectónico completo utiliza interfaces de límites recíprocos para mantener
el aislamiento en ambas direcciones. Mantener la separación en ambas
direcciones es tanto en la fase inicial como en el mantenimiento.
En la Figura 24.1 se muestra una estructura más simple que sirve para mantener el lugar
para una extensión posterior a un límite completo.
Esto ejemplifica el tradicional patrón «Strategy». Los clientes usan una interfaz
«ServiceBoundary» y tiene una implementación en la clase «ServiceImpl».
Esto debería dejar claro que esto prepara el escenario para un futuro límite
arquitectónico. La inversión de dependencia necesaria está en su lugar en un
intento de aislar al cliente de su implementación «ServiceImp». Esto también
debería dejar claro que la separación puede degradarse muy rápidamente, como se
muestra por la línea punteada en el diagrama. Sin interfaces recíprocas, nada
previene este tipo de canal de vuelta más que la diligencia y la disciplina de
los desarrolladores y arquitectos.
Facades
El patrón «Facade» es un ejemplo de límite.
El límite viene definido por la clase «Facade» la cual lista todos los servicios como
métodos desplegando las llamadas a los servicios a cada clase que el cliente
supuestamente no tiene acceso.
La clase «Client» tiene una dependencia transitiva sobre todas las clases de servicios.
En lenguajes estáticos, un cambio al código fuente en una de las clases
«Service» forzará al cliente a recompilar.
Conclusión
Se han visto tres simples maneras para implementar parcialmente un límite
arquitectónico. Por supuesto hay otras maneras. Estas tres estrategias se
exponen como ejemplos.
Cada una de estas estrategias tiene su propio conjunto de costes y beneficios. Cada una de
ellas se adapta mejor a ciertos contextos, como un marcador de posición para un
límite completo. Cada uno también se puede degradar si el límite nunca se
materializa.
Una de las funciones de un arquitecto es decidir dónde un límite arquitectónico podría
existir un día y si se debe implementar ese límite parcial o totalmente.
No hay comentarios:
Publicar un comentario