Aggregate y Aggregate Roots – DDD

Saludos mis amigos.

Uno de los conceptos más utilizados dentro de la arquitectura DDD son los Agregados. He buscado documentación sobre   estos conceptos y encontré un artículo muy bueno que describe de manera sencilla y con ejemplos que son estos elementos.

Domain Driven Design
Domain Driven Design

En el dominio de un sistema hay cosas que inevitablemente deben ir juntas de la mano. Un Aggregate es precisamente ese conjunto de cosas. Un Aggregate Root es una Entidad (de las que ya hemos hablado) que mantiene unido y coherente dicho conjunto.

Un sencillo ejemplo

En un sistema de ventas, un Cliente puede tener una referencia a los Pedidos de ese cliente y un pedido debe tener referencia a las Líneas del Pedido (ítem, cantidad, precio del ítem, etc).

Se puede observar que un Pedido no tiene sentido sin un Cliente que haya realizado ese Pedido, y una Línea de Pedido no tiene sentido sin el Pedido. Son conceptos que van de la mano y por tanto se puede deducir que Cliente y Pedido es un aggregate y que Pedido y LineaDePedido es otro aggregate.

Ahora debemos deducir cual seria el aggregate root. Para esto, solo tenemos que mirar cual es la Entidad principal que actuaría de “punto de entrada”, o la entidad desde la cual “tiramos del hilo” para realizar las operaciones.

En este ejemplo está claro que la raíz de uno de los agregados es Cliente y la raíz del otro es Pedido. También se puede observar que, aunque Pedido actúa como root de LineaDePedidos, al ser éste un hijo de Cliente, no se considerará aggregate root principal para los repositorios del dominio.

¿Y todo esto para que?

La característica principal de un aggregate root es que actúa como un ente único que controla el acceso a sus hijos. Gracias a esto se mantiene la coherencia del conjunto. Básicamente provee un patrón para mantener la lógica de dónde pertenece realmente un ítem.

Es la entidad raíz la que expone las acciones a realizar para con sus hijos. Es el Cliente el que expone una acción para realizar un nuevo Pedido (Cliente.RealizarNuevoPedido) o para cancelarlo (Cliente.CancelaPedido). Esto nos permite encapsular las reglas y restricciones del dominio.

Si una restricción nos dice que un Cliente sólo puede tener 3 Pedidos abierto a la vez, es responsabilidad del Cliente (en la acción Cliente.RealizarNuevoPedido) el contar cuántos Pedidos tengo abiertos; si no llego al máximo debo realizar el nuevo pedido, y si no puedo realizar más pedidos debo notificarlo de alguna manera y no realizar el nuevo pedido.

Se aplica un caso parecido con respecto a Pedidos y LineasDePedido.

Otra característica que deben cumplir los aggregate root es que son las únicas entidades que retornan los repositorios. Nunca se debería poder obtener de la capa de persistencia un Pedido directamente. Debo obtener el Cliente y “tirar del hilo” para llegar al Pedido, o seguir “tirando del hilo” para llegar a una Línea de Pedido. Hay que “navegar” a través de las entidades raíces.

No dejéis que os engañe un experto del dominio que diga, por poner un ejemplo chorra, que hay que listar todos los Pedidos abiertos en el sistema independientemente del Cliente para que un operador les de el visto bueno o los marque como erróneos. Dado que es probable que por otro lado se necesite bloquear a un Cliente la capacidad de realizar un nuevo Pedido (debido a problemas con un cobro, una tarjeta de crédito bloqueada o cualquier otra cosa), una forma correcta de enfrentar esto sería recuperar del repositorio todos los Clientes que tengan algún Pedido abierto y mostrar esos Pedidos por pantalla. Cuando el operador los marcase como correctos, deberíamos utilizar una acción expuesta por el Cliente (Cliente.AceptarPedido) que aplicara las reglas y restricciones para con los Pedidos según el estado actual de ese Cliente.

En resumen

Los aggregates proveen un agrupamiento lógico de Entidades y Objetos-Valor. El aggregate root actúa de punto de entrada para ese conjunto, encargándose de las normas y restricciones que deban cumplir las colecciones de hijos.

Fuente: Articulo Original Agregados

Espero sea de utilidad.

Saludos.

Database First vs Model First vs Code First – Entity Framework

Saludos.

Para comenzar a trabajar con Entity Framework, podemos hacerlo mediante 3 enfoques diferentes para crear nuestro modelo conceptual.

Entity Framework - Modelo
Entity Framework – Modelo

Database First

El modelo conceptual se crea a partir de una base de datos existente.

Model First

Se crea el modelo conceptual y se genera la base de datos.

Code First

