Desde una arquitectura muy conocida a una implementación caótica.

Todo el mundo habla de desarrollo en capas, los arquitectos de software en reuniones pomposas se llenan la boca con Acrónimos tales como SOA, Event Driven, AOP, OOP etc.

 

Los Developer escuchan esas conversaciones crípticas y piensan ufff que saben estos tipos, no soy digno de conversar con ellos.

 

Cuando terminan esas reuniones pomposas, los arquitectos se van para la casa y los Developer deben implementar todas esas maravillas,  muchas veces estos tipos de alta alcurnia computacional no bajan sus ideas cósmicas al nivel de la tierra, altura donde el software es construido y ejecutado.

 

Bajar de los 10.000 metros a tierra las arquitecturas, es el trabajo de la disciplina del diseño. Cómo implica trabajo, los arquitectos no lo hacen y muchas veces nadie lo hace y el Developer debe “asumir” esa responsabilidad.

 

Una de las principales falencias de la arquitectura en capas, es una guía clara de cómo manejar los datos de negocio entre esas capas. Por supuesto todos hablan de DALC, BLL, Entidades de negocio, CRUD, pero frecuentemente no se explica el escenario general y los criterios que se debe usar para las decisiones de diseño.

 

En este contexto aparecen preguntas como las siguientes:

 

  • ¿Cómo represento una entidad de negocio?
  • ¿Cómo represento una colección de entidades?
  • ¿Cómo represento la jerarquía?
  •  ¿Qué formato de datos usamos para acceder al DALC?
  • ¿Cómo me abstraigo de la capa de datos?
  • ¿Cuándo uso Store Procedure y cuándo no?

 

Estos temas son los en que la gente común, Developer y diseñadores, necesitan guías para hacer su trabajo del día a día. Por su lado los arquitectos pueden seguir en los 10.000 metros, repitiendo sus mantras y dibujando el futuro.

Un pensamiento en “Desde una arquitectura muy conocida a una implementación caótica.

  1. Diego

    Tomado el feedback, JuampaNo es fácil tarea, lo sé. A mí como arquitecto emergido de ex developer más de una vez me han desaprobado presentaciones por volar muy bajo al sugerir posibles detalles de implementaciónMe decían "estás más preocupado por la solución que por el negocio en sí"Por eso te decía que es difícil. El arquitecto finalmente es un equilibrista: le gusta el bits & bytes porque toda su vida pasada se quemó las pestañas con eso, pero a la vez tiene que explicarlo de manera que los tomadores de decisión lo entiendan y puedan apoyarlo (léase, financiarlo). Estos tomadores de decisión suelen no ser desarrolladores a un punto tal que en el mejor caso "alguna vez desarrollaron"Es lo que hay, master. Ojalá el mundo fuera otro que el que es pero cuando nacimos ya estaba así enchufado y andando. Como decía Mafalda, "paren el mundo que me quiero bajar"Felicitaciones por tu blog

    Responder

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s