DDD: dove conservare le interfacce di dominio, l'infrastruttura?

Question

Ha senso raggruppare tutte le interfacce del livello di dominio (moduli, modelli, entità, servizi di dominio, ecc.) All'interno del livello infrastruttura? In caso contrario, ha senso creare un progetto/componente "condiviso" che raggruppa tutti questi elementi in una libreria condivisa? Dopo tutto, la definizione di "Infrastructure Layer" include "librerie condivise per livelli di dominio, applicazione e UI".

Sto pensando di progettare la mia base di codice attorno ai livelli DDD: interfaccia utente, applicazione, dominio, infrastruttura. Ciò creerebbe 4 progetti rispettosamente. Il mio punto è, si fa riferimento al livello di infrastruttura dal livello di dominio. Ma se definisci le interfacce nel progetto Domain Layer, ad esempio per IPost, avrai un riferimento circulur quando devi fare riferimento al progetto Domain Layer dal progetto Infrastructure quando definisci il metodo IPostRepository.Save (IPost post) . Quindi, l'idea di "definire tutte le interfacce nella libreria condivisa".

Forse gli archivi non dovrebbero aspettarsi un oggetto da salvare (IPostRepository.Save (post IPost), ma invece, si aspettano i parametri dell'oggetto (che potrebbe essere un lungo set di parametri nel Save()). , questo potrebbe essere una situazione ideale che mostra quando un oggetto sta diventando eccessivamente complesso, e ulteriori oggetti di valore dovrebbe essere esaminato per esso.

Pensieri?

Answer 1

Eric, Ero via per una coppia, quindi perdonami per aver risposto così tardi. Per quanto riguarda il posizionamento dei repository, personalmente inserisco sempre i repository in un livello infrastruttura dedicato (ad esempio MyApp.Data.Oracle) ma dichiaro le interfacce a cui i repository devono conformarsi nel livello dominio.
Nei miei progetti il ​​Livello applicazione deve accedere al livello Dominio e Infrastruttura perché è responsabile della configurazione del livello dominio e infrastruttura.
Il livello dell'applicazione è responsabile dell'iniezione dell'infrastruttura corretta nel dominio. Il dominio non sa a quale infrastruttura sta parlando, sa solo come chiamarlo. Ovviamente utilizzo contenitori IOC come Structuremap per iniettare le dipendenze nel dominio. Ancora una volta non dichiaro che questo è il modo in cui DDD consiglia di strutturare i tuoi progetti, è solo il modo, io faccio architettura delle mie app. Saluti.

Answer 2

sto zitto di nuovo in DDD quindi non esitate per commentare se non sei d'accordo, come tu sono qui per imparare

Personalmente non capisco perché dovresti fare referen ce il livello infrastruttura dal tuo dominio. A mio avviso, il dominio non dovrebbe dipendere dall'infrastruttura. Gli oggetti Dominio dovrebbero essere completamente ignoranti su quale database sono in esecuzione o quale tipo di server di posta è usato per inviare mail. Riassorbendo il dominio dall'infrastruttura è più facile riutilizzarlo; perché il dominio non sa su quale infrastruttura è in esecuzione.

Quello che faccio nel mio codice fa riferimento al livello dominio dal mio livello infrastruttura (ma non il contrario). I repository conoscono gli oggetti del dominio perché il loro ruolo è quello di conservare lo stato per il dominio. I miei repository contengono le mie operazioni CRUD di base per i miei aggregati di root (get (id), getall(), save (oggetto), delete (oggetto) e sono richiamati dai miei controller.

Cosa ho fatto sul mio ultimo progetto (il mio approccio non è puramente DDD ma ha funzionato molto bene) è che ho astratto i miei repository con interfacce. Gli aggregati di root dovevano essere istanziati passando un tipo concreto di un repository:

L'aggregato di root doveva essere istanziato attraverso un repository usando il metodo Get (ID) o Create() del repository.Il repository concreto che costruisce l'oggetto si è passato in modo tale che l'aggregato potesse conservare il suo stato e lo stato dei suoi oggetti figlio ma senza conoscere nulla dell'implementazione concreta del repository es .:

public class PostRepository:IPostRepository 
{ 
    ... 
    public Post Create() 
    { 
     Post post=new Post(this); 
     dbContext.PostTable.Insert(post); 
     return post; 
    } 
    public Save(post) 
    { 
     Post exitingPost=GetPost(post.ID); 
     existingPost = post; 
     dbContext.SubmitChanges(); 
    } 
} 

public class Post 
{ 

    private IPostRepository _repository 
    internal Post(IPostRepository repository) 
    { 
     _repository = repository; 
    } 
    ... 
    Public Save() 
    { 
     _repository.Save(this); 
    } 

} 

Answer 3

io vi consiglio di prendere in considerazione Onion architecture. Si adatta molto bene con DDD. L'idea è che le interfacce repository siedono in uno strato appena fuori di dominio e di riferimento Enti direttamente:

IPostRepository.Save(Post post)

dominio non ha bisogno di conoscere a tutti i repository.

Il livello infrastruttura non è referenziato da Dominio o da chiunque altro e contiene implementazioni concrete di archivi tra altri materiali relativi all'I/O.La libreria comune con vari helper si chiama Application Core in questo caso e può essere referenziata da chiunque.