Guida alla struttura del progetto di applicazione a livelli MVVM, DDD e WPF

Sto cercando di impostare la struttura della mia applicazione in VS e voglio "provare" e in futuro dimostrarlo a un livello ragionevole. Questa applicazione sarà una riscrittura WPF di una vecchia app Winform che non aveva seguito alcuna convenzione. No livelli, livelli, acronimi, ecc ...

È un'applicazione enterprise piuttosto ampia. Ho pianificato di utilizzare Linq To SQL come lo sono i miei DB e molto probabilmente sarà sempre MS SQL. Inoltre ho già un set di abilità.

Voglio seguire MVVM e DDD il meglio che posso ma mi confondo sulla struttura della mia applicazione quando li combino. Vorrei provare e illustrare con alcuni esempi.

Quando seguo MVVM la mia struttura di cartelle può apparire così:

Views
Models
ViewModels
Helpers

ma come si inserisce in un approccio stratificato DDD semplicistico in cui la mia struttura del progetto potrebbe assomigliare a questo:

MyApp.UI
MyApp.Domain
MyApp.Data

Ho messo il livello Modelsnel dominio o ho 3 versioni di dire Person? Questo porta ad un'altra domanda su dove dovrei mettere il mio repository e le mappature di DB Object su Domain Object? Suppongo che i dati ...

ViewsOttengo andrebbe nell'interfaccia utente ma sarebbe ViewModelsanche?

Infine, dove dovrei incorporare la mia logica di business?

Ho trovato quanto segue su CodePlex, Esempio DDD , ed è stato di aiuto, ma sembra essere per un'app Web anche se potrebbe non avere importanza e la mia ignoranza splende attraverso.

Non fraintendetemi, so che posso avere quante più cartelle e chiamarle come voglio. Sto cercando di capire dove posizionare le cose in modo che questo possa essere scalabile, non come si chiamano necessariamente quei luoghi.

Il cuore della mia domanda potrebbe essere mostrato in questo modo.
Ho un tblPersonoggetto generato da *.dbml. Questo è ovvio e appartiene al mio livello "Dati".
Ora avrei Model, DTO, Domain Model o qualunque cosa si chiamasse in un Layer separato (progetto?) Chiamato Person. Avrei bisogno di un Mapperper Persona tblPersonche non sono sicuro dove mettere.
Quindi, avrò un ViewModel per, diciamo, EditPersonche avrebbe le sue proprietà da cui attinge Personma forse anche di più.
Finalmente avrei avuto una vista che era legata a quel ViewModel ....

Per essere chiari, il paragrafo è riempito con le mie ipotesi e ipotesi e spero che qualcuno mi aiuti a liberare l'aria per me o offrirà insight in modo che tra 6 mesi o un anno da adesso non mi stia prendendo a calci più del necessario.

MVVM è un modello di interfaccia utente ed è utilizzato in un client.

Le parti del dominio in DDD utilizzate nel client sono probabilmente (una parte del) Modello

View e ViewModel sono solo client.

Ho inserito Repository nel (o vicino) modello perché sincronizzano il modello con il back-end.

Sì, molte volte ciò comporterà più classi Person in diversi spazi dei nomi. Potrebbero iniziare in modo molto simile ma potrebbero finire in modo molto diverso dopo un paio di iterazioni o rilasci.

MODIFICARE

Chiarire la parte relativa ai repository e spiegare meglio il posizionamento della Business Logic

Se si sta creando un sistema che contiene un client separato e i repository lato server / back-end possono essere utilizzati nel client e nel server. Nel client per fornire un'astrazione dei server e nel server per fornire un'astrazione di altri server e origini dati. È solo uno schema.

Per quanto riguarda le regole aziendali: se usi quelle nel client assicurati di applicarle anche nel server. Non fidarti mai di un cliente. Le regole aziendali nel client consentono una rapida convalida dell'input e impediscono viaggi di andata e ritorno al server.

Penso che DDD appartenga al lato server e 'perde' al client.

