domain-driven-design - quickly - implementing domain-driven design pdf
¿Se me permite tener agregados "incompletos" en DDD? (4)
DDD establece que solo debe acceder a las entidades a través de su raíz agregada. Por ejemplo, supongamos que tiene una raíz agregada X que potencialmente tiene muchas entidades Y filiales. Ahora, para algunas situaciones, solo te importa un subconjunto de estas entidades Y a la vez (quizás las muestres en una lista paginada o lo que sea).
¿Está bien implementar un repositorio entonces, para que en tales escenarios devuelva un agregado incompleto ? Es decir. un objeto X cuya colección Ys solo contiene las instancias Y que nos interesan y no todas ? Esto podría causar, por ejemplo, métodos en X que realicen algunos cálculos que impliquen el Ys para no comportarse como se espera.
¿Es esto quizás una indicación de que la entidad Y en cuestión debe considerarse promovida a una raíz agregada?
Mi idea actual (en C #) es aprovechar la ejecución retrasada de LINQ, de modo que mi objeto X tenga una IQueryable para representar su relación con Y. De esta manera, puedo tener una carga diferida transparente con filtrado ... Pero para que esto funcione con un ORM (de Linq a Sql en mi caso) podría ser un poco complicado.
¿Alguna otra idea inteligente?
Realmente estás haciendo dos preguntas superpuestas.
El título y la primera mitad de su pregunta son filosóficos / teóricos. Creo que la razón para acceder a entidades solo a través de su "raíz agregada" es abstraer los tipos de detalles de implementación que está describiendo. El acceso a través de la raíz agregada es una forma de reducir la complejidad al tener un punto de acceso confiable. Está eliminando la fricción / ambigüedad / incertidumbre al adherirse a una convención. No importa cómo se implemente en la raíz, simplemente sabes que cuando solicites una entidad estará allí. No creo que esta perspectiva excluya un "repositorio filtrado" como describes. Pero para proporcionar un pozo de éxito para que los desarrolladores caigan, debería ser imposible crear una instancia del repositorio sin ser explícito sobre su "filtración"; Del mismo modo, si es posible el acceso compartido a una instancia de repositorio, la "filtración" debe ser explícita cuando se codifica en la persona que llama.
La segunda mitad de su pregunta es acerca de la implementación en una plataforma específica. No estoy seguro de por qué menciona la ejecución retrasada, creo que es realmente ortogonal a la pregunta de filtrado. El filtrado en sí podría ser un poco complicado de implementar con LINQ. Tal vez, en lugar de indicar el lugar donde lambdas, configura una colección de ellos y selecciona uno según el filtro que necesites.
Considero que una raíz agregada con muchas entidades secundarias es un olor a código, o un olor DDD si se quiere. :-) Generalmente veo dos opciones.
- Divida su agregado en muchos agregados más pequeños. Esto significa que mi diseño original no era óptimo y necesito identificar algunas entidades nuevas.
- Divida su dominio en múltiples contextos delimitados. Esto significa que hay conjuntos específicos de escenarios que usan un subconjunto común de las entidades en el agregado, mientras que hay otros conjuntos de escenarios que usan un subconjunto diferente.
Jimmy Nilsson insinúa en su libro que, en lugar de leer un agregado completo, puede leer una instantánea de partes de él. Pero se supone que no puede guardar los cambios en las clases de instantáneas en la base de datos.
El libro de Jimmy Nilsson Capítulo 6: Preparación para la infraestructura - Consultas. Página 226.
Usted está autorizado ya que el código se compilará de todos modos, pero si busca un diseño DDD puro, no debería tener instancias incompletas de objetos.
Debería mirar LazyLoading si tiene miedo de cargar un objeto enorme del cual solo usará una pequeña porción de sus entidades secundarias.
LazyLoading demora la carga de lo que decida cargar de forma diferida hasta el momento en que se accede a ellos. Hacen uso de devoluciones de llamada para llamar al método de carga una vez que el código los llama.