Se hace camino al andar…

Hace ya varios meses que me estoy leyendo el libro de Eric Evans titulado “Domain Driven Design”. Su lectura está siendo muy reveladora porque, por ejemplo, me ha terminado de convencer de la necesidad de evitar los modelos anémicos frente a los modelos ricos. Pero hoy me he leido un artículo publicado en InfoQ sobre DDD que me “he bebido casi inmediatamente” y que ha resultado incluso más clarificador que el libro de Evans (que prometo terminar de leer, por supuesto).

El artículo de Srini Penchikala es denso: no es el típico articulito (como éste que estáis leyendo ahora mismo) que comenta de pasada, sin profundizar, uno o dos artículos más o menos conocidos, sino que aporta una estructura en el discurso y contenidos que aclaran mucho las ideas.

El autor explica qué aporta DDD en cada momento del desarrollo de una aplicación y cómo lo hace. Explica la sinergia entre DDD y SOA y llega incluso a hablar de cómo debe ser el framework en el que basemos nuestro desarrollo: POJOs, DI y AOP y, por supuesto, para todo debemos poder hacer pruebas unitarias lo más fácilmente posible.

Me gustaría destacar el comentario que hace sobre el uso de anotaciones y, en particular, la propuesta de uso de las anotaciones @Configurable, @Repository o @Service que ofrece Spring y que ya estoy tardando en probar.


Quiero sacar tiempo de donde sea para poder probar la aplicación de ejemplo. Tengo muchas ganas de ver cómo ha resuelto:
a) la separación finísima que suele existir entre capa de presentación y de aplicación
b) las distinción entre validaciones y reglas de negocio.
c) la separación a veces difícil de explicar (y justificar su existencia) entre objeto del dominio, “repositorio” y DAO

Creo que ahí es donde solemos fallar todos al implementar cualquier arquitectura, por bien definida que esté ésta en “la pizarra”. Bueno, yo más porque me temo que en mi proyecto actual tengo todos y cada uno de los “tufillos” (“smells”) que indica Penchikala que deberían ser evitados.

Me ha dejado absolutamente intrigado la referencia que hace sobre ROO (Real Object Oriented), que por lo que he podido encontrar haciendo “googling” ha sido que es un “toolset” que están preparando desde hace años los de SpringSource, pero del que aún no se ha liberado nada. De todos modos, quizás no sea mala idea echar de una vez por todas un vistazo a Grails, visto lo productivo que puede ser si se usa con la orientación adecuada.

Me ha gustado también mucho cuando enfatiza el uso de generadores de código porque coincido plenamente en la necesidad de identificar qué pasos del desarrollo se pueden automatizar y usar frameworks para ello. Éste es mi objetivo desde hace años, aunque todavía no he conseguido encontrar la combinación adecuada; quizás porque siempre termino cayendo en la trampa de los “dominios anémicos” y las “capas de servicio hinchadas” (“fat service layer”) con la vana esperanza de ahorrarme lineas de código.

Y por último, me apunto la idea de usar BNLs para especificar reglas de negocio o comportamientos de los sistemas (vamos, para hacer BDD o ATDD). Ahí, la sinergia con herramientas como Concordion resulta evidente…

Bueno, lo dicho, a ver si consigo sacar una tarde o dos para ver con detalle el código de la aplicación de ejemplo y saco alguna conclusión más. De momento, “en la pizarra” todo es muy, muy prometedor.

En DEGESYS hemos lanzado una iniciativa formativa poco frecuente. Se trata de un Grupo de Estudio formado por voluntarios en el marco del cuál, todas las semanas, se estudia un tema (alguien se lo prepara especialmente) y se hace una puesta en común con el objetivo de asegurar una mejor comprensión de los conceptos. Para esto nos hemos basado principalmente en el trabajo de Joshua Kerievski titulado “Knowledge Hydrant: A Pattern Language for Study Groups”, donde se explica cómo organizar con éxito un Grupo de Estudio.

