Organizzazione della soluzione di Visual Studio per microservizi?

4

Stiamo iniziando a ridefinire uno dei nostri principali prodotti in una architettura orientata ai microservizi . Attualmente stiamo utilizzando la struttura di cartelle Implementazione di Domain Driven Design per organizzare i file di origine . Tuttavia, stiamo scoprendo che i progetti di dominio e infrastruttura non stanno facendo un buon lavoro nell'organizzare logicamente ciascun microservizio.

Ad esempio, abbiamo la nozione di "gestore di eventi di dominio" che funziona quando riceve un messaggio. Attualmente tutti questi gestori vengono semplicemente scaricati nella stessa cartella / spazio dei nomi "Gestore" all'interno di "Dominio". Forse va bene, ma sembra che non ci sia una separazione organizzativa tra i contesti dei microservizi. Un altro esempio sono le nostre entità di dominio: un'entità "membro" può avere significati diversi (e persino strutture differenti) a seconda del contesto del microservizio.

Stiamo anche prevedendo alcuni problemi con l'implementazione in futuro. Ovviamente vogliamo che il processo di implementazione sia il più possibile disgiunto. Distribuire ogni servizio con una DLL "Dominio" da 10mb piena di assembly che non verrà mai caricata non è auspicabile.

È meglio organizzare l'origine in spazi dei nomi e cartelle che rispettano le divisioni logiche dei microservizi? Ogni microservizio dovrebbe avere la propria soluzione con ciascuno dei progetti DDD prescritti? Dovremmo "salire di livello nell'albero" e creare una soluzione per ogni nodo nella struttura DDD, quindi creare singoli progetti per ogni microservizio?

Mi sento come se fossi in un territorio in qualche modo inesplorato qui e apprezzerei qualche consiglio!

    
posta Daniel 28.03.2017 - 16:33
fonte

2 risposte

3

Alla fine abbiamo scoperto che le decisioni prese sulla pipeline di devope e sulla piattaforma dei microservizi probabilmente impongono come sono organizzati i progetti e le soluzioni di Visual Studio.

Inizialmente, abbiamo deciso che una soluzione per microservizio era la soluzione migliore. Anche le comuni librerie "core" avevano le proprie soluzioni. Le librerie "core" venivano quindi ospitate tramite feed interni di nuget per il consumo da parte di qualsiasi servizio. Questo ci ha dato la possibilità di mantenere i servizi su vecchie versioni di librerie, se necessario. Se avessimo optato per Docker Swarm o Kubernetes come piattaforma, penso che questa decisione "soluzione per servizio" avrebbe funzionato bene. Tuttavia, abbiamo finito per scegliere Service Fabric, che ha influito sulla nostra decisione.

In Service Fabric, una "applicazione" ospita un "servizio" (ti incoraggio a leggere di più sulla nomenclatura se sei interessato a questa opzione). La soluzione di Visual Studio deve essere adattata in qualche modo per contenere queste dipendenze. A seconda di come pianifichi di scalare i tuoi servizi, "soluzione per servizio" potrebbe non essere un'opzione (per ragioni che esulano dall'ambito di questa risposta).

In conclusione : scegli prima la tua piattaforma e i tuoi sviluppatori. Penso che la soluzione per servizio sia l'ideale, ma la logistica della tua piattaforma potrebbe essere proibitiva.

    
risposta data 28.06.2017 - 23:52
fonte
1

Mantenere più servizi nella stessa soluzione potrebbe essere abbastanza ok e la pipeline di devope potrebbe essere regolata per supportare la tua struttura.
I confini aziendali dovrebbero guidare il tuo design. Avevamo logicamente un servizio, ma tecnicamente era diviso in 2 - sito web e web API. Ha senso tenerli nella stessa soluzione, anche Devops ha bisogno di distribuirli separatamente.

    
risposta data 12.11.2017 - 06:51
fonte

Leggi altre domande sui tag