Concetti fondamentali

L'architettura Micro-frontend è fortemente ispirata a tre concetti architettonici precedenti:

• La progettazione basata sul dominio è il modello mentale per strutturare applicazioni complesse in domini coerenti.

• I sistemi distribuiti sono un approccio per la creazione di applicazioni sotto forma di sottosistemi liberamente accoppiati, sviluppati indipendentemente e eseguiti su una propria infrastruttura dedicata.

• Il cloud computing è un approccio per gestire l'infrastruttura IT come servizi con un modello. pay-as-you-go

Progettazione basata sul dominio

La progettazione basata sul dominio (DDD) è un paradigma sviluppato da Eric Evans. Nel suo libro del 2003 Domain-Driven Design: Tackling Complexity in the Heart of Software, Evans postula che lo sviluppo del software dovrebbe essere guidato da preoccupazioni aziendali piuttosto che tecniche. Evans propone che i progetti IT sviluppino innanzitutto un linguaggio onnipresente che aiuti gli esperti tecnici e di settore a trovare una comprensione condivisa. Sulla base di quel linguaggio, possono formulare un modello della realtà aziendale compreso da entrambe le parti.

Per quanto ovvio possa essere questo approccio, molti progetti software presentano una disconnessione tra business e IT. Queste disconnessioni spesso causano gravi malintesi, che portano a sforamenti di budget, riduzione della qualità o fallimento del progetto.

Evans introduce molti altri termini importanti, uno dei quali è il contesto limitato. Un contesto limitato è un segmento autonomo di un'applicazione IT di grandi dimensioni che contiene la soluzione o l'implementazione per una sola azienda. Un'applicazione di grandi dimensioni sarà costituita da più contesti limitati che sono liberamente accoppiati tramite modelli di integrazione. Questi contesti limitati possono persino avere i propri dialetti della lingua onnipresente. Ad esempio, un utente nel contesto di pagamento di un'applicazione potrebbe avere aspetti diversi da un utente nel contesto della consegna perché il concetto di spedizione sarebbe irrilevante durante il pagamento.

Evans non definisce quanto piccolo o grande debba essere un contesto limitato. La dimensione è determinata dal progetto software e potrebbe evolversi nel tempo. I buoni indicatori dei confini di un contesto sono il grado di coesione tra le entità (oggetti di dominio) e la logica aziendale.

Nel contesto dei microfrontend, la progettazione basata sul dominio può essere illustrata con l'esempio di una pagina web complessa come una pagina di prenotazione di voli.

In questa pagina, gli elementi costitutivi principali sono un modulo di ricerca, un pannello di filtri e l'elenco dei risultati. Per identificare i confini, è necessario identificare contesti funzionali indipendenti. Inoltre, prendete in considerazione aspetti non funzionali, come la riutilizzabilità, le prestazioni e la sicurezza. L'indicatore più importante del fatto che «cose che stanno insieme» sono i loro modelli di comunicazione. Se alcuni elementi di un'architettura devono comunicare frequentemente e scambiarsi informazioni complesse, è probabile che condividano lo stesso contesto limitato.

I singoli elementi dell'interfaccia utente, come i pulsanti, non sono contesti limitati, perché non sono indipendenti dal punto di vista funzionale. Inoltre, l'intera pagina non è adatta a un contesto limitato, perché può essere suddivisa in contesti indipendenti più piccoli. Un approccio ragionevole consiste nel trattare il modulo di ricerca come un contesto limitato e l'elenco dei risultati come il secondo contesto limitato. Ciascuno di questi due contesti limitati può ora essere implementato come un micro-frontend separato.

Sistemi distribuiti

Per facilitare la manutenzione e supportare la capacità di evoluzione, la maggior parte delle soluzioni IT non banali è modulare. In questo caso, modulare significa che i sistemi IT sono costituiti da elementi costitutivi identificabili che vengono disaccoppiati tramite interfacce per ottenere la separazione delle preoccupazioni.

Oltre ad essere modulari, i sistemi distribuiti dovrebbero essere sistemi indipendenti a pieno titolo. In un sistema puramente modulare, ogni modulo è idealmente incapsulato ed espone le sue funzioni tramite interfacce, ma non può essere distribuito in modo indipendente o addirittura funzionare da solo. Inoltre, i moduli generalmente seguono lo stesso ciclo di vita degli altri moduli che fanno parte dello stesso sistema. Gli elementi costitutivi di un sistema distribuito, d'altra parte, hanno ciascuno il proprio ciclo di vita. Applicando il paradigma di progettazione basato sul dominio, ogni elemento costitutivo si rivolge a un dominio o sottodominio aziendale e vive in un contesto limitato.

Quando i sistemi distribuiti interagiscono durante la fase di costruzione, un approccio comune consiste nello sviluppare meccanismi per identificare rapidamente i problemi. Ad esempio, potreste adottare linguaggi tipizzati e investire molto nei test unitari. Più team possono collaborare allo sviluppo e alla manutenzione di moduli, spesso distribuiti come librerie che i sistemi possono utilizzare con strumenti come npm, Apache Maven e pip. NuGet

In fase di esecuzione, i sistemi distribuiti interagenti sono in genere di proprietà di singoli team. L'uso eccessivo delle dipendenze causa complessità operativa a causa della gestione degli errori, del bilanciamento delle prestazioni e della sicurezza. Gli investimenti nei test di integrazione e nell'osservabilità sono fondamentali per ridurre i rischi.

Gli esempi più diffusi di sistemi distribuiti oggi sono i microservizi. Nelle architetture a microservizi, i servizi di backend sono guidati dal dominio (anziché da problemi tecnici come l'interfaccia utente o l'autenticazione) e sono di proprietà di team autonomi. I microfrontend condividono gli stessi principi, estendendo l'ambito della soluzione al frontend.

Cloud computing

Il cloud computing è un modo per acquistare l'infrastruttura IT sotto forma di servizi con un pay-as-you-go modello anziché costruire i propri data center e acquistare hardware per gestirli localmente. Il cloud computing offre diversi vantaggi:

• La tua organizzazione acquisisce una notevole agilità aziendale grazie alla possibilità di sperimentare nuove tecnologie senza dover assumere anticipatamente impegni finanziari ingenti e a lungo termine.

• Utilizzando un provider di servizi cloud come AWS, l'organizzazione può accedere a un ampio portafoglio di servizi a bassa manutenzione e altamente integrabili (come gateway API, database, orchestrazione dei container e funzionalità cloud). L'accesso a questi servizi consente al personale di concentrarsi su attività che differenziano l'organizzazione dalla concorrenza.

• Quando la tua organizzazione è pronta per implementare una soluzione a livello globale, puoi implementarla sull'infrastruttura cloud in tutto il mondo.

Il cloud computing supporta i microfrontend fornendo un'infrastruttura altamente gestita. Ciò semplifica la end-to-end proprietà per i team interfunzionali. Sebbene il team debba avere una solida conoscenza delle operazioni, le attività manuali di fornitura dell'infrastruttura, aggiornamenti del sistema operativo e networking costituirebbero una distrazione.

Poiché i micro-frontend vivono in contesti limitati, i team possono scegliere il servizio più adatto per eseguirli. Ad esempio, i team possono scegliere tra funzioni cloud e contenitori per l'elaborazione e possono scegliere tra diverse versioni di database SQL e NoSQL o cache in memoria. I team possono persino creare i propri micro-frontend su un toolkit altamente integrato, ad esempio dotato di elementi costitutivi preconfigurati per l'infrastruttura AWS Amplifyserverless.