Si tratta di una buona soluzione per la struttura di Visual Studio per un servizio Web RESTful progettato da domini?

Questa struttura di cartelle è ispirata al famoso manuale Implementazione del design basato sul dominio di Vaugh Vernon.

Soluzione:
├ WebService ^{_{(i servizi REST si trovano qui)}} ├ WebServiceTests
├ Applicazione ^{_{(I servizi dell'applicazione risiedono qui)}}
├ ApplicationTests
├ Dominio ^{_{(Entità, VO, Servizi di dominio, fabbriche di dominio, specifiche, eventi di dominio, Interfacce di repository, interfacce di servizi di infrastruttura)}}
├ DomainTests
├ Infrastruttura ^{_{(Archivi, Servizi infrastruttura impl., Adattatori per servizi esterni)}}
└ InfrastructureTests

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

Non creare una cartella interfaces o services nel tuo livello dominio, ma le classi correlate dovrebbero essere raggruppate per funzionalità nei moduli.

Per quanto riguarda la struttura, mi sembra OK anche se mi sarebbe venuto in mente con nomi diversi, più auto-descrittivi, come "YourProjectWebApi" invece di "Base" , "Dal.External" invece di "Dal.Services" e così sopra.

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

In genere mi deduco dal fatto che Dal.Db non ha alcuna dipendenza da Biz.Domain, che il livello Dominio esegue un mapping tra DTO dal progetto Interfaces (restituito dai Repository?) e i propri oggetti Dominio. Ciò non sarebbe corretto in una tipica architettura DDD (== "onion" o "esagonale") - il livello Domain non dovrebbe fare riferimento ad altri progetti. Per lo stesso motivo, le interfacce del repository devono essere dichiarate nel dominio e non in Interfaces come immagino siano.