Acceder directamente al hijo de la raíz de agregado.
Estoy modelando una aplicación de cursos, intentando jugar con DDD y Arquitectura Limpia. Tengo un Curso, que tiene uno o más módulos, y cada uno de ellos tiene una o más lecciones.
He creado una raíz de agregado llamada “ModuleLessons” que es una lista de lecciones que pertenecen a un módulo.
Tengo el caso de uso donde el usuario puede acceder a la lista completa de lecciones dentro de un módulo, por lo que accede a una URL como “myapp/lessons/{identificador-del-modulo}” y esto terminará llamando a algo como “moduleLessonsRepository.getById({identificador-del-modulo})” y mostrará al usuario una lista de lecciones que componen ese módulo.
Según entiendo, el repositorio solo debería ocuparse de la raíz de agregado completa, no de las entidades secundarias directamente. En otras palabras, si Lesson no es una RA, no debo tener un “LessonRepository.getById()”.
Pero tengo otro caso de uso donde el usuario puede acceder a algo como “myapp/lesson/{identificador-de-leccion}”.
¿Pero cómo podría implementarlo si no puedo tener un repositorio que devuelva una lección por su identificador?
Podría cargar el agregado “ModuleLessons” y luego encontrar la lección dentro de él, pero no tengo su identificador para hacer la consulta.
Podría poner el identificador del módulo y el identificador de la lección (o tal vez solo la posición de la lección dentro de su módulo) en la URL y usar eso para encontrar el RA “ModuleLessons”, pero ¿estoy agregando datos extras en la URL solo para cumplir con las restricciones arquitectónicas, está bien?
Finalmente, la posición de la lección dentro de su módulo sí importa, pero ese dato no pertenece a la lección ni al módulo, por eso creé la lista misma como el RA, ¿tal vez no fue la decisión correcta?
davy.ai
Como mencionaste, según los principios de DDD, el repositorio solo debería manejar la raíz del agregado y no las entidades secundarias directamente. En este caso, la entidad “Lesson” es una entidad secundaria de la entidad “Module”, que forma parte del agregado “ModuleLessons”.
Una solución para el segundo caso de uso sería crear un “LessonService” que maneje las operaciones en la entidad “Lesson”. El “LessonService” recibiría el “id de la lección” como parámetro y utilizaría el repositorio “ModuleLessonsRepository” para recuperar la raíz del agregado “ModuleLessons”. Luego, recorrería las entidades anidadas para encontrar la entidad “Lesson” específica con el “id de la lección” proporcionado.
En cuanto al uso de datos adicionales en la URL, es común en arquitecturas RESTful incluir parámetros de ruta adicionales para manejar recursos complejos o anidados. En este caso, incluir el “id del módulo” y el “id de la lección” en la URL podría ser un enfoque válido.
Alternativamente, podrías considerar hacer que la entidad “Lesson” sea una raíz de agregado. Sin embargo, esto requeriría reestructurar el modelo de dominio, ya que significaría que las lecciones ya no están vinculadas a un módulo, lo cual puede no representar con precisión el dominio.
En resumen, una posible solución para el segundo caso de uso es crear un “LessonService” que recupere y manipule la entidad “Lesson” a través de la raíz del agregado “ModuleLessons”, y pasar el “id de la lección” como parámetro. Incluir el “id del módulo” y el “id de la lección” en la URL podría ser un enfoque válido en una arquitectura RESTful. Sin embargo, reestructurar el modelo de dominio para hacer que la entidad “Lesson” sea una raíz de agregado también es una opción viable, dependiendo de los requisitos específicos del negocio.