domain driven design - DDD: pregunta raíz agregada

domain-driven-design aggregateroot

Question

Digamos que tengo 2 entidades - Foo y Bar. Foo es una raíz agregada y contiene Bar. Por lo que yo entiendo, debería verse así:

public class Foo{
    private readonly Bar Bar;
}

Quiero proporcionar funcionalidad para que los usuarios elijan Bars for Foos de una lista definida (y la modifiquen).

Si se supone que los repositorios son solo para raíces agregadas, significa que no habrá repositorio para la entidad Bar.

Esto conduce al problema: la barra no se puede crear / actualizar independientemente sin una referencia a Foo.

¿Eso significa que se supone que Bar tiene un repositorio a pesar de que no tiene sentido sin un Foo?

Answer 1

¿Estás seguro de que Bar necesita ser una entidad? ¿Tienes la necesidad de rastrearlo y cambiarlo en el dominio? Si puede verlo como un objeto de valor, le sugiero que lo obtenga de un servicio y luego "conecte" el objeto de valor seleccionado a la entidad Foo. Por instantes a través de una lista desplegable.

Answer 2

Las razones para tener raíces agregadas son:

1. Proporcionan acceso controlado y dirigido a entidades compuestas.
2. Pueden hacer cumplir las reglas para garantizar que todo el agregado sea válido

Mi opinión: si necesitas seleccionar objetos de Bar sin un Foo , usa un BarRepository .

Pero ... ¿Qué pasa si actualizas una Bar y rompe una regla de validación para su padre Foo ? Si esto pudiera suceder, deberías acceder a Bar través de su padre Foo .

Sin embargo, si necesita acceder a un grupo de objetos Bar (por ejemplo, para un trabajo por lotes o un informe) y sabe que Foos no se romperá, continúe y acceda a ellos a través de BarRepository .

Recuerde que las raíces agregadas pueden estar compuestas de otras raíces agregadas. Puede descubrir que Bar es una raíz agregada en sí misma, lo que le da justificación para un BarRepository :)

Answer 3

Si desea seleccionar de una lista de Barras en las que no están asociadas con Foo, entonces esta no es una raíz agregada. Por ejemplo, no puede obtener una lista de artículos de pedido sin su pedido, por lo que esta es una raíz agregada única (pedido), pero puede obtener una lista de productos para asignar a artículos de pedido, por lo que el producto no forma parte de la raíz agregada de pedidos.

Tenga en cuenta que si bien OrderItem forma parte de la raíz agregada de Order, aún puede crearla y actualizarla de forma independiente. Pero, no se puede obtener sin referencia a la Orden. Lo mismo para su Barra, incluso si era parte de Foo, podría obtener cada (Foo.Bars) y trabajar con ella, o hacer Foo.AddBar (nueva Barra ()). Pero si necesita obtener la Lista sin Foo, Bar no forma parte del agregado de Foo. Es una entidad separada.

Bueno, así es como veo DDD aquí, pero no soy Eric Evans, por supuesto.