Conciencia del repositorio DDD de otros repositorios

Question

¿Es generalmente aceptable que un repositorio pueda acceder a otro repositorio? Específicamente en este caso, tengo una raíz agregada que usa otra raíz agregada para determinar qué entidades agregar. Se corresponde con una relación de tipo de artículo/artículo. El motivo por el que el Tipo de elemento es una raíz agregada es que se pueden mantener por separado dentro de una herramienta de administración fuera del alcance de cualquier Artículo individual.

Si no importa, solo estoy creando mis instancias de repositorio a través de una implementación de fábrica de repositorio, así que no estoy creando directamente por el nombre de la clase concreta. En ningún momento el agregado conoce el repositorio.

Editar - Más información:

La implementación específica es que podemos adjuntar imágenes a un documento. No solo podemos administrar las imágenes en el documento, sino que existen diferentes tipos de imágenes (tipos que se definen como cómo se implementan, a diferencia de una extensión, por ejemplo). El agregado del documento es uno de los pocos tipos de otros objetos en el sistema que usan estas imágenes y no todos usan los mismos tipos. Si bien adjuntamos reglas en los servicios de dominio, esto está más específicamente orientado a construir el agregado de documentos. Al construir el agregado, tenemos cinco imágenes de un tipo específico y una de cada uno de los otros dos tipos. Los extraemos individualmente porque están almacenados en listas separadas en conjunto. La validación no es el problema, sino que limita el tipo de imágenes que se evalúan al ensamblar el documento.

Answer 1

Supongo que se reduce a lo que intenta hacer. Si se trata de una especie de paso de validación (por ejemplo, eliminar todos los elementos que tienen tipos de elementos caducados), podría argumentar que pertenece a una capa o especificación de servicio. Del lenguaje que usas (es decir, "determina qué entidades agregar"), parece sugerir lo último, aunque es difícil de decir sin más detalles.

Supongo que, desde cierto punto de vista, no hay una razón real por la que no puedas (no soy de ninguna manera un super DDD más puro), especialmente porque un elemento y su tipo se pueden ver como una raíz agregada y solo los detalles de implementación que necesita para proporcionar una consola de administración que sea preventiva.

Desde otro punto de vista, parece sugerir que hay un borrón entre las raíces agregadas que podría sugerir dos contextos diferentes en el trabajo. Por ejemplo, se podría argumentar que una herramienta de gestión forma un contexto delimitado por separado para su aplicación principal y, por lo tanto, el caso para el tipo de Artículo que es una raíz agregada realmente no se aplica. p.ej. La herramienta de administración podría estar relacionada con los Tipos de elementos (y nunca con los elementos), mientras que la aplicación principal podría ver los tipos de elementos como más un objeto de valor que una entidad.

actualización

como usted menciona el montaje del documento, esto parece la responsabilidad de una clase de fábrica que se pueden montar correctamente una entidad válida (la fábrica puede utilizar el repositorio tipo de imagen). Un repositorio debería (a mi parecer) exponer las operaciones de consulta y adición, no la lógica para configurar entidades (excepto tal vez la rehidratación de la persistencia).