DDD - ¿Cómo puedo evitar cruzar las fronteras de agregado aquí?

Question

Estamos trabajando en un nuevo proyecto (re-escribir aplicación existente), y yo estoy corriendo a tener problemas con mi modelo de dominio de diseño / repositorio.

Aquí está una (simplificado) versión de dos porciones clave en nuestro modelo de dominio:

Como se puede ver, tengo un concepto abstracto de un Post , que pueden ser cosas como una opinión, una discusión, una foto, un vídeo, etc. Mensajes también pueden tener comentarios.

También tiene un concepto abstracto de un Ubicación , que son, obviamente, cosas como calles, ciudades, barrios, etc.

Ahora, esto, naturalmente, se veía a mí como dos raíces agregados claras.

Así que creó dos depósitos, uno llamado PostRepository , y otro llamado LocationRepository .

Esto fue todo funciona bien, puedo añadir / conseguir cualquier tipo de mensaje (o comentario), y añadir / conseguir cualquier tipo de ubicación a través de uno de estos dos lugares de almacenamiento.

Pero ahora estoy en el escenario de una "página de destino" para una ciudad (por ejemplo).

En esta página, necesito mostrar básicamente "todos los mensajes de este lugar".

¿Cómo se define eso? Bueno, un mensaje puede ser (opcionalmente) etiquetada en un lugar. detalle de implementación, por lo que no quiero ir demasiado profundo en los datos (como eso no es lo DDD está a punto), pero esencialmente hay inteligencia geoespacial para averiguar qué mensajes están contenidos en un lugar determinado por el archivo de forma de la ubicación, y la latitud / longitud del etiquetado post.

Pero, ¿cómo puedo recuperar esta información sin cruzar los límites?

¿Qué repositorio de uso? ¿Necesito uno nuevo?

Si se importa (o para los curiosos), se trata de una aplicación web (ASP.NET MVC), con una base de datos SQL Server 2008 y Entity Framework 4.0.

Si necesita cualquier aclaración, avísame.

Editar

Actualmente utilizan una versión modificada del patrón de especificación con el fin de recuperar los modelos de dominio.

Por ejemplo, este es el código en nuestra BLL para recuperar todos de revisión, donde puntuación> = 4:

var reviews = postRepository // GenericRepository<Post>
      .Find() // IQueryable<Post>
      .OfType<Review>() // IQueryable<Review>
      .Where(x => x.Score >= 4)
      .ToList(); // List<Review>

Pero ahora necesito un poco de código como el siguiente:

var reviews = postRepository
    .Find()
    .OfType<Review>()
    .Where( //lat long, or Locations FK )
    .ToList();

El problema es que no sé cómo hacer la consulta anterior sin añadir un intermediario Join-entidad (LocationPost - ya que es una de muchos a muchos)., Y añadir un FK al modelo de dominio del anuncio a que

Pero al hacer eso, estoy cruzando los límites agregados -? ¿Verdad

Answer 1

Me uniría posterior a la ubicación en tiempo de creación de modo que para cada lugar que puedo conseguir (a través de un repositorio) una lista de mensajes asociados. Se vería así:

Creación:

var p = new Post(latitude, longitude);
var locations = locationRepository.FindByCoordinates(latitude, longitude);
foreach (var l in locations)
{
    l.AssociatePost(p);
}
session.Save(p);

Recuperación:

var associatedPosts = postRepository.FindByLocation(locationId);
foreach (var p in associatedPosts)
{
    Display(p);
}

Bajo el capó, la asociación entre los mensajes y ubicación sería implementado como una relación de tabla de muchos a muchos. Hay un problema con esta solución:. Añadir una nueva ubicación requiere para escanear todos los mensajes y asignarlos a la nueva ubicación (si procede)

Espero que ayude.

Answer 2

¿Por qué es esto un problema? De acuerdo con Evans en su libro, una AR puede muy bien hacer referencia a otra AR. (Es posible que no obstante hacer referencia a un elemento secundario en un AR de otro AR)

Además, son lugares muy raíces agregadas? La definición de una raíz agregada es que actúa como un límite de concistency. ¿Eso se ajustan a la definición de un lugar? Yo diría que un lugar es un objeto de valor.

No son más o menos dos campos aquí con respecto a los repositorios y asociaciones AR:

Uno que dice que todas las raíces agregadas Have a se obtengan a través de su respectivo depósito, y AR de las relaciones debe usar suaves, por ejemplo de Identificación entre ellos

Y uno que dice que las raíces agregadas pueden muy bien traen otras raíces agregadas asociados y que un repositorio es simplemente una manera de encontrar las raíces de agregado.

Answer 3

Digamos que utilizó el patrón de especificación, se puede construir una especificación de mensaje utilizando un objeto Localización? A continuación, sólo tiene que pasar la Especificación Para publicar su repositorio, y obtener de vuelta el resultado.