Problema di progettazione: abbattere un'applicazione web monolite

0

Descrizione del problema: abbiamo una grande app monolite contenente componenti dell'interfaccia utente A , B , C , D . Puoi pensare ad un componente come una pagina per ora. Componente A & B condividi un sottocomponente chiamato SHARED . Ora entrambi A & B sta pianificando di uscire dalla grande app del monolite. La sfida qui è avere lo stesso aspetto e aspetto del sottocomponente SHARED in entrambi A & B in qualsiasi momento.

La mia soluzione: pubblica il sottocomponente come modulo. Entrambi A & B importalo e usalo. Il problema qui è quando viene pubblicata una nuova versione del sotto-componente, sia A & B avrebbe bisogno di una versione. Rilasciando entrambi A & B allo stesso tempo non sarà semplice. Ciò richiede il coordinamento tra le squadre che mantengono A & B rispettivamente. Potrebbe esserci una possibilità quando A è stato rilasciato, ma B ha dovuto ritirarsi a causa di qualche altro cambiamento. Questo scenario viola la nostra esigenza di aspetto coerente per il sottocomponente su A & B in ogni momento. Ci sarebbero anche altri scenari simili. Come dovremmo gestirlo?

C'è un modo migliore per gestire questa situazione?

    
posta user2899951 26.07.2017 - 06:35
fonte

1 risposta

-1

ciao non sarà meglio se al posto di integrare il sottocomponente sia A & B si riferisce come componente seprate C? Intendo l'integrità strutturale e A e B invece di elaborare i dati da C l'elaborazione viene eseguita in C stesso, questo renderà le modifiche C indipendenti sia da A che da A & B e finché abbiamo dipendenza non possiamo assicurarci che sia A & B sarà allo stesso livello /

    
risposta data 26.07.2017 - 08:10
fonte

Leggi altre domande sui tag