¿Debo usar una raíz agregada al diseñar mi repositorio?

Tengo una entidad llamada Master que está compuesta por varias entidades Slave.

Solo puede haber un Maestro en mi base de datos y quiero consultar repositorios para obtener el Esclavo para una identificación determinada.

Inicialmente creé un SlaveRepository y lo pregunté por id. Eso parece estar bien y funciona, y otros desarrolladores podrían usar mi repositorio.

Luego pensé en las raíces agregadas y creé un MasterRepository y devolví el Master y luego hice un ciclo para obtener la entidad Slave requerida. El problema que sentí aquí es que una vez que expongo esto a otros desarrolladores tendrían que hacer lo mismo, así que tuve un método en el MasterRepository llamado GetSlaveByID (id de cadena) y luego pude obtener el Slave directamente (oculta la funcionalidad del bucle )

Ahora, ¿debería mi repositorio devolver un Esclavo aunque se llame MasterRepository? Y lo más importante, ¿cuál es el camino correcto?

Estoy en las primeras etapas de tratar de aplicar DDD y TDD, por lo que probablemente hay muchas cosas en las que debo pensar antes de decidir cuál es la forma correcta, supongo.

De acuerdo con la forma de diseño controlado por dominios de Eric Evans, debe evitar repositorios para raíces no agregadas.

Él dice claramente:

Solo se pueden obtener raíces agregadas directamente con las consultas de la base de datos. Todo lo demás debe hacerse a través del recorrido.

Pero también significa que el repositorio de la raíz debe cumplir todos los requisitos. Si necesita acceso directo a partes del agregado, entonces un objeto raíz agregado o su repositorio es responsable de hacerlo.

Por lo tanto, está perfectamente bien tener métodos como los siguientes en un repositorio raíz agregado:

Slave GetSlave(string id)

Pero esta firma es un poco peligrosa, ya que las identidades de los niños en DDD solo tienen sentido en el contexto de un objeto raíz real y son superficiales sin la raíz.

Esto nos lleva a un enfoque mejor y más DDD para una implementación en un repositorio:

Slave GetSlaveOfMaster(Master master, string slaveId)
// or
Slave GetSlaveOfMaster(Identity masterId, Identity slaveId)

Pero probablemente ni siquiera tendría este método en el repositorio sino en la entidad maestra para acceder rápidamente a los esclavos. Posiblemente incluso expuesto como una tabla hash. Ese es el enfoque más limpio que se me ocurre.

//within the Master entity
Slave GetSlave(Identity slaveId);

Espera, este no es el final de la historia. Si necesita buscar esclavos sin el conocimiento del maestro, entonces debe pensar en sus agregados y su modelo de objetos. Quizás necesite un segundo agregado donde el esclavo sea una raíz y luego debería tener un repositorio personalizado para ellos. El esclavo no es solo un hijo del maestro, sino una jerarquía separada que probablemente también tiene una referencia a un maestro. Es importante saber si un objeto esclavo puede existir sin un maestro en absoluto. Si puede, entonces un agregado separado es probablemente el camino a seguir.

En general, dentro del límite agregado debe haber solo un repositorio. Y, como dijo Falcon, podría terminar con dos agregados separados, maestro y esclavo.

Sin embargo, parece que el enfoque principal en su pregunta es la recuperación de datos, mientras que en DDD debería ser el comportamiento. Los límites agregados son una consecuencia de las restricciones impuestas por el comportamiento (cosas que cambian juntas e invariantes para que se apliquen), la estructura interna del agregado es una consecuencia de esa elección.

Por ejemplo, si agrupa las cosas correctamente de acuerdo con la necesidad de un cambio, no es necesario llamar a un Repositorio externo. La mayoría de los casos, los datos necesarios para una operación comercial en el Agregado ya deberían estar dentro de los límites agregados, la necesidad de acceder a diferentes agregados es probablemente un olor a límite inconsistente.