Architettura DDD in un'applicazione Web MVC

7

Sto assemblando un'applicazione web con DDD, tuttavia sto lavorando per mettere il modello DDD del libro di testo in un'applicazione MVC reale.

Al momento ho questi livelli:

Controller > ViewModelsBuilders > Servizi di dominio > Aggregati, API e repository remoti

  • Controller
    I risultati dell'azione richiedono un modello di vista
  • ViewModelsBuilder
    Questi creano il modello di visualizzazione necessario da un insieme di servizi di dominio.
  • Servizi di dominio
    Questi sono il punto di accesso al mio dominio e utilizzano Aggregati (per logica di dominio complessa) che trasmettono dati da API e repository remoti
  • Aggregati ed entità
    Questi sono tutti limitati allo scopo dell'assembly e contengono la logica aziendale

Domande:

  1. Questa è la struttura corretta, nel caso in cui si trattasse dei servizi di dominio o dei costruttori del modello di visualizzazione che raggruppano tutto?
  2. Gli oggetti restituiti dai Domain Services dovrebbero essere semplici DTO o entità reali, nascondendo i metodi con i livelli di accesso?
  3. I servizi di dominio dovrebbero essere i gatekeeper o i builder del modello di visualizzazione dovrebbero accedere alla radice aggregata, ai repository, ecc.?
posta John 09.06.2015 - 21:20
fonte

1 risposta

6

L'approccio che ho usato in passato che può essere applicato in MVC & I progetti WebAPI seguono:

  • Endpoint (Controllers, ApiController) restituisce ViewModels (DTO)
  • Livello aziendale / Livello applicazione / Servizio dominio - restituisce i dati dell'applicazione
  • Livello di accesso ai dati - Pattern di repository - restituisce entità modello DB

Ogni livello è responsabile dei propri dati.

    
risposta data 21.06.2015 - 23:50
fonte

Leggi altre domande sui tag