Hai la giusta direzione nella scelta del modello di progettazione MVVM per l'applicazione WPF.

Do I put the Models in the Domain layer?

Sì, i tuoi modelli possono essere collocati nel dominio

Where would I put my Repository and mappings of DB Object to Domain Object?

I tuoi repository possono essere posizionati nel layer in cui è posizionato il tuo dominio. I tuoi oggetti di mappatura (chiamati anche DTO - oggetti di trasferimento del dominio) dovrebbero essere collocati nel tuo livello di servizio e puoi usare un potente strumento AutoMapper di mappatura per mappare facilmente i tuoi oggetti di dominio su DTO.

ViewModels also?

I ViewModel devono essere posizionati sul lato client (livello). Puoi costruire i tuoi modelli di vista da uno o più DTO, a seconda delle tue viste.

Per quanto riguarda DDD , vorrei suggerire di leggere questo argomento e chiarire che è necessario disporre di un modello di progettazione basato su dominio. ecco una discussione sul fatto che il 95% di tutte le applicazioni software rientri nelle categorie "non così buone per l'utilizzo di DDD".

Modifica: il riferimento è stato aggiunto sopra e grazie vai a @Den!

Prima di approfondire ciò che va dove, parliamo di cosa dovrebbe fare ogni strato.

Il punto di forza di MVVM è il legame tra la vista e il modello di vista. L'obiettivo qui è eliminare la logica all'interno della vista.
Come la vista, il modello dovrebbe essere piuttosto leggero e utilizzato solo per accedere alle informazioni (dati) necessarie per il funzionamento del modello di vista. Il modello può fondere l'accesso a diverse origini dati, ma non dovrebbe avere una logica aziendale. Nella maggior parte dei casi, hai un singolo archivio di dati da colpire. In alcuni casi no. In caso contrario, è opportuno utilizzare il modello per oscurare l'origine dei dati dalla macchina virtuale.

Un punto implicito di MVVM è che i dati sono già archiviati e il progetto non è responsabile del mantenimento della sua organizzazione. Alcuni progetti hanno la fortuna di sfuggire a questa ipotesi, la maggior parte dei progetti a cui ho lavorato non è stata così fortunata. Basti dire che i dati sono un altro livello con cui dovremo confrontarci.

Darei il mio progetto in questo modo:

 project.Views
 project.ViewModel
 project.Model
 project.DataStructs

e questo livello può essere aggiunto secondo necessità:

 project.Helpers

Sto separando gli helper dal resto dello stack in modo che non venga confuso come un livello dello stack dell'applicazione.

Disclaimer: non sono un esperto di DDD, ma capisco l'essenza generale e vedo il valore nell'approccio.

Il tuo dominio sarà il set di problemi che stai considerando.
I modelli di dominio corrisponderanno principalmente ai ViewModels creati; un po 'all'interno delle viste; e un piccolo pezzo all'interno del Model / DataStructs.

Quindi, come funzionerà?
Se hai la possibilità di modificare le strutture di dati esistenti, quelle nuove che crei dovrebbero essere correlate al problema che stai cercando di risolvere. Hai un oggetto cliente? Quindi dovresti avere una / alcune tabelle relative al cliente. Hai fatture o prodotti? Stessa storia: dovrebbero essere create tabelle e strutture che si mappano su quegli oggetti business.

Il dominio verrà espresso attraverso i tuoi oggetti ViewModel e le viste che presenti di tali oggetti. Se è necessario modificare i record del cliente, si avrà una macchina virtuale per la gestione di tale attività.

Alle tue domande:

1. Non provare a sovrapporre DDD su MVVM. Semplicemente non funzionerà. DDD non è un modello di layout, è un approccio per visualizzare il tuo problema generale.
2. Repository e Mappings vivranno in project.Data o project.Model come appropriato.
3. Non avere un livello chiamato UI a meno che non sia quello che vuoi chiamare project.Views.
4. Business Logic andrà nel View-Model.