Architektur für Enterprise-Frontend-Anwendungen

• Ein wachsender Codebestand bedeutet: Er wird schwerer zu verstehen und zu ändern.

• Die Lösung? Den Codebestand klein halten.

• Aufteilung des Codebestands nach Domänen & Micro Frontends zur Rettung!

• Anforderungen wie das Festlegen von Abhängigkeitsbeziehungen zwischen Bibliotheken innerhalb eines Monorepos & das Prüfen von Abhängigkeiten wurden durch die Einführung von Nx gelöst.

• Aufteilung des Codes in Anwendungen und Bibliotheken

• Anwendungen übernehmen die Rolle der Injektion von Abhängigkeiten und Konfigurationen

• Der Großteil der Funktionalität wird in Bibliotheken implementiert

  • In Bibliotheken werden nicht nur allgemein nutzbare Elemente wie Design-System, Internationalisierung und Third-Party-Module geschrieben, sondern auch nicht wiederverwendeter Code wie das Hero-Banner der Startseite, die Produktdetailseite oder die Bestellhistorie.

Feature-Bibliotheken

• Grundsätzlich werden alle Komponenten, die auf einer Seite verwendet werden, in einer Feature-Bibliothek mit demselben Namen geschrieben.

  • z. B. werden für die Seite SignInPage der Domäne account alle Komponenten in der Bibliothek account/feature-sign-in geschrieben.

• Komponenten, die auf zwei oder mehr Seiten derselben Domäne gemeinsam genutzt werden, werden als separates Feature innerhalb dieser Domäne ausgelagert.

  • z. B. wenn die Komponente KakaoLoginButton sowohl auf SignInPage als auch auf SignUpPage der Domäne account gemeinsam verwendet wird, wird diese Komponente in der Bibliothek account/feature-social-login geschrieben.

• Komponenten, die auf Seiten unterschiedlicher Domänen gemeinsam genutzt werden, werden als separates Feature innerhalb einer gemeinsamen Domäne ausgelagert.

  • z. B. wird die gemeinsam genutzte Komponente GlobalNavigation, die auf HomePage der Domäne landing und auf LecturePage der Domäne classroom verwendet wird, in der Bibliothek shared/feature-navigation geschrieben.

Shell-Bibliotheken

• Seiten werden erstellt, indem Komponenten aus Feature- und UI-Bibliotheken kombiniert werden.

  • z. B. ist die Komponente SignInPage eine Komponente der Bibliothek account/shell-kr-web. Dort befinden sich auch SignUpPage, PhoneVerificationPage usw.

• Shell-Bibliotheken sind der Einstiegspunkt einer bestimmten Domäne, der einer Anwendung bereitgestellt wird.

• Es können je nach Anwendung unterschiedliche Einstiegspunkte bereitgestellt werden.

  • Zum Beispiel …

  • Die im HomePage-Komponent verwendeten Komponenten sind in der Bibliothek landing/feature-home geschrieben.

  • Aber selbst bei derselben HomePage ist die Zusammensetzung unterschiedlich, je nachdem, ob es sich um die HomePage der US-Website, der japanischen Website oder der koreanischen Website handelt.

  • Daher können für jede Anwendung, die auf die Domäne landing zugreift, eigene shell-Bibliotheken erstellt werden. (shell-us-web, shell-jp-web, shell-kr-web)

Provider-Bibliotheken

• Bibliotheken, die den Zustand verwalten, der von zwei oder mehr Feature-Bibliotheken gemeinsam genutzt wird

  • z. B. shared/provider-auth-state zur Verwaltung des Login-Status

UI-Bibliotheken

• Eine Sammlung von Presentational-Komponenten, die von zwei oder mehr Bibliotheken gemeinsam genutzt werden.

Utility-Bibliotheken

• Alle Module, die nicht zu den vier oben genannten Kategorien gehören

• Sie sollten Funktionen bereitstellen, die unabhängig genug sind, um ohne Bezug zum Domänenmodell von Class101 getestet und bereitgestellt werden zu können.

  • z. B. shared/utils-apollo-client, shared/utils-i18n

Anwendungen

• Sie übernehmen nur die Rolle der Konfigurations- und Abhängigkeitsverwaltung = der Anwendungscode ist fast nicht vorhanden