El back será la parte más robusta del sistema. No importa si carga muchas librerías, archivos, etc. Se sobreentiende que la frecuencia de cambio del contenido es mucho menor que la frecuencia de acceso al mismo (consultar Anexo, ‘Relativización de los contenidos dinámicos’).

La principal abstracción organizacional que planteo para el back, se define como Componente. Un componente tendrá la esencia del patrón MVC, como el primer ejemplo planteado, pero dentro de un marco de trabajo con más niveles. Un componente tendrá sus propias vistas y modelos,  también podrá acceder a modelos de otros componentes si así se requiere, a las librerías comunes, a la aplicación cargada, etc.

Lo organización del código en componentes es de gran utilidad en la creación de sistemas complejos y escalables.

A pesar de que aumentar el número de capas de abstracción en nuestro código puede traer ventajas, también puede suponer la creación de más código, archivos y en general 'burocracia' del framework para empezar a trabajar. No cabe duda que cuanto más definida está la arquitectura de nuestro software, más reglas e interfaces tendremos que cumplir.

Aún así, sin duda son más las ventajas que inconvenientes en contextos como el mencionado:

• Cada componente se comporta como una mini aplicación en sí misma, cumpliendo las reglas del entorno sí, pero con su funcionalidad propia y encapsulable.

• Permite el trabajo en equipo, ya que diferentes miembros pueden trabajar en diferentes componentes de manera independiente, haciendo crecer el sistema en paralelo.

• Mantener diferente versionado en cada componente. Se puede actualizar el front sin afectar al back, o actualizar componentes determinados sin afectar la estabilidad del resto de la aplicación.

• No perder el foco. Si el modelo de negocio resulta ser desarrollar un software en una línea concreta, evitar que las peticiones de los clientes hagan de la aplicación un parche encima de otro, desarrollar componentes a medida y activar o desactivar su funcionamiento.

• Reutilizar componentes. Se puede generar un sistema a medida activando y desactivando componentes. Aunque las necesidades de dos supuestos clientes pueden parecer muy diferentes, desde el punto de vista de las soluciones tecnológicas y del software, seguro tiene muchas cosas en común, y la propuesta es reutilizar esas funcionalidades análogas que no forman parte de su modelo de negocio.  

Se puede ver en este diagrama un resumen de la arquitectura propuesta para el back.

En comparación con el gráfico inicial del patrón MVC, vemos una Application más cargada, la agregación de librerías, y sobre todo los componentes, organizados bajo el mismo patrón, pero como mini aplicaciones en sí mismas, que comparten un entorno, y que pueden interrelacionarse, como vemos en el caso del componente noticias, que importa el modelo secciones de otro componente. Creo que este planteamiento resulta muy conveniente por las ventajas ya comentadas.