He estado leyendo el artículo Understanding Spring Web Application Architecture: The Classic Way.
Creo que es un buen artículo porque explicita algo que no mucha gente hace en esta clase de cosas: cómo se distribuye la lógica del dominio en la arquitectura que propone. En este caso, la divide entre servicios, objetos entity, objetos value, etc … y aunque no lo haya puesto de manera explícita, es habitual que, en el mundo real, la lógica del dominio llegue a los controladores de las vistas. Precisamente ésa es la principal crítica que se le puede hacer: propone un modelo del dominio anémico, lo que supone problemas de testeabilidad y comprensión de las reglas del dominio, dos de las actividades que me parecen más fundamentales en el desarrollo de software. No es un problema menor.
Sin embargo, hay otra crítica que se le puede hacer a estos sistemas. Con un impacto igualmente importante, pero quizás más sutil y difícil de ver: tienen un mayor riesgo de quedarse obsoletos. Este tipo de sistemas tienden a ser usados (por su propia manera de ser) como un todo: usas desde el ORM que empaqueta hasta su sistema de directivas HTML/JS (que, obviamente, tiene sutilezas que lo hace distinto a HTML y JS). Suele ser complejo integrar cosas diferentes a las que te propone el framework. Esto hace que seas vulnerable en áreas donde exista gran volatilidad o innovación. Por ejemplo: hoy en día, es inmensa la innovación que se está dando en las interfaces con HTML y JS, tanto por la consolidación de nuevos estándares –HTML5, ECMAScript6– como por la propia dinámica de la industria que ha apostado fuerte por estas tecnologías en los últimos años. Por lo tanto, si usas un sistema de plantillas propio del framework que sea un sucedáneo de HTML y JS, estás invirtiendo en un conocimiento/tecnología específico que en breve tiene grandes posibilidades de quedarse obsoleto.
Hasta aquí la crítica. Me parece importante entender también el atractivo que tienen este tipo de sistemas todo-en-uno. Desde luego que son atractivos al inicio, ya que venden que puedes construir una aplicación en un par de días sin programar ni pensar sobre cómo hacerla. Probablemente sí puedas hacer alguna cosa muy rápido. Me imagino que las primeras semanas pueden ser un camino de rosas. Pero lo que veo en el mundo real es que, a medida que inviertes tiempo en un framework todo-en-uno, los riesgos de encontrarse con sus límites y quedarte bloqueado son altísimos: costes altos de mantenimiento por falta de integración de tests, semanas de desarrollo para hacer lo que parece una pequeña mejora porque supone revisar la lógica en varios lugares e implementar la nueva petición en otras tantas capas, interfaces que no son tan atractivas como las de los competidores, etc.
Para mí, estos son unos riesgos no menores que no asumiría a no ser que los pros fuesen espectacularmente altos. Y habitualmente no lo son. Es muy fácil dejarse llevar y no darse cuenta de estas sutilezas, pero es igualmente peligroso, porque entonces serán los clientes los que te pidan más de lo que puedes dar a un precio competitivo o directamente contraten a otra compañía que se lo pueda ofrecer. Por eso me parece que la selección tecnológica no es meramente una cosa técnica, sino que tiene un impacto muy alto en el futuro de los productos que tu empresa puede ofrecer y conviene tener en cuenta tu contexto y no tomársela a la ligera.
Leave a Reply