Separa i progetti in Visual Studio e le cartelle in un singolo progetto per i microservizi

Question

Separa i progetti in Visual Studio e le cartelle in un singolo progetto per i microservizi

#1 da (3 voti)

3

Incerto se la domanda è troppo ampia o basata su opinioni. Anche se lo chiederò comunque.

Sto valutando la lettura tramite "Architectural eBook" di Microsofts, trovato link . Ha una soluzione di supporto che si trova su Github, link

L'applicazione di esempio fornisce diversi modelli da implementare all'interno dei tuoi microservizi, insieme a una raccolta di tecnologie e infrastrutture diverse.

Questo mi porta alla mia domanda.

Se osservi il progetto Ordering.API ( link ) l'autore ha scelto di inserire il proprio codice Dominio e Infrastruttura all'interno di progetti separati nell'API microservice che li sta utilizzando.

Questa immagine mostra 3 dei servizi, con l'ordine implementato con più progetti

Stranamente,ilprogettoeradivisoulteriormente;avendoancheunprogettoOrdering.Application,cheorafapartedelprogettoOrdering.API.Questaimmagineobsoletaneidocumentilodimostra.

Dato che i microservizi dovrebbero essere autonomi in quanto hanno un contesto limitato definito e questi modelli di dominio non dovrebbero essere usati al di fuori di questo microservizio quale sarebbe il vantaggio di strutturare il progetto in questo modo, al contrario di una struttura di cartelle all'interno il progetto Ordering.API?

domain-driven-design microservices visual-studio

posta Darren 24.10.2017 - 15:23

fonte

1 risposta

Leggi altre domande sui tag domain-driven-design microservices visual-studio

Progetta una classe che contiene informazioni di analisi È ancora utilizzato WSDL? [chiuso]

score 3 · Answer 1

build più veloci. se hai un singolo progetto per il tuo microservizio, deve ricompilare tutto (ottimizzazioni del compilatore nonostante). Se hai diviso il tuo codice in più progetti, solo il progetto che stai cambiando e i progetti che dipendono da esso sono ricompilati
Codice più probabilmente decoupled. Anche in microservizi con stretto, funzionalità isolata, i fondamenti del codice disaccoppiato ancora applicare. Quando hai le tue diverse preoccupazioni in diversi, progetti indipendenti, è molto più facile verificare che tu abbia separati i tuoi livelli in modo organizzato. Ad esempio, dì che lo sei utilizzando un ORM per l'accesso ai dati. Senza usare i progetti, quanto è facile per dimostrare che non stai utilizzando l'ORM direttamente nel tuo controllore? Con i progetti, il controller è in un binario diverso del tuo livello di accesso ai dati, quindi è piuttosto semplice dimostrarlo: il tuo progetto di controllore non ha nemmeno un riferimento ad esso!
Test unitari più semplici. Con le tue risorse separate in progetti, non devi includere riferimenti a tutte le terze parti pazze framework che utilizzi per l'accesso ai dati o il web hosting quando lo fai vuoi testare la tua logica aziendale di base. Concesso, in un mondo perfetto dovresti avere una copertura del codice al 100%, ma non siamo perfetti mondo. Più difficile è testare le cose semplici, meno è probabile è che saranno testati.
Distribuzioni più piccole. Progetti .NET, più o meno, da tradurre DLL sul lato di uscita (questa è una semplificazione, ma in generale, questo è il risultato finale a meno che tu non lo eviti in modo specifico). Quando tu cambia solo un progetto, devi solo ridistribuire una DLL. (Nota che questo è un motivo terribile per scegliere i progetti e le cartelle da allora dovresti comunque utilizzare build / implementazioni automatizzate, ma è un motivo comunque!)