Sto rompendo i miei confini aggregati?

Question

Sto modellando un'applicazione ASP.NET MVC molto semplice utilizzando NHibernate e mi sembra di essere bloccato sul mio progetto. Ecco uno schizzo del mio modello:

model 1 http://i29.tinypic.com/309614n.jpg

Come si può vedere questo è molto semplice, ma ho alcune preoccupazioni su di esso. L'entità radice utente e l'entità radice dell'organizzazione stanno accedendo allo stesso figlio entità Organization_Users tramite due relazioni uno-a-molti. Questo non sembra giusto e penso che sto rompendo i confini aggregati. Questo modello odori a me, ma mi piace l'idea perché vorrei avere codice come questo:

var user = userRepository.Load(1); 
var list = user.Organizations; // All the organizations the user is a part of. 

e

var org = orgRepository.Load(1); 
var list = org.Users; // All the users in an organization. 

anche i dati aggiuntivi nella tabella come contrassegnato e il ruolo sarebbe stato utilizzato dai l'entità dell'organizzazione. È un cattivo design? Se hai pensieri che sarebbero grandi. Sto ancora cercando di pensare al DDD. Grazie

Answer 1

Ho usato un approccio simile al tuo primo modello in diverse occasioni. L'unica soluzione con questo approccio è la necessità di creare una classe OganizationUser nel dominio per gestire il ruolo e campi contrassegnati dal proprio dominio. Questo ti lascerebbe qualcosa di simile nel tuo codice.

var user = userRepository.Load(1); 
var list = user.OrganizationUsers; // All the organizations the user is a part of including their role and flagged values. 

var organization = list[0].Organization; 

* Se avete intenzione di essere l'iterazione attraverso tutte le organizzazioni a utenti molto spesso probabile che ci si vuole carico impazienza la Organizzazione entità con OrganzitionUser

Con il secondo disegno che inviato sembra che tu possa aggiungere un utente a OrgUserDetails senza aggiungere l'utente a OrganizationUser. Non sembra qualcosa che vorrei sostenere dal mio dominio.

Answer 2

Questa è una tipica relazione molti-a-molti. E le tabelle Organization_Users sono la tabella bridge. Infatti, NHibernate e tutti gli altri strumenti ORM hanno funzionalità integrate per supportare la tabella bridge.

Questa cosa dovrebbe essere risolta a livello di modellazione dei dati piuttosto che a livello di applicazione. Dovresti analizzare il tuo modello di dati e si raccomanda di evitare le relazioni molti-a-molti (nel senso che se non è la necessità del modello di dominio, dovresti cercare di evitare la relazione molti-a-molti).

Per prima cosa è necessario assicurarsi che la relazione molti-a-molti nel modello di dati sia necessaria per il mapping delle entità di dominio. Una volta che avete fatto questo allora il modello rappresentato nel diagramma è ok per mappare queste relazioni a livello di applicazione

Answer 3

Le prime cose da considerare in DDD sono:

• dimenticare lo schema del database (non c'è alcun database!
• quali azioni verranno eseguite su tali entità da una prospettiva di dominio?

Answer 4

mia comprensione è:

Un utente può appartenere a organizzazioni 0-a-molti. E Un'organizzazione è costituita da 0-a-molti utenti.

Sono entrambi corretti? Se è così, questo mi sembra un molti-a-molti.

In molti a molti, è necessario un oggetto di tipo relazionale per colmare questa lacuna. Il problema è che non c'è user_organization nel dominio.

Questo mi fa pensare che non dovresti avere user_organization come parte del tuo dominio, di per sé. Sembra un dettaglio di implementazione.

D'altra parte, forse ha senso nel proprio dominio disporre di un elenco che contiene gli utenti in un'organizzazione e memorizza il proprio ruolo e altre informazioni specifiche per tale relazione.

Answer 5

Penso che la tua modella stia bene.Di solito penso alle radici aggregate del dominio, quando penso a loro affatto, in termini di ciò che è esposto pubblicamente, non di un'implementazione interna. Con le relazioni penso a quale entità "indossa i pantaloni" nella relazione. Cioè, è più naturale aggiungere un utente a un'organizzazione o aggiungere un'organizzazione a un utente? In questo caso entrambi possono avere senso, un utente si unisce a un'organizzazione; un'organizzazione accetta un utente per l'adesione.

Se il dominio vede la relazione dal punto di vista dell'utente, è possibile inserire i metodi per mantenere (aggiungere, rimuovere, ecc.) La relazione sull'utente ed esporre una raccolta di sola lettura sull'organizzazione.

In risposta al tuo secondo progetto (sarebbe stato meglio se avessi modificato la domanda originale): non mi piace affatto. Il tuo design originale va bene. Non ignorerei necessariamente il database durante la progettazione delle classi, un buon design dovrebbe modellare accuratamente il dominio ed essere semplice da implementare in un database relazionale. A volte devi scendere a compromessi in entrambe le direzioni per raggiungere il punto giusto. Non c'è termine di prigione per rompere i confini aggregati. :-)

Answer 6

Grazie a tutti per le vostre risposte. Sono stati molto utili.

Mentre pensavo un po 'di più alla mia modella, ho abbozzato qualcosa di nuovo che penso sarebbe stato meglio.

alt text http://i26.tinypic.com/ic0pw4.png

Il mio pensiero era questo:

1. Quando un utente accede al sito il sistema trova proprio account e quindi restituisce un elenco delle organizzazioni che sono parte di e diventa queste informazioni da l'oggetto user_organizations.

2. Quando un utente fa clic su una delle organizzazioni che si trova a parte, le indirizza al pannello di controllo dell'organizzazione.

3. L'organizzazione selezionata cerca quindi il ruolo di quell'utente nei suoi org_user_details per sapere quale accesso l'utente dovrebbe avere a quel pannello di controllo delle organizzazioni.

Ha senso? :)

Mi sembra che sarebbe un bene in un modello ma ho dei dubbi sull'implementazione del DB. So che non dovrei neanche preoccuparmene, ma non posso ancora rompere la mia cattiva abitudine! È possibile vedere che esistono tipi di dati duplicati nell'oggetto user_organizations e l'oggetto org_user_details. Non sono un professionista di DB ma è un cattivo progetto di DB? Dovrei invece combinare i dati di user_organizations e org_user_details in una tabella come quella del mio primo post e dire semplicemente a NHibernate che l'utente la guarda come una relazione molti-a-molti e l'organizzazione la guarda come una relazione uno-a-molti ? Sembra che sto ingannando il sistema. Scusa se mi sono sembrato davvero confuso su questo.

Cosa ne pensi? Sto pensando troppo a questo? : P