Come ridisegnare e ridimensionare l'applicazione MVC legacy

Sto lavorando con un'app Web legacy per la gestione di un rifugio per animali che deve essere rearchitected / redesign, in modo che possa essere scalabile ed essere possibile distribuire in una posizione centrale.

Attualmente è distribuito fisicamente sui server presso le sedi dei clienti (9 e più in attesa che la centralizzazione sia possibile).

Breve descrizione dell'architettura / design corrente:

• 6 strati MVC 5, EF (primo codice):

  • entità con contesto DB (libreria di classi),
  • modello di dominio (libreria di classi),
  repository
  • con unità di pattern di lavoro e auto mapper (libreria di classi),
  • servizi (libreria di classi),
  • commons con NLog e la mappa della struttura (libreria di classi),
  • presentazione (MVC con visualizzazioni di rasoio).

• 6 moduli esistenti:

  1. Modulo di alimentazione con funzionalità di esempio: un. Alimenti, b. programma di alimentazione.
  2. Modulo ospedaliero con caratteristiche esemplificative: un. farmaci, b. malattia, c. piani di trattamento, d. quarantena.
  3. Modulo di bellezza con funzioni di esempio: un. metodi di pulizia, b. accessori e prodotti per la cura degli animali.
  4. Modulo di importazione file con funzionalità di esempio: un. rapporto basato sul punteggio sulla salute degli animali, immagini.
  5. Inserimento dati manuale 1 modulo con funzioni di esempio: un. attività quotidiane con cronologia, b. funzione di valutazione del comportamento basata sul punteggio
  6. Inserimento dati manuale 2 moduli con funzioni di esempio: un. descrizione delle condizioni fisiche degli animali, b. funzione di valutazione delle condizioni fisiche basata sui punteggi.

• Nuovi moduli richiesti:

  1. Modulo di notifica - messaggi in tempo reale / istantanei in cui si sono verificati eventi / azioni, ovvero scorte alimentari scarse, scorte di medicinali scarse, animali malati, condizioni fisiche < 50 o quando gli utenti inviano messaggi interni ad altri usi - SinglaR da utilizzare qui.
  2. Modulo del piano d'azione - generazione automatica del modulo con un piano d'azione in caso di qualsiasi azione / evento verificati, cioè scorte alimentari scarse, scorte basse di medicinali, animali malati, condizioni fisiche < 50 ecc.
  3. Modulo Analytics / Reporting in cui abbiamo già creato ca. 30 diversi modelli di report che utilizzano Power BI.
  4. Modulo di contatto - vari modi di comunicazione, ad esempio e-mail, messaggi istantanei,
  5. Modulo di gestione utenti - profili utente e ruoli

I nostri obiettivi:

• ha un'architettura scalabile,
• implementare nel data center, rimuovere dai percorsi dei clienti,
• offre prestazioni decenti,
• esporre i nostri dati in caso di necessità di client mobili o di condivisione di dati,

Domande:

1. Stiamo prendendo in considerazione il porting del livello di presentazione esistente per il solo progetto angolare 6 con autorizzazione basata su token:

   • È una buona idea avere un progetto di front-end in una soluzione non Visual Studio, eventuali svantaggi?
2. Desiderare esporre i nostri dati con .NET core WebAPI e consumarli nel nostro front-end.
   • Come gestire i casi che saranno difficili da coprire con le API se dovessimo disporre di un altro livello di servizio e che ci fosse WebAPI? Se sì, allora come consumare quel tipo di servizio dal front-end? Aggiungendo un altro progetto MVC o un modello diverso?
3. Aggiungiamo un pesante modulo di analisi / reportistica e discutendo le prestazioni mi sono imbattuto in "pattern query secret responsibility pattern" che consente di utilizzare db separati per operazioni di scrittura e lettura che nel nostro caso saranno per lo più report, ecc.
   • È possibile utilizzare CQRS con pattern MVC o dovrebbe essere DDD o qualcos'altro?,
   • in caso di due db di lettura / scrittura avremmo bisogno di una replica, sarebbe problematico, specialmente mantenendo i db in sincrono?,
   • Il CQRS si adatta al concetto WebAPI? Significa che la web api dovrebbe usare questo pattern o avremmo bisogno di un'altra astrazione?
   • Nella lettura di CQRS sql sono state menzionate le viste materializzate per il modello di lettura, queste sono in effetti un'opzione migliore rispetto alle visualizzazioni con indici, dovremmo considerarlo affatto?
   • Cambiamento della strategia di generazione di ID - attualmente utilizziamo "interi" per i nostri valori chiave, alcuni forum suggeriscono che l'introduzione di GUID potrebbe aiutare con le prestazioni soprattutto sulle richieste CREATE, ci sono altri problemi, vantaggi?

Dal punto di vista hardware stiamo considerando l'hosting di un'applicazione client su due VM utilizzando un bilanciamento del carico e una soluzione DB sepa- rata per cliente.

Dato che probabilmente non hai immaginato molta esperienza architettonica da parte mia, gradirei ricevere aiuto e indicare la direzione giusta.

Se pensi che potrebbero esserci alcuni esempi di architetture / disegni che potremmo adattare, ti preghiamo di dare un'occhiata.