Nuevo a partir de EF 4.1. Un enfoque simplificado que permite mapear nuestras clases POCO a la base de datos usando convención, Data Annotations o Fluent API.

Que sea de utilidad.

Enlaces:

http://gustavoazcona.blogspot.com/2011/07/entity-framework-code-first.html

http://gustavoazcona.blogspot.com/2011/06/entity-framework-database-first.html

http://gustavoazcona.blogspot.com/2011/07/entity-framework-model-first.html

Saludos.

Objetos POCO, DTO – Entity Framework

Buenas mis amigos.

Hace ya varios días que vengo familiarizándome con la herramienta de Entity Framework. Cada día me encuentro con nuevos términos,  definiciones y nuevas tecnologías. Por lo que he decidido comenzar a tomar apuntes de todos ellos que se me presenten de ahora en adelante.

POCO – Plain Old CLR Object

Son las siglas de Plain Old C# Object, y se refieren a “clases simples” que no dependen de ninguna Framework. Es un término derivado del concepto del mundo Java: POJO. El término POCO se utiliza para contrastar un objeto “estándar” o simple de un objeto que está diseñado para ser utilizado con un complicado Framework de objetos, tal como un ORM, o bien para diferenciarlo de un objeto COM.

DTO – Data Transfer Object

Se refiere a Data Transfer Objects y es un objeto que por definición se envía y recibe dentro de un servicio (WS, WCF).  Básicamente son un molde para la información, donde el esquema se encuentra fuertemente tipeado.

Algunas de las ventajas de utilizar diseños que implementen este tipo de objetos son:

  • En cualquier punto del sistema la información puede ser validada, a partir de metadatos establecidos.
  • Mejora la comunicación entre los programadores, dándoles un mismo esquema de información, evitando conflictos.
  • Separa físicamente las capas del sistema, haciendo el código mucho mas limpio y reutilizable.
  • Proporciona mayor seguridad.

Aunque estos objetos pueden darnos una gran cantidad de ventajas, tienen una enorme desventaja la cual es la causante de su poco uso, y es el tiempo de desarrollo, ya que obliga al programador a tipear cada una de las entidades lógicas del sistema.

Una de las preguntas interesantes en el Grupo de Arquitectos .NET :

Que utilizariais para devolver la información en un servicio WCF donde en la capa de datos se esta ultilizando Entity Framework.

DTO o POCO?

Los objetos POCO contienen las propiedades de navegación.

Las respuestas la encontramos en un articulo escrito mas tarde por uno de los participantes basado en los comentarios y opiniones de miembros del Grupo:  Sobre WCF, DTO, POCO

Espero sea de utilidad.

Saludos.

Diseño Web Adaptativo

Hoy en día, la variedad de dispositivos existente en el mercado (Smartphones, Tablets, Smart TV, etc) ha provocado que la información disponible no sea accesible desde todos los dispositivos, o bien es accesible pero la experiencia de navegación es muy pobre. A partir de esta necesidad, el diseñador norteamericano Ethan Marcotte creó y difundió una técnica llamada Responsive Web Design (Diseño Web Adaptativo), el cual permite mediante el uso de estructuras e imágenes fluidas, asi como de media-queries en la hoja de estilo CSS, adatar el sitio Web al entorno del Usuario.

En Julio de 2008, el consorci W3C discutió, describió y aprobó esta tecnica bajo el titulo “One Web”. El concepto de “One Web” hace referencia a la idea de construir una Web para todos (Web for All) y accesible desde cualquier tipo de dispositivo (Web on Everything).

Con una sola versión en HTML y CSS se cubren todas las resoluciones de pantalla, es decir, el sitio web creado estará optimizado para todo tipo de dispositivos: PCs, tabletas, teléfonos móviles, etc.

Responsive Web Design
Responsive Web Design

De esta forma se reducen los costes de creación y mantenimiento, pues se evita tener que desarrollar aplicaciones ad-hoc para versiones móviles, por ejemplo, una aplicación específica para móviles Android, otra para iPhone, etc.5

Espero les sea de utilidad.

Algunos ejemplos de Web con diseño Adaptativo.

Demo 1 | Demo 2 | Best Demos

Saludos.

Principios de Diseño Orientado a Objetos – SOLID

Hace un par de semanas he comenzado a leer sobre Diseño Ágil con TDD (Test Driven Development) de Carlos Blé Jurado. Un libro con bastante ejemplos sobre TDD – Desarrollo Dirigido por Pruebas él cual recomiendo darle una lectura e introducirnos al Desarrollo Ágil con TDD.

En el cápitulo de Diseño Orientado a Objetos se describe la gran importancia de los principios de diseño orientado a objetos en términos de la gestión de dependencias  –  SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion), los cuales fueron introducidos por Robert C. Martin en 1995. Estos principios son los siguientes:

