C++ / Domain-driven design

Bienvenidos sean a este post, hoy veremos otro concepto de diseño.

Que es un dominio? Podemos considerarlo como el concepto principal y los conceptos suplementarios a este, en nuestro caso va a ser todo la discusion y diseño de la plataforma de e-commerce. Por lo general, se sugiere utilizar este diseño para los proyectos pero tampoco es una panacea para el diseño de programas. Por esto siempre es recomendable diseñar tus proyectos teniendo en cuenta a las siguientes tres capas de la lista de tres niveles de arquitectura:

• Presentacion
• Logica del negocio
• Datos

La lista de tres niveles de arquitectura se aplica a software de cliente-servidor como es nuestra plataforma de e-commerce, comentemos cada una de las capas que mencionamos anteriormente.

La presentacion va a ser lo que provea al usuario la informacion relacionada con el producto, la posibilidad de comprar, envio y todo lo que interactue con el mismo. Este se comunica con otras capas para mostrar los resultados en pantalla, como ejemplo podemos tomarlo como la pagina que se vera en el navegador.

La logica del negocio es la que se encarga de la funcionalidad. Por ejemplo, un usuario navega por los disttintos productos enlistados por la capa anterior, y decide comprar uno de ellos. El procesamiento de esta tarea es lo que realiza esta capa. En domain-level design, tratamos de combinar las entidades a nivel de domino con sus atributos para abordar la complejidad de la aplicacion. Manejamos a los usuarios como objetos de la clase Usuario, los productos son objetos de la clase Producto, y asi sucesivamente. Tomemos esta situacion, el usuario realiza una compra y la logica de negocios lo interpreta como un objeto de Usuario creando un objeto de Orden, la cual esta relacionada al objeto Producto. A su vez, el objeto Orden esta ligado al objeto Transaccion que esta relacionada a la compra del producto. Y el resultado de todo lo comentado anteriormente se representa en la capa de presentacion.

La ultima capa, Datos, maneja el almacenamiento y recuperacion de datos. Desde la autenticacion hasta el envio del producto, pasando por la compra, listado y demas, toda accion es recuperada o almacenada en una o varias bases de datos.

Trabajar la aplicacion con estas tres capas nos permiten manejar la complejidad general. Por eso, es mucho mejor manejar objetos con una sola responsabilidad pero domain-driven design nos permite diferenciar entidades de objetos que no poseen una identidad conceptual. Tomemos como ejemplo la siguiente situacion. Los usuarios no van distinguir entre cada transaccion; ellos estan a la expectativa de la informacion que una transaccion representa. Y a su vez, el objeto del usuario tiene una identidad conceptual en la forma de la clase Usuario.

Las operaciones permitidas en objetos usando otros objetos (o no) son llamadas como servicios. Un servicio se puede considerar como una operacion que no esta vinculada a un objeto especifico. Como ejemplo, podemos establecer el nombre del usuario mediante set_nombre y esta es una operacion que no puede considerarse como un servicio. Pero la compra de un producto por el usuario si es encapsulada por un servicio.

Para ir terminando, podemos decir que domain-driven design incorpora intensamente patrones de repositorio y fabrica (factory). El patron de repositorio es responsable por los metodos para la recuperacion y almacenamiento de los objetos del dominio. El patron de fabrica se encarga de crear los objetos. El uso de estos patrones nos permite intercambiar implementaciones alternativas para cuando y si son necesarios.

En resumen, hoy hemos visto a domain-driven design, diseño basado en dominio, que es, como se utiliza, en que consiste realmente, y algunas situaciones donde se pueden aplicar. Espero les haya resultado de utilidad sigueme en tumblr, Twitter o Facebook para recibir una notificacion cada vez que subo un nuevo post en este blog, nos vemos en el proximo post.