Lo hemos nombrado GeDOS (Grupo de Estudios “Diseño Orientado a Servicios”) porque justamente queremos centrarnos en aumentar nuestro conocimiento sobre este tema en particular y tratar de cubrir así nuestras necesidades de formación en este terreno dado que no encontramos nada en España ni fuera de España (a un precio razonable, claro).

El primer material de estudio que hemos decidido (y que ahora mismo debería estar yo estudiando, puesto que soy el ponente de la primera sesión) es el capítulo 4 del libro de Thomas Erl “SOA: Principles of Service Design”, titulado “Service Orientation” y que, para que os hagáis una idea, son apenas 30 páginas y es básicamente una introducción al paradigma SOA y a los retos que hay que enfrentarse cuando se diseña en base a este modelo. El próximo jueves nos reuniremos en un VIPS cerca de la oficina, mientras tomamos un café y pondremos en común las conclusiones que cada uno haya sacado del estudio. Espero que el fin de semana pueda haceros partícipes de esas mismas conclusiones porque la idea es publicarlas también en nuestro wiki, con lo que no me debería costar nada ponerlo en el blog porque lo difícil ya estaría hecho.

Lógicamente, no descartamos poder abrir el Grupo de Estudio a personas fuera de DEGESYS, con todas las ventajas que eso supondría para la compañía (darse a conocer a profesionales cualificados del sector) y para los propios miembros del Grupo de Estudio (ampliar la red de contactos y enriquecerse con conocimientos y puntos de vista “extramuros”), pero de momento vamos a rodar la iniciativa y ya iremos sacando conclusiones de esta experiencia. También estamos pensando en organizar otros Grupos de Estudios sobre otros temas, pero “piano, piano si va lontano”…

Por cierto, quería aprovechar para saludar a Jose Moreno, que ha dejado Cap Gemini para unirse a nuestro Departamento de Desarrollo como arquitecto. Estoy seguro de que vamos a aprender mucho juntos. De momento ya le he enredado para que se una al GeDOS.

Acabo de encontrar otro artículo similar al anterior donde se trata (aunque tangencialmente) bastante más acertadamente (en mi opinión) la diferencia entre OO y SO.

Permitidme que plagie tal cual el contenido del apartado que me interesa resaltar:

SOA and object orientation

Some practitioners consider SOA a direct evolution of OO, considering services as objects or components on steroids (see Resources [10]). This is as far from reality as it can get. The similarities do not extend beyond system decomposition for definition and encapsulation for implementation.

Additional features of objects, such as inheritance and polymorphism, are not applicable to SOA. What really sets the two apart is usage and programming model (similar to the differences between instance-based and service-based collaborations, described in Resources [11]).

• In OO, multiple object instances of the same type (potentially existing simultaneously) are distinguished based on their internal state, representing a particular execution context. As a result, the object’s life cycle is controlled explicitly by its consumer through an object creation.

  Every object exposes multiple methods, which are bound to a particular instance (execution context) and allowed to manipulate variables on a given instance.

• In SOA, services support not the execution context of a particular consumer but rather the state of the enterprise resources associated with the particular service. Typical service invocation is stateless; the notable exception to this rule is a conversational composite service, which typically has an execution context, supporting a particular conversation.

  As a result, the service life cycle is not associated with a life cycle of any particular consumer — it exists regardless of whether a particular consumer invokes it or not. The resulting programming model is the direct invocation of the service, without its explicit creation.

This difference has a profound impact on the interface definition for objects and services. In OO, multiple methods defined on the interface always physically belong to the same instance of the object because they are bound to the same execution context. In contrast, since services don’t have an execution context, the association of methods in the service interface is purely logical.

The service (and consequently service interface) effectively represents a namespace providing a logical grouping of service methods, which are otherwise independent entities with their own quality of service requirements, security, versioning strategy, endpoint address, and so on. To make a programming language analogy: every method of the service is similar to a FORTRAN subroutine/function, which can exist and be executed independently from others.

