Qual è la migliore architettura / progettazione di sistemi per lanciare la stessa app con gusti diversi e una logica leggermente diversa?

-1

Esiste una società diciamo "X" che si occupa principalmente di proprietà / immobili e ha un sito web (portale online) per visualizzare tali proprietà.

Proprio come qualsiasi altra grande azienda, quando hanno visto un concorrente l'hanno acquisito e lasciato intatto il retaggio della concorrenza tra le società affiliate, in modo che l'azienda crescesse e il beneficio finale andasse alla casa madre / capogruppo.

Ora considera "X" acquisito "Y". La direzione di X prese quindi la decisione di usare il codice sorgente di X rinnovando l'interfaccia utente e rapidamente rilancia Y nel mercato, oh e sì con lo stesso database e introducendo un nuovo valore / colonna per distinguere tra fonti / app per registrare l'attività di entrambi i portali. (Questo perché la gestione di Y non ha venduto codice o database ma solo il nome / SEO).

Il team di gestione dei prodotti di X ha deciso di utilizzare Y per indirizzare quelle aree in cui X è debole in modo che Y diventi più strong in quelle aree e competa con il resto. Questa modifica richiederà modifiche logiche a livello di app / modifiche nei codici. Ps. X alimenterà Y con nuovi record di lead / proprietà come aiuto per ottenere un vantaggio rispetto ad altri concorrenti.

Il problema che sta affrontando il team di ingegneri è:

  1. Il codice sorgente è un codice legacy e non è all'altezza del segno

  2. I dati di X sono già troppo grandi (diciamo 10 milioni di record)

  3. Lo schema / struttura del database è un disastro completo!

  4. Il team di ingegneri non ha mai avuto la possibilità di cancellare il debito tecnico e non lo vedranno neanche nel prossimo futuro.

Ps. alcune decisioni / logiche a livello di business come: X avrà i propri utenti e Y avrà i propri utenti (significa che devi registrarti a Y per pubblicare la tua proprietà o ottenere le statistiche specifiche dell'app, sebbene all'utente di X verrà data la possibilità di pubblicare cose su Y senza registrarsi e che deve essere gestito nella logica di business dell'app.)

Come ingegnere, vedo 2 opzioni. O per andare in modalità single-tenant o multi-tenant. Invece condivido la mia opinione, mi piacerebbe conoscere la migliore strategia / Architettura | Progettazione del sistema che dovrebbe essere utilizzata in questo scenario. Cosa si dovrebbe fare per un codice basso accoppiato e di facile manutenzione e un approccio economicamente vantaggioso?

    
posta yunas 02.09.2018 - 21:41
fonte

1 risposta

1

In base alla tua descrizione, comprendo i seguenti requisiti:

  • X e Y continueranno a essere gestiti come 2 società con meno di 2 marchi
  • Ci sono 2 team di gestione prodotto, apparentemente con una certa autonomia sui loro approcci, e così via sui dati
  • " X avrà i propri utenti e Y avrà i propri utenti "

Capisco anche che le seguenti conclusioni dell'analisi sono già state tratte:

  • La struttura dei dati per entrambe le società è abbastanza simile per unire tutto in un unico database
  • Potrebbero tuttavia esserci alcune differenze nell'elaborazione, poiché ogni record è assegnato al sistema proprietario.
  • Un singolo team è responsabile dei sistemi

Tutti questi elementi suggeriscono l'approccio multitenancy :

  • è garantita la proprietà dei dati e l'indipendenza delle società (importante se in un secondo momento viene venduta a un altro investitore)
  • l'ingegneria e il supporto possono essere ottimizzati, perché in realtà c'è un sistema con alcune varianti
  • multineancy consente la personalizzazione specifica dell'inquilino. Ma questo deve essere progettato correttamente fin dall'inizio.

Non ho trovato argomenti per un approccio monotenente (ma potrebbe esserci e non lo hai detto).

Sfortunatamente, non è possibile basarsi sulle informazioni fornite per raccontare di più sull'architettura e formulare ulteriori raccomandazioni.

    
risposta data 03.09.2018 - 08:53
fonte