Principio de Única Responsabilidad – Single Responsibility Principle (SRP)

Cada clase debería tener un único motivo para ser modificada. Si estamos delante de una clase que se podría ver obligada a cambiar ante una modificación en la base de datos y a la vez, ante un cambio en el proceso de negocio, podemos afirmar que dicha clase tiene más de una responsabilidad o más de un motivo para cambiar. Se aplica tanto a clases como a cada uno de sus métodos.

Principio Abierto/Cerrado – The Open Closed Principle (OCP)

Una entidad software (una clase, módulo o función) debe estar abierta a extensiones pero cerrada a modificaciones.  el comportamiento de una entidad debe poder ser alterado sin tener que modificar su propio código fuente.  El nombre de Open-Closed se debe a Bertrand Meyer en 1998.

Principio de Sustitución de Liskov – Liskov Substitution Principle (LSP)

Introducido por Barbara Liskov en 1987. Si una función recibe un objeto como parámetro, de tipo X y en su lugar le pasamos otro de tipo Y, que hereda de X, dicha función debe proceder correctamente por el propio polimorfismo existente. El diseño por contrato (Design by Contract) es otra forma de llamar al LSP.

Principio Segregación de Interfaz – Interface Segregation Principle (ISP)

No obliguemos a los clientes a depender de clases o interfaces que no necesitan usar.  Tal imposición ocurre cuando una clase o interfaz tiene más métodos de los que un cliente (otra clase o entidad) necesita para sí mismo.

Principio de Inversión de Dependencias – Dependency Inversi´on Principle (DIP)

DIP explica que un módulo concreto A, no debe depender directamente de otro módulo concreto B, sino de una abstracción de B. Tal abstracción es una interfaz o una clase (que podría ser abstracta) que sirve de base para un conjunto de clases hijas.

Estos principios describen principalmente la gestión de dependencias entre clases, algo que no se ocupa el modelado tradicional ya que pone más énfasis en la conceptualización de clases.

Saludos!

Informe Sistema de Gestión de Compra y Venta

Saludos mis amigos.

En esta oportunidad y aprovechando las buenas noticias sobre nuestra Facultad de Ciencias de la Computación les comparto un pequeño informe de proyecto presentado en la materia de Arquitectura de Software en la Universidad Autónoma Gabriel René Moreno – Gestión 1 – 2011.

Docente: Ing. Josué Obed Veizaga Gonzáles

Caso de Estudio: Desarrollar una Aplicación para la Compra y Venta de Productos Genéricos.

El trabajo consistía en desarrollar la misma Aplicación pero aplicando la Arquitectura 3 Capas (Datos, Negocio y Presentación) y MVC (Modelo Vista Controlador), además que se pueda hacer uso de 2 Sistemas Gestores de Bases de Datos.

En ese momento estaba terminando de desarrollar un  proyecto en .NET es así que me decidí en primer instancia hacer uso de esta plataforma con C# sobre Base de Datos en SQL Server 2005 y MySQL.

Al final de cada unos de los documentos se adjunta los enlaces de descarga para cada una de las Plataformas (.NET y JAVA).

Informe de un Sistema de Compra y Venta de Productos  Arquitectura 3 Capas. 

 

Puedes descargar el proyecto pulsando en el siguiente enlace de descarga.

Descargar Proyecto Sistema de Compra y Venta Arquitectura 3 Capas en .NET

Informe de un Sistema de Compra y Venta de Productos Arquitectura 3 Capas con Hibernate. 

 

Puedes descargar el proyecto pulsando en el siguiente enlace de descarga.

Descargar Proyecto Sistema de Compra y Venta Arquitectura 3 Capas con Hibernate en JAVA

Informe de un Sistema de Compra y Venta de Productos Arquitectura MVC con Hibernate. 

 

Puedes descargar el proyecto pulsando en el siguiente enlace de descarga.

Descargar Proyecto Sistema de Compra y Venta Arquitectura MVC con Hibernate en JAVA

 

Espero les sea de mucha utilidad.

 

Hasta pronto.

 

 

Windows Communication Foundation Services + LINQ

Saludos amigos.

Les comparto un interesante artículo sobre Windows Communication Foundation Services + LINQ escrito por Edison Daniel García Chinas en su blog Tecnologías Microsoft. Un primer paso para quienes comenzamos a familiarizarnos con LINQ.

Lenguaje Integrado de Consulta - Microsoft
Lenguaje Integrado de Consulta

Windows Communication Foundation Services  + Linq Parte 1

Windows Communication Foundation Services  + Linq Parte 2

Un artículo bien explicado!

Saludos!