Precomputa sin miedo que no muerde.

Parece ser que, en el mundo de la gente que intenta aplicar DDD, hay mucha reticencia a la hora de hacer cálculos en diferido fuera de la operación principal (agregado raíz) que necesita los resultados de ese cálculo. Eso es un error que te empantana hasta las tetillas y te hace liarla muy parda.

Pongamos un ejemplo sencillo que se complica cuando queremos tener agregados que realicen una operación en una única transacción (regla de oro de los agregados) que necesita ser confirmada por un montón de elementos; los cuales cada uno tiene sus datos propios que podrían provocar el rechazo de ese cambio.

Tenemos un Seminario con una lista de 1000 Participantes. El Seminario tiene un fecha de programa de comienzo y de fin. El seminario se puede reprogramar para otras fechas según unas reglas propias pertenecientes al Seminario y además sólo si cada uno de los Participantes puede aceptar esa nueva fecha según una serie de datos pertenecientes a ese Participante. En caso de que un solo Participante no pueda aceptar la fecha la reprogramación se cancela.

A primera instancia; el instinto nos dice que recorramos los 1000 participantes y les preguntemos si pueden aceptar. Bueno venga, 1000 identificadores con algún dato que otro en memoria no es tanto pero ¿Y si fueran varios millones?

¿Recuerdas la entrada de Dale la vuelta antes de decidir? Pues vamos a aplicarla.

Lo que debemos hacer es acotar las fechas que puede aceptar el Seminario en unos campos en persistencia que se usarán para alimentar el agregado que reprograma el Seminario. A medida que, al trabajar con el sistema, asociemos Participantes al Seminario uno por uno, estos campos irán cogiendo los valores mas restrictivos de cada Participante que se añada y el conjunto de fechas de reprogramación aceptadas por el agregado se ira reduciendo. A la hora de desasociar un Participante hacemos lo contrario y ampliamos el conjunto de fechas aceptables por el Seminario. Esto provoca que el sistema esté siempre consistente a cada pasito (añadir un nuevo Participante en el Seminario) que damos y que luego podamos aplicar reglas del dominio sin necesidad de chequear varios millones de valores solo para una respuesta de un agregado raiz.

Ya sólo nos queda obtener el agregado que reprograma las fechas del Seminario; que entre su información tiene las fechas aceptables por el Seminario y lanzar la operación de reprogramación; pudiéndola rechazar o aceptar con un par de comparaciones simples.