Primero que todo disculparme si alguien entra en este post pensando que voy a hablar de política 😛 siento que no sea así. Ya me sobra con el regaño que me dieron ayer por decir que “insidiar” era un verbo. 😉
Entrando en la materia que nos ocupa… Muchas veces cuando escuchamos hablar de arquitecturas del tipo DDD, TDD o N capas orientadas al dominio pensamos que todo eso es cosa de unos cuantos frikis que se pasan el día sin nada que hacer e intentando complicarnos la vida y, nada más lejos de la realidad. La arquitectura de un proyecto puede muchas veces llevarnos a escribir un mal código.
Ayer a un colega le pasó algo curioso respecto a eso. Introducir una arquitectura orientada al dominio en un grupo de trabajo con apenas experiencia es complicado, la curva de aprendizaje cuando se parte de cero es realmente alta y son muchos los conceptos y paradigmas que nos vemos obligados a cambiar. Entidades, DTO, Inversión de control, Inyección de dependencias, etc… todo esto puede ocasionar un retraso en el proyecto que nadie está de acuerdo en asumir.
Para evitar todo esto, diseñó una arquitectura N capas de toda la vida con posibilidades de dividirla en niveles, pero a su vez fue insertando conceptos como: Dominio, entidades, DTO, capas, niveles, servicios del dominio, repositorios, etc. toda una base que le permitiera en un momento dado, dar el cambio definitivo a arquitecturas verdaderamente orientadas al dominio.
Ayer se le presentó una problemática, necesitaba mandar a encender desde un panel de administración un conjunto de dispositivos por un tiempo determinado. Ya tenía funcionando toda la lógica de encendido y solo debía insertar el nuevo requerimiento de definir el tiempo que dicho dispositivo iba a permanecer encendido. La secuencia para encender dispositivos era la siguiente:
Con el nuevo requerimiento la secuencia quedó de la siguiente manera:
La solución dada no me gustó porque rompe con la naturaleza propia del método, se está actualizando estados en un método destinado a seleccionar. Esto evita que dicho método pueda ser reutilizado para lo que fue pensado, traer un listado de dispositivos.
Cuando le dije cómo lo hubiera hecho yo, el diagrama de secuencia quedó de la siguiente forma:
Ummm… ¿Qué pasa aquí? Yo viajo al dominio mediante los servicios WCF dos veces para realizar una acción. Al final, él pensó una solución que desde el punto de vista de arquitectura está mal, pero es mucho más eficiente que la mía.
¿Por qué nos pasa esto? Si miramos el último diagrama de secuencia vemos como si algo faltara en la arquitectura que permita hacerlo bien y además que sea eficiente. Si me llevo esto a DDD ¿cómo queda?
Diagrama de secuencia:
Feliz y contento… toda la lógica que estaba en el UI ahora pasa a mi capa de aplicación, por lo que solo viajaría una vez por la capa de servicios WCF y todo lo que está dentro del ApplicationLayer, podría ser reutilizado desde otros UI.
Nada, que llegamos a la conclusión que… es la hora del cambio J
Salu2