Como lo había comentado hace un par de semanas atrás en la página de Facebook. Quiero y deseo crear una aplicación web para gestionar el proceso de publicación y adopción de mascotas. Será un proyecto de código abierto y le he puesto por nombre «ASM – Agente Salvavidas de Mascotas». La idea principal es crear una comunidad de personas dispuestas a salvar y mejorar la calidad de vida de mascotas abandonadas en las calles o puestas en adopción, ofreciéndoles esta herramienta para facilitar y gestionar el proceso de encontrarles un hogar.
¿Quieres ser parte del proyecto?
El proyecto estará escrito usando tecnología Microsoft .NET con C# 6.0 como lenguaje de programación, NET Framework 4.6.1, inicialmente con ASP.NET Web API como Framework de Servicios, etc.
He creado el repositorio en GitHub con la solución en blanco.
Características:
Gestionar Mascotas para Adopción
Gestionar Candidados de Adopción de Mascotas
Gestionar Estados de Publicación de Mascotas
Arquitectura del proyecto Domain Driven Design
Patrones de diseño Unidad de Trabajo, Repositorio, Inversión de Control e Inyección de Dependencias, Dtos, etc.
Autenticación Web API 2 OAuth Bearer Tokens
API REST bajo ASP.NET Web API 2
Entity Framework con Code First
Seguridad de Usuarios con ASP.NET Identity (Por definir)
Implementación de Pruebas Unitarias
Repositorio de Codigo GitHub
Como pueden ver, inicialmente el proyecto será creado como servicio usando ASP.NET Web API como Back-End. Espero que sea un proyecto de utilidad y sirva como base para futuros proyectos.
En los próximos días estaré compartiendo y actualizando las primeras actividades a desarrollar en el proyecto en el Tablero de trabajo de GitHub
De igual manera, si encuentras errores en el proyecto, o tienes algunos comentarios / sugerencias puedes enviarlas al área de Issues de GitHub, o al correo: uialberto@outlook.com
Iniciamos una serie de publicaciones sobre los principios SOLID. Los principios S.O.L.I.D. son un conjunto de diseños y buenas prácticas que se emplean en OOD y OOP (diseño y programación orientada a objetos). Estos principios fueron desarrollados y publicados por primera vez por Robert “Tío Bob” Martin hace más de una década. En esta oportunidad detallaremos el primero de los principios, el Principio de Responsabilidad Simple. Este principio nos dice:
«There should never be more than one reason for a class to change»
«No debe existir mas que una sola razón para que una clase cambie»
El punto es que todos los atributos y todas las operaciones de una clase deben estar intrínsecamente relacionados con un solo propósito. Si se encuentra que al modificar una clase tiene dos responsabilidades se debe separar en dos clases respectivamente. Una clase que hace muchas cosas, es muy grande o muy complicada de seguro tendrá mas de una sola responsabilidad.
Para comprender mejor este principio vamos a ejemplificar mediante un diseño de clases.
Diagrama Clases – Violación al Principio de Responsabilidad Simple
El anterior diagrama muestra la violación del principio de responsabilidad simple ya que vemos que la clase Cuenta tiene más de una responsabilidad, esto se lo puede verificar mediante el método Transferir. Si bien tiene sentido que podamos transferir dinero de una cuenta a otra, vemos que se viola este principio al darle la responsabilidad a la clase Cuenta para dicho propósito. Esta operación debe ser sacada de la clase y llevada a otra que podemos llamar por ejemplo ServicioTransferencia, así nuestra clase Cuenta solo tendría operaciones relacionadas a ella misma.
Veamos como seria una posible solución a la violación del Principio de Responsabilidad Simple.
Solución a Violación al Principio de Responsabilidad Simple
Mediante este nuevo diseño podemos verificar la única responsabilidad para cada clase. Se ha delegado la responsabilidad a la clase ServicioTransferencia de Transferir dinero de una cuenta origen a una cuenta destino.
Ventajas de Aplicar este principio
Código más fácil de escribir y de entender.
Menos propenso a errores, ya que cada clase tiene una única responsabilidad bien definida
Facilita las tareas de testing : tenemos bien definido que debemos testear en cada clase.
Facilita las tareas de mantenimientos
Hace que nuestro código sea más robusto y extensible.
Hace un par de semanas acordamos con un grupo de amigos el de realizar una serie de presentaciones en el que cada uno buscaría un tema en particular y expondría el mismo para todos. Si bien no tenemos una fecha oficial para la realización del mismo, ya tengo lista mi presentación. Algunos temas a tratar: Programación con Silverlight, Servicios Web, Team Foundation Server y Principio Inversión de Dependencia. Una buena iniciativa para compartir conocimiento.
Principio Inversión de Dependencia. No es una presentación con efectos visuales elegantes, pero si trato de enfatizar y puntualizar los conceptos más importantes dentro de lo que es SOLID.
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
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.
Alberto Baigorria 