ASP.NET MVC y otras Yerbas - Parte 1

Este es la primera parte de una serie de post en la que veremos como crear una aplicación ASP.NET MVC y como se pueden aplicar todos esos términos raros(DDD, IOC, TDD, BDD, ATDD, Test Double……) que existen actualmente dentro del desarrollo de software.

Para esto vamos a tomar como ejemplo el desarrollo de una pequeña aplicación que sirva como “Bolsa de Trabajo” donde las personas puedan llenar sus datos y luego postular a anuncios de trabajo de otras empresas

A continuación tenemos unos  Mockups (Prototipos) para darnos una idea de lo que queremos lograr con la aplicación:

image  image

Estos prototipos han sido creados con una estupenda aplicación llamada Balsamiq Mockups, tiene una opción de trial en el que se puede probar todas sus opciones pero no puedes grabar tu trabajo, de todas maneras siempre podremos hacer un print-screen =).

Ahora toca el turno al diseño de la aplicación, para esto haremos uso de un término muy hablado y usado hoy en día, este es “DDD” (Domain Driven Design), Pero que significa esta cosa, “DDD es un conjunto de patrones, principios y prácticas que nos ayudan a resolver y entender los problemas del negocio (dominio) en el diseño de sistemas orientas a objetos” (Yo), en pocas palabras es:

“OO software done right” Casey Charlton

La definición de DDD no estaría completa sin explicar el “Ubiquitous Language”. Desde los inicios del desarrollo del software surge la necesidad de contar con un lenguaje común que sea entendido de la misma manera por todos los involucrados en el desarrollo del software ( expertos del negocio, analistas, desarrolladores, etc) , este lenguaje no solo debe ser entendido de la misma manera sino también debe estar presente en todas partes (ubiquo) que se hable del software, y esto incluye las clases, métodos, variables, etc dentro del sistema.

Para complementar lo anterior, voy a mostrar una imagen que ha sido extraída y traducida de la presentación de DDD en el VAN (Virtual ALT.NET) realizado por Steve Bohlen.

image

Dentro de los patrones descritos en la imagen, observamos en la parte superior a los patrones de Diseño de la Solución, estos patrones se enfocan en como es que realmente se va a resolver el problema para el cual se esta diseñando e implementado el software, y allí es donde se encuentra DDD, A continuación tenemos algunos recursos para profundizar más en el tema :

- Libro de Eric Evans, principal referencia sobre DDD
- DDD Quickly, resumen del libro de Eric Evans
- Virtual ALT.NET sobre DDD, presentación en video sobre DDD
- DDD Step by Step
- Slides sobre DDD

Luego de aplicar DDD a la arquitectura de nuestra aplicación tendríamos la siguiente estructura dentro de una solución del Visual Studio:

image

Explicando muy brevemente cada uno de los proyectos creados:

- Web: No hay mucho que decir acá, en este proyecto se encontrarán nuestras páginas web (views) con las cuales interactuará el usuario final a través de un navegador.

- Controllers: Es una de las partes fundamentales del modelo MVC y que marca la diferencia ante del desarrollo con WebForms. Los controllers son los encargados de manejar el flujo de la aplicación, es decir son ellos los que manejan las peticiones(request) de los usuarios y deciden cual es la vista que se encargará de mostrar la respuesta(response) en la pantalla. Un punto importante que nos podemos dar cuenta en la solución es que los controllers se encuentran en un proyecto separado de las vistas O.o .  En este artículo de Billy McCafferty, el creador de S#arp Architecture, explica porque esta es una buena decisión.

-Domain: Es el corazón de la aplicación y aquí es donde se encontrará representado el “dominio” del negocio y todas sus reglas. Un punto importante a aclarar es que el dominio y en general todo DDD es Persistence Ignorance, esto debido a que DDD se basa en el negocio y no en como se realizará la persistencia ( una u otra base de datos, xml, archivos de texto ,etc).

Pero de alguna manera tenemos que mantener el estado de los objetos de nuestro dominio y es por esto que en DDD se habla de repositorios (repository pattern) ya que estos a diferencia de una capa de datos no tratan de filas o columnas sino de colecciones de objetos. En el dominio tendremos el contrato o la interfaz hacia estos repositorios pero no la implementación real, ya que no le corresponde al dominio sino es una tarea de la infraestructura de la aplicación.

- ApplicationServices: Este proyecto está directamente relacionado con lo propuesto por  DDD, realmente el nombre de este término trae muchas confusiones, una definición es la siguiente:

“An application service layer defines a set of services that act as boundary to the domain layer. Any interaction with the domain layer passes through these application services. The application services interface with domain and infrastructure layers to get the job done. The domain layer also can talk to infrastructure layer” Kaushik

Ahora en terrestre, es la puerta de acceso del mundo exterior a nuestro dominio, en este caso ese mundo exterior se refiere a nuestros controllers pero también se puede referir por ejemplo a otras aplicaciones a las cuales estemos exponiendo lógica de nuestro dominio, ejm: WebService. Pero, ¿es realmente necesario contar con una capa como esta ? , las razones podrían ser las siguientes:

  • Para mantener los controllers limpios o tener thin controllers , este caso se presenta cuando tenemos proyectos grandes o empezamos a poner mucho código en el controller, en caso contrarío podemos quitar del todo esta capa.
  • Si necesitamos reutilizar lógica que se encuentra en un controller y exponerla por cualquier otra interfaz hacia una cliente ejm: WebService, entonces es buena idea mover el código hacía un application service.

-Persistence: Acá tendremos a la implementación real de los repositorios definidos en el dominio y es donde nos comunicaremos con una base de datos para guardar el estado de nuestros objetos.

-Test: Se encontrarán los test unitarios de todas las capas de la aplicación.

A continuación tenemos 2 imágenes que muestran las diferencias de una arquitectura tradicional de 3 capas frente a DDD (Onion Architecture) :

image  image

DDD tiene muchos otros conceptos que aún no hemos visto pero que iremos tocando a medida avancemos la aplicación. Existen algunas aplicaciones libres donde podemos observar la implementación de DDD:

- S#arp Architecture, framework que encapsula la implementación de DDD sobre la arquitectura de una aplicación.
- CodeCampServer, aplicación web que es tomada de ejemplo por Jeffrey Palermo en su libro ASP.NET MVC in Action
- NDDD Sample, aplicación que pone en práctica lo descrito en el libro de Eric Evans.

Bueno con esto terminamos esta primera parte donde definimos un poco el objetivo de la aplicación y su arquitectura. Asimismo hemos visto algo de DDD, y sin considerar DDD aún nos queda muchísimas otras cosas por ver.

No se olviden de ver el resto de las serie ASP.NET MVC y otras Yerbas.
Hasta el siguiente post.

Mi Primer Post

Como todos los que vivimos en el mundo de la informática tenemos la necesidad de aprender y compartir, es por esto que me animé a abrir un blog, para poder escribir lo poco que sé y a la vez esperar sus comentarios y sugerencias para seguir mejorando.

Saludos.
Angel Nuñez Salazar.