Antes que nada pedir disculpas, especialmente a
Julio César Pérez porque hace ya varias semanas que, en la
primera parte de este artículo, le prometí que iba a escribir un ejemplo para explicar cómo se implementaba la
ignorancia de la persistencia (“persistence ignorance” en inglés) en un modelo de dominio al estilo
DDD. Lo cierto es que he visto que me estoy metiendo en tantos fregados (incluídas mis labores familiares cotidianas) que cada día tengo menos tiempo de ponerme a programar con la mínima continuidad necesaria.
Bueno, como la respuesta a Julio la tengo más o menos elaborada, voy a utilizar código ajeno para explicarme. A ver si queda suficientemente claro. El código completo está disponible en el ejemplo “oficial” de DDD: DDDSample. Lo podéis bajar desde el repositorio de subversion (yo he utilizado la última versión etiquetada como 1.1.0) o podéis “navegar” por el código fuente coloreado e hipervinculado generado con el plugin maven jxr. Seguramente explicar este ejemplo daría para varios blogs, pero me voy a centrar en la explicación de la persistencia. Si queréis ver los ficheros de configuración de Spring e Hibernate no os quedará más remedio que acceder al SVN. Perdonad que no os hipervincule todas las clases pero ya os he explicado que ando justito de tiempo libre… 
Este DDDSample es la implementación del ejemplo empleado por Eric Evans en el libro azul y que se trata de una compañía de transporte de contenedores. Yo voy a seguir el camino de una petición de reserva del envío de un contenedor, que es algo sencillo pero que implica guardar datos en la base de datos. No voy a entrar en cómo se llama desde la UI al servicio para no extenderme demasiado, pues como dije más arriba tenéis todo el código disponible para descargarlo, pero sí que os explicaré (al final) el “truqui” que emplean aquí por si os suena un poco raro.
Todo empieza por una fachada llamada BookingServiceFacadeImpl (que implementa la interfaz BookingServiceFacade y que no sirve para otra cosa que para envolver al “verdadero servicio” (BookingServiceImpl, que implementa BookingService). El constructor de BookingServiceImpl tiene como parámetros un CargoRepository, un LocationRepository y un RoutingService, esto se podría cambiar por un constructor vacío y varios setters, pero siempre y cuando nos aseguremos de no usar BookingService sin antes haber “seteado” estos colaboradores. Por eso es más seguro inyectar los colaboradores imprescindibles en el constructor. En DDDSample se hace con Spring en context-application.xml:
El método que nos interesa es bookNewCargo:
@Override@Transactionalpublic TrackingId bookNewCargo(final UnLocode originUnLocode, final UnLocode destinationUnLocode, final Date arrivalDeadline) {// TODO modeling this as a cargo factory might be suitablefinal TrackingId trackingId = cargoRepository.nextTrackingId();final Location origin = locationRepository.find(originUnLocode);final Location destination = locationRepository.find(destinationUnLocode);final RouteSpecification routeSpecification = new RouteSpecification(origin, destination, arrivalDeadline);
final Cargo cargo = new Cargo(trackingId, routeSpecification);
cargoRepository.store(cargo);logger.info("Booked new cargo with tracking id " + cargo.trackingId().idString());
return cargo.trackingId();}
Fijaos que no hablamos con la BD para guardar el objeto Cargo que recién creamos, sino que hablamos con un CargoRepository: el que hemos inyectado en el constructor y que puede perfectamente guardar el objeto en la BD o en cualquier otro sitio, p.ej. una Collection. ¿Por qué no? Si no hubiera un requisito que nos pidiera poder recuperar la información de los envíos (Cargos) si la aplicación se reiniciara, no habría nada que nos impediría mantener en memoria esta información. ¿Verdad? En esto justamente consiste la ignorancia de la persistencia. Si cambiamos la política para guardar los datos, el código de los objetos Cargo no necesita ser modificado ni una línea. Es más, nuestro servicio (de dominio) BookingService tampoco. Sólo necesitamos cambiar el repositorio que inyectamos. Esto es fácil con Spring. Veamos cómo está hecho en context-infrastructure-persistence.xml:
No pongo los detalles de cómo se configuran transactionManager ni sessionFactory porque no son significativos: son idénticos a los de cualquier otra aplicación. Lo que sí es relevante aquí es CargoRepositoryHibernate. Fijaos en que está anotada con @Repository y extiende HibernateRepository (que simplemente sirve para tener el setSessionFactory y el getSession). Finalmente, echemos un vistazo al método store que es el que nos interesa ahora, pero echad un vistazo “de refilón” a los demás porque pueden ayudaros a situaros sobre cuál es la responsabilidad de este objeto (que es MUY parecido a un DAO).
public void store(Cargo cargo) {getSession().saveOrUpdate(cargo);// Delete-orphan does not seem to work correctly when the parent is a componentgetSession().createSQLQuery("delete from Leg where cargo_id = null").executeUpdate();}
Observad que alguien ha dejado un comentario explicando el borrado de ciertos objetos relacionados. Esto tiene un cierto “tufillo”, yo hubiera extraído el comentario y la linea a la que se refiere a un método private llamado deleteOrphansWhenParentIsAComponent o algo así, y hubiera llevado el comentario al javadoc del método y me aseguraría de tener un buen test para esto que huele tan raro… pero es lo que hay…
Llegados a este punto algunos volveréis la vista atrás y diréis: “¡Demonios! ¿Dónde hace commit?”. Aquí es donde tenemos que mostrar todas las cartas y enseñar dónde se configura aquella fachada de la que hablábamos al principio BookingServiceFacadeImpl:
hibernateInterceptor
Claro, ahora se entiende, usamos el HibernateInterceptor con la misma sessionFactory de nuestros repositorios. Je, je… Vale, es un poco “truqui”, pero es la manera más limpia que hay de trabajar “puertas adentro” y olvidarte de historias.
¡Uy! Se me olvidaba explicar cómo es el objeto Cargo, que es lo que en DDD se denomina AggregateRoot y que es algo así como la raíz de un árbol de objetos dependientes, cuya existencia depende de la raiz. En este caso son Cargo, Itinerary, Leg, Delivery y RouteSpecification. No voy a profundizar aquí, pero diré que cuando guardamos un Cargo podemos estar guardando todos los que dependen de él. Cargo también es una Entity (en el sentido de DDD y también en el sentido de JPA, si lo usáramos).
¿Cómo se mapea este AggregateRoot con las tablas de la BD? Si usáramos JPA sería muy fácil viendo las anotaciones; en el caso de DDDSample han usado los ficheros de mapeo de Hibernate. No voy a entrar en detalles sobre esto porque sería explicar Hibernate, y no es mi intención ahora mismo.
Por último, el “truqui” del que os hablaba al principio que usan para exponer la fachada. Usan RmiServiceExporter, una utilidad (como otras muchas) de Spring, y que permite acceder a este objeto BookingServiceFacadeImpl como si de un EJB se tratara. Fácil, ¿verdad? Bueno, también podríais haberlo anotado con @EJB y todas esas cosas que explican en Java EE. Ya se sabe, para gustos, colores. 
Espero que haya quedado claro el “meollo” de la cuestión, que tiene mucho que ver con aquello que contaba hace ya bastante sobre la Arquitectura en Capas de Cebolla. La idea que me gustaría que os quedara después de este artículo (y sobre todo el anterior) es que la ventaja de hacer un modelo de dominio rico y carente de dependencias tecnológicas consiste en que tenemos un código más limpio y realmente desacoplado, lo que nos trae un montón de ventajas como que podemos comprobar unitariamente nuestro código con mucho menos coste y riesgo de errores.
Quedo a vuestra disposición para discutir lo que creáis conveniente.
Nota: Perdonad el formato de los xml, pero Blogger me reformatea los elementos vacíos y me monta un cristo, hasta que me he dado cuenta y los he cambiado a mano.
Voy en metro, ilusionado, camino del segundo día del 
En los últimos días he estado cruzando 
Resulta que en 
