Cuando salí de la universidad hace unos 10 años ya, la boga en esos días eran salir del clásico sistema monousuario todo en 1 y pasar a ambientes clientes-servidor. Bien, no era algo novedoso y ya existían  en el mercado productos que te prometían hacer esto de forma simple. Ha pasado el tiempo y todavía me da risa(de pensar que felices son como estan) cuando escucho que una organización es moderna porque esta en ambiente cliente/servidor cuando esta tendencia muto hacia otras cosas en el transcurso de estos años, no se realmente si para mal o para bien. Analicemos lo que ha ocurrido en estos 10 últimos años, o por lo menos lo que yo he vivido, me recuerdo que en esa epoca lo primero que se pensaba era en hacer una aplicación:

Pase los 10 últimos años haciendo aplicaciones que solo querían lo basico, grabar un dato a la DB y ver luego un reporte de esto; y que realice en el medio, una estratificación de capas tan complejas que el mantenimiento de la misma no es lo mas simple del mundo, tal vez olvide el principio fundamental del KISS y fui complaciendo a clientes o moviéndome de tecnologías  tal como el mercado me hacía ir o el cliente me exigía, pero en base a lograr arquitecturas que fuesen escalable fui creando tantas capas de desarrollo que mas que una solución simple parece la descripción geológica del planeta Tierra. Adicional ni siquiera describí las capas que encontramos normalmente en un Application Server(Messaging, DAO, Bussiness Components, etc.) sino nunca terminaría de describir esto.
Pudiéramos decir que esa empresa que dice que es moderna por usar una arquitectura cliente/servidor, hasta contento pudiésemos estar que se queden así y evitar a que vayan complicando su esquema de soluciones, se que muchos pensaran que en la simplicidad no esta la respuesta pero también hay que saber cuando dejar que las cosas funcionen de forma natural. Se que es inmantenible la lógica de negocios en un DB Server y que con esto estaríamos casando la aplicación con un manejador de DB en particular que de ser sustituido la migración de T-SQL seria un trabajo doloroso, pero cuantas veces suceden las migraciones de esta magnitud, cada 5 o 10 años?? Hasta que punto el ego, ya que es ego al fin por el nuevo reto, del Arquitecto, Coder o lider del proyecto hace que no simplifiquemos las cosas sino que busquemos complicarla cada día más.
El mundo Client/Server cada día cambia, ya no tenemos que la View sera un GUI-Client o GUI Web-Enabled sino un dispositivo mobil o un cualquier otra cosa que se nos ocurra(Google Maps por ejemplo que a pesar de se web enabled no es una aplicación de formas clasica), ya no manejamos una DB como nuestro repositorio ya que tal vez dialoguemos contra un Legacy, un ERP o un mismo dispositivo electrónico donde no tendremos capacidad de agregar logica de negocio en T-SQL pero estos casos no son la regla hoy por hoy  de el clasico 80-20 pero en un futuro cercano tal vez lo sean, el estar preparado para esto no esta mal, pero también se debe tratar de hacer las cosas simples en la medida de lo posible. Hace una semana y algo conversaba con un padawan sobre esto mismo, si tu aplicación es para un desktop de trabajo unitario, porque complicar la arquitectura de la misma a 8 capas?? Por que un paper de best practices asi lo indica?? O es porque tu ego lleva a esto? No esta mal acostumbrarse a trabajar bien pero hay que saber demarcar esa delgada línea entre satisfacer a nosotros mismos o hacer una solución simple pero que cumpla con los requisitos y sea fácilmente escalable en el tiempo. Tarea sencilla no es esto último pero en mi cabeza solo suena una canción…

Sonado en player Perenne:KISS-Rock and roll all nite