Sei sulla strada giusta su DDD a seconda di quanto sottili/spessi sono i livelli di servizio del dominio &. DDD dice che la conoscenza (cioè la logica di business) dovrebbe essere scricchiolata nel modello di dominio. Spostare i problemi di accesso ai dati al DAL è in linea con DDD, ma penso che lo spostamento della logica aziendale in un livello di servizi non lo sia. Se si dispone di un livello di "modello di dati" thin Domain (principalmente per le entità) e di un thick layer di servizi (principalmente per "business logic"), è possibile che sia presente un anemic domain.
Inoltre, non vi è tecnicamente alcun "Service Layer" in DDD. Potrebbe esserci un "Application Layer", ma dovrebbe essere sottile e solo essere responsabile per il flusso di applicazioni/gestire le durate della classe del dominio. Questo è essenzialmente ciò che i controllori fanno in .NET MVC, gestiscono il flusso delle applicazioni nel contesto del web http.
Se riempire tutta la logica all'interno del Modello ha reso il tuo codice eccessivamente complicato, sarei interessato ad ascoltare esempi di ciò che intendi per "eccessivamente complicato". Potresti modellare correttamente un dominio complesso o ci sono possibilità che tu abbia potuto passare ai pattern DDD per cose semplici. Direi che come hai elencato nella tua domanda, l'arco non è DDD. Lo chiamerei semplicemente "Architettura stratificata", ma è perché preferisco usare il termine "tier" solo quando si parla di arch. Fisico. Tuttavia, la tua architettura logica è stratificata.
Mi piace molto il fatto che Darin si sia collegato all'arco di cipolla nella sua risposta. Sto diventando un grande fan di questo, e trovo che non sia esclusivo del DDD.Se il tuo codice utilizza l'iniezione di dipendenza per risolvere le dipendenze dell'interfaccia con le implementazioni di runtime, potresti avere una forma di arco di cipolla. Ad esempio, definisci eventuali interfacce nel tuo DAL? Le implementazioni di queste interfacce sono risolte in fase di runtime?
Ecco un esempio di un arco che sto iniziando a utilizzare nei miei nuovi progetti. E 'una combinazione di cipolla + DDD:
API Progetto/Struttura: generici interfacce, enumerazioni, classi e metodi di estensione utilizzati da tutti gli altri livelli. Non è necessario essere separati dal dominio, ma possibile.
Domain Progetto/Assemblea: tutte le entità e la logica aziendale. Dipende solo da API. Utilizza pattern DDD come factory, service, specifiche, repository, ecc. Contiene anche altre interfacce specifiche del dominio che non sono definite nell'API.
Impl Progetto/Assieme: implementazioni di interfacce definite in API e Domain. È qui che viene implementato EF DbContext, come ad esempio la registrazione, l'invio di e-mail, ecc. Tutte queste implementazioni sono iniettate in dipendenza, quindi tecnicamente potresti avere diversi progetti/assiemi Impl.
UI Progetto/Assemblea: questo è il progetto MVC. I controller consumano direttamente la superficie del dominio e non passano attraverso un'applicazione o un livello di servizio. Qualsiasi dipendenza di interfaccia in fabbriche, servizi, repository, ecc., Viene iniettata nel dominio dal controller usando MVC IoC (constructor injection).
Ho inserito un livello API proprio al centro ma è possibile combinare i progetti API e Dominio in uno solo. Ad ogni modo, la grande parte carnosa della cipolla è il Dominio, e ha una stratificazione interna. Ad esempio, i Servizi possono dipendere dalle Fabbriche, che dipendono dai Repository, che dipendono dalle Entità.
Il progetto Impl è quello che si vede come la buccia di cipolla "Infrastruttura" nel diagramma di Palermo. Si trova sul bordo esterno insieme all'interfaccia utente e non contiene alcuna conoscenza specifica del dominio. Sa come inviare e-mail, archiviare/recuperare i dati utilizzando EF, ecc. Se vuoi, puoi avere più di 1 di questi - ad esempio 1 Impl per l'accesso ai dati, 1 Impl per gestire la posta, ecc.
MVC ha i controller e le visualizzazioni e si concentra sull'interfaccia utente e sul flusso dell'applicazione web. Tutto ciò che richiede una conoscenza specifica del dominio è delegato al dominio e le classi di dominio sono incorporate nel gestore. Ciò significa che tutte le interfacce basate su un costruttore nelle classi di dominio vengono risolte automaticamente dal contenitore IoC.
Come nota finale, la programmazione rispetto alle interfacce definite nelle classi API e Dominio significa che è possibile testare unitamente il progetto del dominio separatamente dal progetto MVC.
Avete qualche buon esempio di progetti ASP.NET MVC basati su DDD? O quelli che utilizzano l'architettura che descrivi? Ho cercato di leggere il codice di tutti i progetti MVC ASP.NET che posso per capire quali pratiche vengono utilizzate, ma è estremamente difficile. –
Vorrei chiacchierare di questo con voi prima di postare una risposta al tuo commento: http://chat.stackoverflow.com/rooms/9000/danludwig-private-room – danludwig
Risposta così interessante! Non so come Google mi abbia indirizzato a questo vecchio post ma è davvero buono. Potresti scrivere un articolo in Code Project riguardante DDD e Onion Architecture con un esempio :) O lo hai già fatto: D – Celdor