È una buona struttura della soluzione Visual Studio per un servizio Web RESTful di progettazione guidata dal dominio?

Sto creando una soluzione RESTful per l'API Web C # .NET 4.5 e vorrei che qualcuno mi dicesse se la mia soluzione di progetto è corretta e / o saggia (-basta?) Per una soluzione progettata usando Domain Driven Design, per favore.

La soluzione è stata suddivisa in 6 progetti:

• /Base

(Non referenziato da nulla)

Il progetto web e costituisce l'interfaccia tra la soluzione e il mondo esterno. Contiene i controller API Web. Non contiene quasi alcuna logica oltre a raccogliere valori dagli oggetti richiesta e chiedere lavoro al livello BizApi.

• /Biz.Api

(Riferito alla base])

Fornisce i servizi di dominio e consente al progetto dell'interfaccia / Base di accedere agli oggetti della logica aziendale di dominio nel progetto /Biz.Domain.

• /Biz.Domain

(Riferito a Biz.Api)

Fornisce le classi di dominio per il livello Biz.Api. Questi forniscono metodi per manipolare i dati dell'azienda in memoria.

• /Dal.Db

(Riferito a Biz.Api)

Il livello del repository del database. Accede ai database e mappa i dati restituiti nei DTO interni definiti nel livello / Interfaces.

• /Dal.Services

(Riferito a Biz.Api)

Fornisce un livello proxy a dipendenze esterne come i servizi Web e mappa i dati restituiti ai DTO interni definiti nel progetto / Interfaces.

• Interfacce /

(Riferito dalla maggior parte dei progetti sopra)

Contiene le classi DTO per il passaggio dei dati intorno alla soluzione e le interfacce C # per definire contratti per cose come l'IoC.

Questa struttura di cartelle si ispira al famoso libro di design Implementing guidato dal dominio di Vaugh Vernon.

Soluzione:
├ WebService ^{_{(i servizi REST risiedono qui)}}
├ WebServiceTests
├ Applicazione ^{_{(i servizi dell'applicazione risiedono qui)}}
├ ApplicationTest
├ Dominio ^{_{(entità, VO, servizi di dominio, fabbriche di dominio, specifiche, eventi di dominio, interfacce di repository, interfacce di servizi di infrastrutture)}}
├ DomainTests
├ Infrastruttura ^{_{(Repository, Infrastructure services imp., Adattatori di servizi esterni)}}
└ Infrastructure Test

Comincio con una soluzione, quindi creo quattro progetti per ogni livello nella mia applicazione, quindi altri quattro progetti per ciascun livello di test.

Non creare una cartella interfaceso servicesnel tuo livello di dominio, invece le classi correlate dovrebbero essere raggruppate per funzionalità in moduli.

Per quanto riguarda la struttura, mi sembra OK, anche se avrei escogitato nomi diversi, più auto-descrittivi, come "YourProjectWebApi"invece di "Base", "Dal.External"invece di "Dal.Services"e così via.

Tuttavia, potrebbe esserci un odore nella parte "DTO interna", poiché si suppone che le entità escano dai repository e che siano in grado di intraprendere azioni di dominio (aziendali) direttamente su di esse. Le entità non sono solo DTO.

Mi rendo conto del fatto che Dal.Dbnon ha alcuna dipendenza dal fatto Biz.Domain,che il livello Dominio stia eseguendo una mappatura tra DTO del progetto Interfaces (restituito da Repository?) E i suoi oggetti Domain. Ciò non sarebbe corretto in una tipica architettura DDD all'avanguardia (== "cipolla" o "esagonale") - il livello Dominio non dovrebbe fare riferimento ad altri progetti. Per lo stesso motivo, le interfacce del repository dovrebbero essere dichiarate nel dominio e non Interfacescome credo.