AOP, OO y SOA: Cada uno es responsable de lo suyo

AOP, OO y SOA son algunos de los acrónimos de moda dentro del mundo de desarrollo. Actualmente existe un abanico de tecnologias que nos facilitan en mayor o menor medida su uso. Yo me voy a centrar en .NET, y para introducir el tema voy a hacer uso del que puede ser mejor anfitrión: el DDD (Domain Driven Development) . DDD es una filosofía de diseño (basada en el sentido común) que intenta orientar el diseño de un sistema mediante la compresión del problema y evitando centrarse en el problema tecnologico (si estamos para resolver problemas, no nos creemos uno más antes de empezar). Entender el problema (al menos inicialmente) nos permite determinar que entidades primarias existirán, que entidades secundarias las interrelacionan y por último con toda la información aparece la Orientación a Objetos. En este punto, una buena práctica es el que cada elemento del sistema se responsabiliza de una tarea y solo de esa, evitando complejidad. Este metodo de trabajo está intimamente relacionado con TDD y la filosofía de plantear las pruebas antes de codificar . Estas entidades van a ser las futuras interfaces en el sistema (y solo interfaces) y las entidades de negocio . Normalmente en este punto ya tenemos la primera piedra y a partir de aqui solo es colocar las demás (pero aun así también podemos tropezar). A partir de estas entidades, también podemos comprender los procesos que serán necesarios (por ejemplo, en un mantenimiento al alta, baja y modificación). Una vez identificados estos procesos ya tendremos identificados que servicios necesitamos y que nos deben ofrecer, asi como los metodos de las interfaces. Como veis en este punto estamos trabajando Orientación a Objetos y Orientación a Servicios. Una vez disponemos de la interfaz de servicio y de sus entidades por una parte, y por la otra de la definición de las interfaces (con sus herencias, agregaciones y relaciones), podemos empezar a dar forma por separado. El el caso del servicio, problablemente siempre pensemos en un servicio que habla con una base de datos, pero puede no ser así y que nos encontremos:

• Un servicio que habla contra uno o más servicios que pueden ser nuestros o de terceros
• Un servicio que actua contra otro sistema mediante colas de mensajes o mediante algún mecanismo asincrono.
• Un servicio que hable contra un gestor de procesos como Biztalk.

La conclusión de todo esto es que necesitamos saber de donde sacar y/o almacenar los datos, para decidir cual es la mejor implementación a seguir. Además tendremos que tener en cuenta factores como Seguridad, Monitorización y Trazabilidad del servicio. Y por ultimo recordar que SOA no es SOAP, un servicio no tiene porque ser necesariamente un WebService por lo que debemos concebirlo como un elemento independiente del canal de comunicaciones que se use (si es que alguno es necesario). En este sentido Windows Communication Foundation puede ser un elemento clave. En cuanto al modelo de objetos, nuestro mejor aliado va a ser el conocer Patrones de Diseño (a parte de OO). Normalmente en los modelos de objetos nos encontraremos con objetos que contienen collecciones que a su vez devuelven objetos y a otros objetos. Un diseño basado en interfaces nos facilita la posibilidad de ocultar la complejidad de nuestras librerías a quienes las usen, y para ello podemos hacer uso en .NET de clases internal que implementen las interfaces. Al igual que en el caso de los servicios, el modelo de objetos tendrá un o más punto de entrada. En mi caso, me suele gustar seguir estas lineas de trabajo:

• Siguiendo el patron de abstract factory o el factory method (a gusto de cada uno), proporciono acceso a la clase o clases principales. Esta clase no devuelve como tipos los de las clases internas (que no son publicables) sino los tipos de las interfaces.
• En muchas ocasiones necesitamos que una misma interfaz tenga distintos comportamientos (similar a los juegos de futbol donde todos son jugadores pero cada uno a su manera) y para ello podemos seguir el patron Strategy donde para una misma interfaz tenemos distintos comportamientos implementados usando n clases.
• En el caso de las collecciones, es recomendable seguir la pauta de puntero libre, es decir quien recoge un elemento de la colleccion es el encargado de gestionar su ciclo de vida y no la propia colección.

Esto son solo algunos puntos, y en cada situación siempre se presentan cosas nuevas. A partir de aqui solo una recomendación, la mejor forma de validar un modelo es tener listas las pruebas unitarias que nos ayudan a ver si seguimos un camino coherente y a probarlo despues de cada modificación. Además, con este tipo de pruebas podemos validar nuestro proyecto en cualquier momento (yo soy partidario de las Build diarias pasando estas pruebas y etiquetando nueva versión en caso de exito). Y donde queda AOP? AOP nos puede facilitar ciertas tareas tanto en nuestros servicios como en nuestro modelo de objetos. Normalmente con AOP podemos incluir Trazabilidad, Gestión de Excepciones, Seguridad, Transaccionalidad, etc haciendo uso de atributos en .NET (ya veremos que alternativas hay directamente en .NET) o de algun Framework de AOP para .NET, pero AOP también nos puede servir para modificar el comportamiento de las clases según el aspecto aplicado, para el mapeo de campos, etc. En este sentido, la norma de una responsabilidad por elemento facilita el detectar que características son susceptibles de ser aspectos. Proximamente, profundizaremos más en detalle tanto en patrones de diseño, SOA (seguridad, estándares, etc) y en AOP, pero espero que estas lineas hayan servido para aclarar un poco los distintos enfoques y sus posibilidades al combinarlos.

Comments

• Anonymous
  January 01, 2003
  Lo cierto es que me gustaria aprender a programar, entender como funcionan las cosas, y te puedo asegurar que leer este post no ha hecho sino evidenciar la profunda carencia de conocimiento que en estos momentos poseo. No solo no me ha aclarado que es o para que sirven AOP, OO, SOA, etc... sino que ha generado en mi un sinfin de preguntas que van a hacer que mi cabeza estalle. Efectivamente, se mucho menos de lo que me imaginaba, pero al menos al leer estas lineas me he dado cuenta que eso me importa, con lo que se que voy a poner medios para evitar que este mar de dudas continue creciendo. Voy a ser, a partir de ahora, muy critico con lo que lea en tu blog, asi que preparate!!!