Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Identificazione dei confini dei microfrontend
Per migliorare l'autonomia del team, le funzionalità aziendali fornite da un'applicazione possono essere scomposte in diversi microfrontend con dipendenze minime l'uno dall'altro.
Seguendo la metodologia DDD discussa in precedenza, i team possono suddividere un dominio applicativo in sottodomini aziendali e contesti limitati. I team autonomi possono quindi possedere la funzionalità dei propri contesti limitati e fornire tali contesti come micro-frontend. Per ulteriori informazioni sulla separazione delle preoccupazioni, consulta il diagramma Serverless Land.
Un contesto limitato ben definito dovrebbe ridurre al minimo la sovrapposizione funzionale e la necessità di comunicazioni in fase di esecuzione tra i contesti. La comunicazione richiesta può essere implementata con metodi basati sugli eventi. Ciò non è diverso dall'architettura basata sugli eventi per lo sviluppo di microservizi.
Un'applicazione ben progettata dovrebbe inoltre supportare la fornitura di future estensioni da parte di nuovi team per offrire un'esperienza coerente ai clienti.
Come suddividere un'applicazione monolitica in microfrontend
La sezione Panoramica includeva un esempio di identificazione di contesti funzionali indipendenti su una pagina Web. Emergono diversi modelli per suddividere la funzionalità sull'interfaccia utente.
Ad esempio, quando i domini aziendali costituiscono fasi del percorso dell'utente, è possibile applicare una suddivisione verticale sul frontend, in cui una raccolta di visualizzazioni del percorso dell'utente viene fornita sotto forma di microfrontend. Il diagramma seguente mostra una suddivisione verticale, in cui le fasi Catalog, Checkout e Invoice vengono fornite da team separati come microfrontend separati.
Per alcune applicazioni, la divisione verticale da sola potrebbe non essere sufficiente. Ad esempio, potrebbe essere necessario fornire alcune funzionalità in molte visualizzazioni. Per queste applicazioni, è possibile applicare una suddivisione mista. Il diagramma seguente mostra una soluzione mista suddivisa in cui i microfrontend per Station finder e Route explorer utilizzano entrambi la funzionalità di visualizzazione della mappa.
Le applicazioni di tipo portale o di dashboard in genere riuniscono le funzionalità di frontend in un'unica visualizzazione. In questi tipi di applicazioni, ogni widget può essere fornito come micro-frontend e l'applicazione di hosting definisce i vincoli e le interfacce che i micro-frontend devono implementare.
Questo approccio fornisce ai microfrontend un meccanismo per gestire problemi come il dimensionamento delle viewport, i provider di autenticazione, le impostazioni di configurazione e i metadati. Questi tipi di applicazioni ottimizzano l'estensibilità. Nuove funzionalità possono essere sviluppate da nuovi team per scalare le funzionalità del dashboard.
Il diagramma seguente mostra un'applicazione dashboard sviluppata da tre singoli team che fanno parte di Team Dashboard.
Nel diagramma, la vista futura rappresenta le nuove funzionalità sviluppate dai nuovi team per scalare Team Dashboard e le funzionalità della dashboard.
Le applicazioni di portale e dashboard di solito creano funzionalità utilizzando una suddivisione mista nell'interfaccia utente. I micro-frontend sono configurabili con impostazioni ben definite, inclusi vincoli di posizione e dimensione.
