La arquitectura del software es el
arte de dibujar líneas a las que el tio Bob llama límites. Esos límites separan
los elementos de software unos de otros. Algunas de las líneas se dibujarán
incluso antes de que el código esté escrito mientras que otras se dibujarán en
fases más tardías. Los límites que se dibujan más temprano tienen el propósito
de posponer las decisiones durante el mayor tiempo posible y de evitar que esas
decisiones contaminen el núcleo de la lógica de negocio.
Hay que recordar que la meta principal de una arquitectura es minimizar los recursos
requeridos para construir y mantener el sistema requerido. El enemigo natural
es el acoplamiento.
¿Que tipo de decisiones se consideran prematuras? Son aquellas decisiones que no tienen
nada ver que con los requisitos de negocio. Esto incluye decisiones con el
framework, base de datos, servidores web, librerías de utilidad, inyección de
dependencias y similares.
Una buena arquitectura es aquella que no depende de las decisiones que no tienen que ver
con negocio y que, una vez se toman, no tienen un impacto significativo.
¿Qué líneas hay que dibujar y cuándo dibujarlas?
Pues se dibujan líneas entre las cosas que importan y las cosas que no importan. Por
ejemplo, la GUI no importa a las reglas de negocio así que debería haber una
línea entre ellas. La base de datos no importa a la GUI por lo que debería
haber una línea entre ellas.
Puede que alguno de estas afirmaciones choquen, sobre todo la que la base de datos no es
importante para las reglas de negocio. Aunque esta es un idea equivocada dado
que a las reglas de negocio les da igual en qué tipo de base de datos se guarde
y obtengan los datos. Esto permite poner la base de datos detrás de una
interface.
En la siguiente figura se puede observar como las reglas de negocio usan la interface
para salvar y obtener los datos. La clase «Database Access» implementa la
interface y dirige las operaciones de la base de datos actual.
En este caso, la línea se dibuja justo debajo de la interface.
Observe las dos flechas dejando la clase «Database Access». Esas dos flechas apunta fuera
de la clase «Database Access». Esto significa que ninguna de estas clases sabe
que la clase existe «Database Access». Si volvemos un poco más atrás podemos mirar el componente que contiene las reglas de negocio y el componente que contiene las reglas la base de datos y todos sus accesos a clases.
Si se observa la dirección de la flecha, la base de datos conoce sobre las reglas de
negocio pero las reglas de negocio no saben sobre la base de datos. Esto
implica que las clases «DatabaseInterface» viven en el componente «Business
Rules» mientras que las clases «DataBase Access» viven en el componente
«DataBase».
La dirección de la línea es importante dado que a la base de datos no le importan las
reglas de negocio pero «Database» no puede existir sin «BusinessRules».
Esto es así porque el componente «Database» contiene el código que traduce las llamadas
hechas por el componente «BusinessRules» en consultas a la base de datos y para
ello, el código que hace la traducción debe saber sobre «BusinessRules».
Teniendo definido el límite entre los dos componentes así como la dirección de la flecha
hacia las reglas de negocio se puede ver que las reglas de negocio podrían
utilizar cualquier base de datos. El componente «Database» se podría reemplazar
con distintas implementaciones ya que a las reglas de negocio no le importan.
¿Qué hay sobre la entrada y la salida?
Los usuarios tienen que tener alguna manera de poder comunicarse con el sistema y esta
responsabilidad suele recaer en la GUI del sistema. Esta debe tener los
componentes necesarios para la entrada y salida de datos para un usuario pero
sería un error considerar que la GUI pertenezca a las reglas de negocio.
De hecho, se podría rehacer toda la GUI sin que las reglas de negocio cambien. Por
ejemplo, se podría rediseñar toda la interfaz web de un sistema y tener las
mismas reglas de negocio.
Esto lleva dibujar un límite entre las reglas de negocio y al GUI.
Nuevamente, la dirección de la flecha establece qué componente conoce sobre la existencia
del otro y, por lo tanto, qué componente se preocupa por el otro. La GUI sabe sobre las reglas de negocio.
Arquitectura de plugins
Si la GUI es un componente que del cual las reglas de negocio no sabe nada al igual que
la base de datos, se podría considerar un tipo de patrón para añadir nuevos
componentes. Este patrón es el mismo que se usa por los sistemas que permiten
plugins de terceros.
En realidad, la historia del desarrollo de software es la historia de cómo crear plugins convenientemente para establecer una arquitectura de sistema escalable y mantenible. Las reglas de negocio están guardadas separadas de un aquellos componentes que ni son opcionales o que pueden estar implementados de muchas formas diferentes.
Como en este diseño la interfaz de usuario se considera como un plugin es posible
añadir muchos plugins diferentes de interfaz de usuarios. Estos plugins podrían
estar basados en WEB, SOA, consola, o cualquier otro tipo que se nos pueda
ocurrir.
Lo mismo se podría aplicar para la base de datos. Desde que se ha diseñado como un plugin,
la base de datos se podría reemplazar con cualquier base datos SQL, No-SQL,
archivos de texto, o cualquier otro tipo de tecnología para almacenar datos.
Reemplazar un plugin con otro podría no ser trivial dado que si el desarrollo inicial de
nuestro sistema estaba basado en web entonces escribir un plugin para un
cliente-servidor podría ser un reto.
El argumento plugin
Ordenar el sistema con una arquitectura de plugins crea barreras en las cuales no se
pueden propagar los cambios. Si la interfaz de usuario se conecta con las
reglas de negocio entonces los cambios en la interfaz no afectan a las reglas
de negocio.
Ordenar el sistema con una arquitectura de plugins crea barreras en las cuales no se
pueden propagar los cambios. Si la interfaz de usuario se conecta con las
reglas de negocio entonces los cambios en la interfaz no afectan a las reglas
de negocio.
La interfaz de usuario cambia de diferente manera y en diferentes tiempos que las reglas de
negocio por lo que debería haber un límite entre ellos. Las reglas de negocio
cambian en diferentes tiempos y por diferentes razones que los frameworks de
inyección de dependencias así que debería haber un límite entre ellos.
Eso es simplemente el Principio de responsabilidad única de nuevo, este nos dice dónde
dibujar los límites.
Conclusión
Para dibujar las líneas de los límites en una arquitectura software primero hay que
particionar el sistema en componentes. Algunos de aquellos componentes son las
reglas de negocio, otros son plugins que contienen funciones necesarias que no
están directamente relacionadas con el núcleo del negocio. Entonces se ordena
el código en estos componentes de manera que las flechas entre ellos apuntan en
una dirección, hacía las reglas de negocio.
Se debería reconocer esto como una aplicación del Principio de inversión de dependencias y
el principio de abstracción estable. Las flechas de dependencia están ordenadas
para apuntar de niveles más específicos a niveles más altos de abstracción.
No hay comentarios:
Publicar un comentario