DDD - Come posso evitare Crossing Boundaries aggregate qui?

Question

Stiamo lavorando su un nuovo progetto (ri-scrittura di app esistenti), e sto correndo in problemi con il mio modello di dominio / design repository.

Questa è una versione (semplificato) di due porzioni chiave del nostro modello di dominio:

|

Come potete vedere, ho un concetto astratto di un Post , che può essere le cose come una recensione, una discussione, una foto, un video, ecc messaggi possono anche avere commenti.

Ho anche un concetto astratto di un posizione , che sono, ovviamente, le cose come vie, città, quartieri, ecc.

Ora, questo, naturalmente, guardato a me come due radici di aggregazione chiare.

Così ho creato due depositi, uno chiamato PostRepository , e un altro chiamato LocationRepository .

Questo è stato tutto funzionava bene, posso aggiungere / ottenere qualsiasi tipo di messaggio (o un commento), e aggiungere / ottenere qualsiasi tipo di posizione tramite uno di questi due repository.

Ma ora im nello scenario di una "landing page" per una città (per esempio).

In questa pagina, ho bisogno di mostrare praticamente "tutti i messaggi per questa posizione".

Come è quello definito? Beh, un messaggio può essere (opzionalmente) tagged in un Posizione. Attuazione dettaglio, quindi non voglio andare troppo in profondità in dati (come non è quello che DDD è di circa), ma in sostanza non c'è intelligence geospaziale per capire quale i messaggi sono contenuti in una posizione particolare dalla file di forma del luogo, e il latitudine / longitudine del tag post.

Ma come posso recuperare queste informazioni senza attraversare i confini?

Quali repository si usa? Ho bisogno di una nuova?

Se è importante (o per i curiosi), si tratta di un'applicazione web (ASP.NET MVC), con un database SQL Server 2008 e Entity Framework 4.0.

Se avete bisogno di qualsiasi chiarimento, me lo faccia sapere.

Modifica

Al momento utilizza una versione modificata del modello specifiche al fine di recuperare modelli di dominio.

Per esempio, questo è il codice nel nostro BLL per recuperare tutte Review dove Score> = 4:

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

Ma ora ho bisogno di un po 'di codice come questo:

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

Il problema è che non so come fare query precedente senza l'aggiunta di un intermediario join-entità (LocationPost - come è una relazione molti a molti)., E aggiungere un FK per il modello di dominio Pubblica che

Ma facendo questo, sto attraversando i confini aggregati -? Non sono io

Answer 1

I legherebbe post per la posizione al momento della creazione in modo che per ogni posizione che posso ottenere (tramite un repository) l'elenco dei posti associati. Si sarebbe simile a questa:

di creazione:

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

Recupero:

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

Sotto il cofano, l'associazione tra pali e posizione sarebbe essere implementato come un molti-a-molti tabella. C'è un problema con questa soluzione:. L'aggiunta di una nuova posizione richiede di eseguire la scansione di tutti i messaggi e assegnarli alla nuova posizione (se applicabile)

La speranza che aiuta.

Answer 2

Perché questo problema un? Secondo Evans nel suo libro, una AR può benissimo fare riferimento a un'altra AR. (Si può, tuttavia, non fare riferimento a un elemento figlio in un AR da un'altra AR)

Anche, sono luoghi davvero radici di aggregazione? La definizione di una radice aggregato è che agisce come un confine di concistency. Non che si adattano alla definizione di una posizione? Direi che una posizione è un oggetto di valore.

Non ci sono praticamente due campi qui per quanto riguarda i repository ed associazioni AR:

Uno che dice che tutte le radici di aggregazione sono a essere recuperati attraverso i loro rispettivi repository, e AR di dovrebbe usare rapporti morbidi, ad esempio, di ID tra loro

E uno che dice che le radici di aggregazione possono benissimo recuperano altre radici di aggregazione associati e che un repository è semplicemente un modo per trovare radici di aggregazione.

Answer 3

Diciamo che è stato utilizzato il modello specifica, si potrebbe costruire un messaggio specifica utilizzando un oggetto Location? Poi basta passare la specifica al tuo post Repository, e tornare il risultato.