Come strutturare un progetto di cipolla

Question

Come strutturare un progetto di cipolla

#1 da (5 voti)
#2 da (1 voti)

6

Ecco un'implementazione di esempio che utilizza l'architettura di Onion: link

La pagina web suggerisce una struttura della soluzione di:

Domain - Solution Folder
Domain.Entities - Class Library Project
Domain.Interfaces - Class Library Project
Service Interfaces - Solution Folder
Service.Interfaces - Class Library
Services - Solution Folder
Services - Class Library Project
Infrastructure - Solution Folder
Infrastructure.Data - Class Library Project
User Interface - Solution Folder
MVC - MVC Project

Ho alcune domande:

Perché ci sono due cartelle di soluzioni nel livello di servizio? cioè Servizi e Servizi. Interfacce. Credo che ci dovrebbe essere uno come nel livello di dominio, ad esempio la cartella di soluzione di dominio contiene due progetti di libreria di classi (Domain.Entities e Domain.Interfaces). Normalmente lo considererei un errore, tuttavia ho visto altri progetti strutturati in questo modo.
Perché il livello di dominio e servizi è diviso in due progetti di librerie di classi (perché non avere un solo progetto di libreria di classi in ogni classe contenente e librerie).
Questa domanda afferma che TUTTE le interfacce dovrebbero essere contenuto nel livello del dominio. Tuttavia, tutti gli esempi di codice che ho esaminato inseriscono le interfacce del livello di servizio nel livello di servizio. Dovrebbero andare nel livello di servizio o nel livello di dominio?

c# domain-driven-design onion-architecture

posta w0051977 24.10.2017 - 16:56

fonte

2 risposte

Leggi altre domande sui tag c# domain-driven-design onion-architecture

Perché usare 'const foo = () = {}' invece di 'function foo () {}' CQRS in domini collaborativi

score 5 · Answer 1

Dal punto di vista di un progetto / cartella non c'è nulla di necessario da parte tua per stabilire un'architettura di Onion, sebbene i livelli nel modello suggeriscano luoghi naturali per mettere limiti di progetto / API.

Dai un'occhiata a questo diagramma:

Oradaiun'occhiataaquesto:

Oltreallaformadeidiagrammi,notiqualcosadiinteressante?

L'unicadifferenzasostanzialetraquestiduediagrammiècheildiagrammadicipollaconsentesolol'accessoaldatabaseattraversoillivellodiaccessoaidati.Nella"architettura tradizionale a livelli" sono consentite l'interfaccia utente e la logica aziendale accesso diretto al database e ad altri sistemi IT (ciò che l'autore chiama "infrastruttura"). In Onion Architecture, l'unica cosa che consente l'accesso al database sono le entità di dominio. Noterai che la maggior parte dell'interazione con questa architettura avviene al limite del livello di servizio (l'anello esterno).

Questo è tutto ciò che c'è da fare su Onion Architecture, davvero. Qui non sta accadendo nulla di speciale, se non una separazione più stretta tra gli strati. In effetti, direi che il modo in cui lo fa Onion è probabilmente il modo più comune in cui le architetture software dei domini aziendali vengono espresse al giorno d'oggi. Dovrei tornare a Winforms o ASP.NET (entrambi utilizzano ampiamente code-behind) per trovare un'architettura che assomigli più a ciò che questo autore chiama "Layered tradizionale".

score 1 · Answer 2

La tua soluzione / struttura del progetto non è dettata dall'architettura della cipolla. Se tu avessi un'applicazione molto semplice, potresti avere tutto nello stesso progetto, anche nella stessa cartella - e avere comunque un'architettura cipriota perfetta. Oppure potresti avere 100 progetti e mantenere l'architettura della cipolla.

L'architettura suggerisce "cuciture" in cui è naturale separare il codice se è necessario inserirlo in progetti separati, ma la struttura visualizzata è solo un esempio. In realtà, dovresti separare i progetti in base alla dipendenza e alle considerazioni sulla distribuzione.