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

14

Sto costruendo una soluzione RESTful per l'API Web .NET 4.5 C # e vorrei che qualcuno mi dicesse se la mia soluzione di progetto è corretta e / o saggia (-enough?) per una soluzione progettata utilizzando 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. Contiene quasi nessuna logica oltre la raccolta di valori dagli oggetti richiesta e chiedendo il livello BizApi per il lavoro.

  • /Biz.Api

(Riferito da Base))

Fornisce i servizi di dominio e consente al progetto dell'interfaccia / Base di accedere agli oggetti logici di business del dominio nel progetto /Biz.Domain.

  • /Biz.Domain

(Riferimento a Biz.Api)

Fornisce le classi di dominio per il livello Biz.Api. Questi forniscono metodi per manipolare i dati del business in memoria.

  • /Dal.Db

(Riferimento a Biz.Api)

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

  • /Dal.Services

(Riferimento a Biz.Api)

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

  • / Interfacce

(Riferito dalla maggior parte dei progetti sopra)

Contiene le classi DTO per il trasferimento dei dati attorno alla soluzione e le interfacce C # per definire contratti per cose come IoC.

    
posta Matt W 10.09.2014 - 14:22
fonte

2 risposte

19

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.

    
risposta data 10.09.2014 - 23:22
fonte
1

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.

    
risposta data 11.09.2014 - 11:43
fonte

Leggi altre domande sui tag