Cuando se mira la estructura de directorios del proyecto los ficheros fuente de paquete
de alto nivel estos deberían «gritar» cosas como «Health Care System» o
«Account System». Si por el contrario está gritando «Rails», «Spring/Hibernate»
la arquitectura no está siendo todo lo buena que esta debería ser.
El tema de una arquitectura
Ivar Jacobson, autor del libro Object Oriented Software Engineering, establece que
las arquitecturas son la estructura que dan soporte a los casos de uso del
sistema. Así que la arquitectura de una aplicación de software debería gritar
sobre los casos de uso de la aplicación.
Las arquitecturas no son y no deberían ser sobre los frameworks. Las arquitecturas
no deberían estar apoyadas por frameworks. Los frameworks son herramientas para
usarse y no arquitecturas con las que conformarse. Si una arquitectura está
basada en frameworks entonces esta no se puede basar en casos.
El propósito de una arquitectura
Las buenas arquitecturas están centradas en los casos de uso por lo que los arquitectos
son capaces describir estas estructuras que soportan esos casos de uso sin
comprometerse con frameworks, herramientas o entornos.
Una buena arquitectura software permite que las decisiones sobre frameworks, bases de
datos, servidores web, y otros temas de entorno y herramientas se retarden y
pospongan. Los frameworks son opciones a dejar abiertas. Una buena arquitectura
hace innecesario decidir sobre Rails o Django, Tomcat o MySql hasta mucho más
tarde en el proyecto. Una buena arquitectura hace facil de cambiar de opinión
sobre estas decisiones. Una buena arquitectura enfatiza los casos de uso y
desacopla estos de los aspectos periféricos.
Pero, ¿Que pasa con la web?
La web es un mecanismo de entrega y tu arquitectura debería tratar esta como tal. El
hecho de que la aplicación se entregue vía web es un detalle y no debería
influir en la estructura del sistema. De hecho, la decisión de que la
aplicación se entregue sobre la web debería aplazarse. La arquitectura del
sistema debería ser tan ignorante como sea posible sobre como esta se entrega.
La aplicación debería poder entregarse como aplicación de consola, una
aplicación web, un servicio web, etc. sin que hubiera cambios en la
arquitectura.
Frameworks son herramientas no maneras de vivir
Los frameworks pueden ser muy potentes y muy útiles pero es posible que puedan
llegar a tener un coste. Hay que pensar en cómo usarlo y cómo proteger la
arquitectura del mismo mediante una estrategia que prevenga el framework se
apodere de la arquitectura.
Arquitecturas testeables
Si la arquitectura de sistema alberga los casos de uso y se ha aplazado la decisión
del framework entonces se debería poder probar todos los casos de uso sin
necesidad del framework.
No se debería necesitar un servidor web o una base de datos para ejecutar los casos
de uso.
Las entidades deberían ser simples objetos que no tengan dependencias de los
frameworks, bases de datos u otras complicaciones. Los casos de usos deberían
coordinar los objetos entidad. Al final todos ellos juntos deberían ser
testeables in situ sin ninguna otra complicación.
Conclusión
La arquitectura debería aportar información a los lectores sobre el sistema y no
sobre las tecnologías usadas como el framework o la base de datos. Si se
construye un sistema de cuidado de salud cuando venga un nuevo programador al
proyecto la primera impresión de este debería ser un «vale, esto es un sistema
de cuidado de salud.»
Los programadores deberían poder ser capaces de aprender todos los casos de uso del
sistema sin saber como se entrega el resultado del sistema.
Si tenemos un sistema sólo con entidades y casos de uso y el nuevo programador pregunta
por las vistas y los controladores, entonces se podrá decir que eso son
detalles que no son necesarios en ese momento y que se podrá decidir más
adelante.
No hay comentarios:
Publicar un comentario