Este artículo trata también sobre una “vieja” discusión (al menos nosotros la hemos tenido en Degesys) sobre si los servicios deben ser sin estado o con estado… lógicamente han ganado los servicios sin estado porque es lo que toda la literatura explica, pero al menos a mi me queda la duda de… ¿y cómo se hace entonces una cesta de la compra en una arquitectura orientada a servicios? ¿Se persiste siempre la cesta de la compra en la base de datos, se guarda en la sesión web o se tiene un SFSB entre la aplicación web (o swing) y los webservices?

Por lo demás, el artículo es realmente muy completo y clarificador. Os lo recomiendo.

Por fin he encontrado un artículo donde se compara la orientación a objetos y la orientación a servicios. Además, de paso, explica también bastante claro cómo se debe diseñar orientado a servicios.

Lo que puede parecer un poco chocante es que no se dice por qué en SOA se prescinde de cualidades de la orientación a objetos (OO) largamente probadas en la ingeniería del software. Se dice que:

Como frecuentemente se crea un modelo de caso de uso aislado para cada dominio del problema (y por tanto para cada projecto de desarrollo) el dibujo a gran escala de la empresa queda difuminado en muchos casos. Es más, por varias razones, los modelos de caso de uso no siempre están sincronizados con sus homólogos BPM (modelos de procesos de negocio).

Es como si todo el mundo hubiera concluido que OO es muy difícil para esos miles y miles de programadores tontos, que abundamos por doquier y que no somos capaces de entender los procesos de negocio (a la vista están los resultados). Si os digo la verdad, creo que tienen parte de razón porque todos los días compruebo que somos artesanos del software (con todo el respeto para los artesanos, por supuesto), de modo que no se puede confiar mucho en nosotros para construir productos que realicen todo lo que quieren los clientes…

Conceptualmente, en SOA hay 3 niveles de abstracción principales:

• Operaciones: Transacciones que representan unidades lógicas de trabajo individuales. La ejecución de una operación causará normalmente que se lean, escriban o modifiquen uno o más registros de datos persistentes. Las operaciones SOA se comparan directamente con métodos OO. Tienen una interfaz específica y estructurada y devuelve respuestas estructuradas. Igual que para los métodos, la ejecución de una operación en particular puede conllevar la invocación de otras operaciones.
• Servicios: Representan agrupaciones lógicas de operaciones. P.ej., si vemos el PerfilDeCliente como un servicio, entonces Buscar Cliente por número de teléfono, Listar clientes por nombre y código postal y Guardar datos de un nuevo cliente representan las operaciones asociadas.
• Procesos de Negocio: Son un conjunto de acciones o actividades que se ejecutan con objetivos de negocio específicos en mente. Los procesos de negocio normalmente coordinan varias llamadas a otros servicios. Ejemplos de procesos de negocio son: Crear un nuevo empleado, Vender productos o servicios y Completar pedido.
  En términos SOA, un proceso de negocio consiste en una serie de operaciones que son ejecutadas en un orden secuencial de acuerdo a un conjunto de reglas de negocio. La secuenciación, selección y ejecución de operaciones es dnominado coreografía de servicios o procesos. Normalmente, servicios coreografiados son invocados a fin de responder a eventos de negocio.

Quedaría discutir cuál cómo debemos diseñar los componentes que implementan estos servicios. Supongo que depende un tanto del grano del componente en cuestión, pero sospecho que, dado que los servicios de más bajo nivel (las operaciones) son equiparables a los métodos de un objeto, no toca mucho hablar de OO en este punto, y si subimos al nivel superior, los procesos de negocio se definen como algo casi procedural (un programa BPEL es muy parecido a un programa COBOL) Nos quedaría ver qué pasa justo en medio… en la capa de servicios de negocio… pero creo que es mejor dejar para otro momento la discusión entre modelo rico y modelo anémico… :$