DDD, NHibernate e struttura del progetto/denominazione

Question

Che cosa si consiglia come struttura di progetto corretta per una soluzione WebForms che utilizza NHibernate e tenta di introdurre alcuni concetti DDD?

Supponendo che lo spazio dei nomi di root e nome della soluzione è campione

• Sample.Domain - contiene i miei oggetti di dominio e il mio file di mapping
• Sample.Repositories - contiene i miei archivi e file di configurazione di connessione NHibernate
• Campione .Business - contiene la mia logica aziendale
• Sample.Web - il progetto WebForms attuale - tutto Presentazione

Cosa sto dimenticando? C'è un modo più standard per nominarli?
Qualsiasi post del blog sull'argomento?

Answer 1

Alcune parti mancanti sembrano essere una posizione centrale per i servizi necessari in tutta la soluzione e progetti di test. Io di solito hanno qualcosa di simile:

• Sample.Core - servizi e il codice che devono essere utilizzato in tutta l'applicazione
• Sample.Data - classi di dominio e interfacce repository
• Sample.Data.NHibernate - mappatura file, config fluente, ecc e le implementazioni di repository, fondamentalmente dati qualsiasi cosa strato mappatura specifica
• Sample.Services - implementazioni di servizi e interfacce
• Sample.Web - applicazione web

Ho un albero corrispondenza di progetti di test:

• Test \ Sample.Core.Tests
• Test \ Sample.Data.NHibernate.Tests
• ecc ...

Ovviamente, l'albero diventerà più complesso a seconda del progetto. Per quanto riguarda le discussioni, controlla lo Onion Architecture. Puoi anche consultare i progetti di esempio su Domain-Driven Design e vedere cosa puoi prendere da quelli.

Answer 2

ho trovato ognuno ha le proprie preferenze per la denominazione, preferisco:

• Sample.Domain - oggetti di dominio, file di mapping
• Sample.Services - logica di business e servizi (e repository, anche se io potrebbe vedere la separazione di questi fuori)
• Sample.Web - Web Stuff.
• Sample.Migrations - Migrazioni dei dati.

Ben Scheirman ha anche pubblicato di recente su questo: Exporting Visual Studio Solutions with Solution Factory.

Lui utilizza una struttura diversa ma include anche un ottimo modo per standardizzare il modello.

Answer 3

Lo tengo semplice e mi propongo di separare per spazio dei nomi piuttosto che per progetto, soprattutto all'inizio. Di solito inizio con tre progetti nella soluzione:

• Esempio - contiene spazi dei nomi Sample.Model, Sample.Model.Mappings e Sample.Services.
• Sample.Tests - contiene test di unità è strutturato come Sample.
• Sample.Web - UI

Answer 4

Si può vedere come si è fatto in s#arp architecture. È un quadro architettonico molto solido