Einführung Frontend-Entwickler stehen häufig vor einem Problem im Zusammenhang mit der Anwendungsarchitektur. Es erfordert die Verwendung einer Architektur, die sich leicht skalieren lässt und eine lockere Kopplung sowie eine hohe Kohäsion zwischen den Anwendungsmodulen bietet. In diesem Artikel geht es um die Feature-Sliced-Design-Architektur, da sie meiner Meinung nach die beste unter den verfügbaren Optionen ist. Außerdem werden die Idee von FSD und die Probleme untersucht, die diese Architekturmethodik löst. Wir werden FSD mit klassischen und modularen Architekturen vergleichen und ihre Vor- und Nachteile untersuchen. Lassen Sie uns zunächst drei Konzepte unterscheiden: Ebene, Scheibe und Segment. Lagen Ebenen sind Verzeichnisse der obersten Ebene und die erste Ebene der Anwendungszerlegung. Ihre Anzahl ist begrenzt – maximal 7 Schichten – und standardisiert, einige davon sind jedoch optional. Derzeit werden folgende Schichten unterschieden: Jede Ebene hat ihren eigenen Verantwortungsbereich und ist geschäftsorientiert. Betrachten wir jede Ebene einzeln. app: Hier wird die Anwendungslogik initialisiert. Hier werden Anbieter, Router, globale Stile, globale Typdeklarationen usw. definiert. Es dient als Einstiegspunkt für die Anwendung. Prozesse: Diese Ebene verarbeitet Prozesse, die sich über mehrere Seiten erstrecken, wie z. B. die mehrstufige Registrierung. Diese Ebene gilt als veraltet, kann aber immer noch gelegentlich angetroffen werden. Es handelt sich um eine optionale Ebene. Seiten: Diese Ebene umfasst die Seiten der Anwendung. Widgets: Dies sind eigenständige UI-Komponenten, die auf Seiten verwendet werden. Funktionen: Diese Ebene befasst sich mit Benutzerszenarien und Funktionen, die einen geschäftlichen Wert haben. Zum Beispiel Likes, das Schreiben von Rezensionen, das Bewerten von Produkten usw. Es handelt sich um eine optionale Ebene. Entitäten: Diese Ebene repräsentiert Geschäftsentitäten. Zu diesen Entitäten können Benutzer, Rezensionen, Kommentare usw. gehören. Es handelt sich um eine optionale Ebene. Shared: Diese Ebene enthält wiederverwendbare Komponenten und Dienstprogramme, die nicht an eine bestimmte Geschäftslogik gebunden sind. Es umfasst ein UI-Kit, Axios-Konfiguration, Anwendungskonfiguration, Helfer, die nicht an die Geschäftslogik gebunden sind usw. Diese Schichten helfen bei der Organisation der Codebasis und fördern eine modulare, wartbare und skalierbare Architektur. Eines der Hauptmerkmale von Feature-Sliced Design ist seine hierarchische Struktur. In dieser Struktur können Entitäten die Funktionalität von Features nicht nutzen, da Features in der Hierarchie höher stehen. Ebenso können Features keine Komponenten von Widgets oder Prozessen verwenden, da die darüber liegenden Ebenen nur die darunter liegenden Ebenen nutzen können. Dies geschieht, um einen linearen Fluss aufrechtzuerhalten, der nur in eine Richtung gerichtet ist. Je niedriger eine Ebene in der Hierarchie positioniert ist, desto riskanter ist es, Änderungen daran vorzunehmen, da sie wahrscheinlich an mehr Stellen im Code verwendet wird. Beispielsweise wird das UI-Kit in der gemeinsam genutzten Ebene in den Features, Widgets und sogar Seitenebenen verwendet. Scheiben In jeder der Ebenen gibt es Unterverzeichnisse – Slices – die zweite Ebene der Anwendungszerlegung. In Slices besteht die Verbindung nicht zu abstrakten Dingen, sondern zu bestimmten Geschäftseinheiten. Das Hauptziel von Slices besteht darin, Code nach seinem Wert zu gruppieren. Slice-Namen sind nicht standardisiert, da sie direkt vom Geschäftsbereich des Projekts bestimmt werden. Beispielsweise kann es in einer Fotogalerie Abschnitte wie „Foto“, „Album“ und „Galerie“ geben. Ein soziales Netzwerk würde Slices wie Beiträge, Benutzer und Newsfeeds erfordern. Eng verwandte Fragmente können strukturell in einem Verzeichnis gruppiert werden, sie müssen jedoch denselben Isolationsregeln unterliegen wie andere Slices – es sollte keinen gemeinsamen Zugriff auf den Code in diesem Verzeichnis geben. Segmente Jedes Slice besteht aus Segmenten. Segmente helfen dabei, den Code innerhalb eines Slice entsprechend seinem Zweck zu unterteilen. Abhängig von den Vereinbarungen des Teams können sich die Zusammensetzung und Benennung der Segmente ändern. Die folgenden Segmente werden häufiger verwendet: API – notwendige Serveranfragen. UI – UI-Komponenten des Slice. Modell - Geschäftslogik, dh Interaktion mit dem Staat. Zum Beispiel Aktionen und Selektoren. lib – Hilfsfunktionalität, die innerhalb des Slice verwendet wird. config – notwendige Konfiguration des Slice, aber das config-Segment kommt selten vor. consts – notwendige Konstanten. Öffentliche API Jedes Slice und Segment verfügt über eine öffentliche API. Die öffentliche API wird durch eine index.js- oder index.ts-Datei repräsentiert, die es ermöglicht, nur die notwendige Funktionalität aus dem Slice oder Segment nach außen zu extrahieren und unnötige Funktionalität zu isolieren. Die Indexdatei dient als Einstiegspunkt. Regeln für die öffentliche API: Anwendungs-Slices und -Segmente verwenden nur die Funktionalität und Komponenten des Slice, die in der öffentlichen API-Indexdatei definiert sind. Der interne Teil des Slice oder Segments, der nicht in der öffentlichen API definiert ist, gilt als isoliert und ist nur für den Zugriff innerhalb des Slice oder Segments selbst offen. Die öffentliche API vereinfacht die Arbeit mit Import und Export, sodass bei Änderungen an der Anwendung nicht überall im Code Importe geändert werden müssen. Tiefer in die Architektur Abstraktion und Geschäftslogik Je höher die Ebene, desto stärker ist sie an den spezifischen Geschäftsknoten gebunden und desto mehr Geschäftslogik enthält sie. Je niedriger die Ebene, desto mehr Abstraktionen, Wiederverwendbarkeit und mangelnde Autonomie in der Ebene. Wie löst FSD das Problem? Eine der Aufgaben des Feature-Sliced-Designs besteht darin, eine lose Kopplung und eine hohe Kohäsion zu erreichen. Es ist wichtig zu verstehen, wie FSD dieses Ergebnis erzielt. In OOP werden diese Probleme seit langem durch Konzepte wie , , und gelöst. Diese Konzepte gewährleisten Isolation, Wiederverwendbarkeit und Vielseitigkeit des Codes, wobei je nach Verwendung einer Komponente oder Funktionalität unterschiedliche Ergebnisse erzielt werden. Polymorphismus Kapselung Vererbung Abstraktion Feature-Sliced Design hilft, diese Prinzipien im Frontend anzuwenden. und werden durch Schichten erreicht. Da die unteren Schichten abstrakt sind, können sie in höheren Schichten wiederverwendet werden und je nach Bedingungen kann eine Komponente oder Funktionalität basierend auf den angegebenen Parametern oder Requisiten unterschiedlich funktionieren. Abstraktion Polymorphismus erfolgt über die öffentliche API, die das, was nicht benötigt wird, von außen in Slices und Segmente isoliert. Der Zugriff auf die inneren Segmente eines Slice ist eingeschränkt und die öffentliche API ist die einzige Möglichkeit, auf Funktionen und Komponenten eines Slice oder Segments zuzugreifen. Die Kapselung erfolgt auch über Schichten, da höhere Schichten niedrigere Schichten wiederverwenden können. Die Vererbung Vergleich mit der klassischen Architektur Ich glaube, Sie sind schon oft auf klassische Architektur gestoßen. Aufgrund seiner Einfachheit verwenden die meisten Autoren es in Lehrartikeln und YouTube-Videos. Es gibt keinen spezifischen Standard für klassische Architektur. Häufig sieht man jedoch das folgende Format: Die klassische Architektur weist spürbare Nachteile auf. Das größte Problem besteht darin, dass das Projekt aufgrund impliziter Verbindungen zwischen Komponenten und Modulunordnung schwierig zu warten ist. Die Nachteile der klassischen Architektur werden mit der Zeit immer deutlicher. Je länger sich das Projekt weiterentwickelt, desto mehr wird die Anwendungsarchitektur zu einem Wirrwarr, der nur schwer zu entwirren ist. Die klassische Architektur eignet sich für kleine Projekte ohne laufende Wartung oder Lieblingsprojekte. Feature-Sliced Design verhindert dank seiner Konzepte und Standards die Probleme der klassischen Architektur. Das Verständnis und die Fähigkeiten von Entwicklern, die mit FSD arbeiten, sollten jedoch höher sein als bei der Arbeit mit klassischer Architektur. Normalerweise haben Entwickler mit weniger als 2 Jahren Erfahrung noch nie von FSD gehört. Bei der Arbeit mit Feature-Sliced Design müssen Probleme jedoch „jetzt“ und nicht „später“ angegangen werden. Probleme im Code und Abweichungen von den Konzepten werden sofort sichtbar Vergleich mit einfacher modularer Architektur Eine einfache modulare Architektur hat mehrere Nachteile: Manchmal ist unklar, wo Funktionalität in Module oder Komponenten eingefügt werden soll. Schwierigkeiten bei der Verwendung von Modulen innerhalb eines anderen Moduls. Probleme beim Speichern von Geschäftseinheiten. Implizite Abhängigkeiten in globalen Funktionen führen zu einer verworrenen Struktur. Es scheint, dass bei allen komplexen oder mäßig komplexen Projekten Feature-Sliced Design der einfachen modularen Architektur vorgezogen werden sollte. FSD löst viele grundlegende Architekturprobleme und weist nur wenige Nachteile auf. Im Hinblick auf Einfachheit und Entwicklungsgeschwindigkeit kann eine einfache modulare Architektur gegenüber FSD einen Vorteil haben. Wenn ein MVP benötigt wird oder ein kurzlebiges Projekt entwickelt wird, ist eine einfache modulare Architektur möglicherweise besser geeignet als FSD. Aber in jedem anderen Fall scheint ein funktionsorientiertes Design vorzuziehen. Das Potenzial von Feature-Sliced Design FSD ist eine junge Architekturmethodik. Es wird jedoch bereits von vielen Banken, Fintech-, B2B-, E-Commerce-Unternehmen und anderen genutzt. Hier ist ein Link zum GitHub-Problem mit einer Liste der Unternehmen: . GitHub-Problem Das GitHub-Repository mit der offiziellen FSD-Dokumentation hatte zum Zeitpunkt der Veröffentlichung dieses Artikels mehr als 1,1.000 Sterne. Die Dokumentation wird aktiv erweitert und das FSD-Entwicklungsteam sowie die Community in Telegram und Discord stehen rund um die Uhr zur Verfügung, um Menschen bei architekturbezogenen Fragen zu helfen. Das Potenzial dieser Architektur wird hoch geschätzt und ihr Einsatz ist bei großen Unternehmen auf der ganzen Welt weit verbreitet. Bei richtiger Einführung hat FSD das Potenzial, die dominierende Architekturlösung im Bereich der Frontend-Entwicklung zu werden. Vor- und Nachteile der Architektur Vorteile Architekturkomponenten können einfach ausgetauscht, hinzugefügt oder entfernt werden Standardisierung der Architektur Skalierbarkeit Die Methodik ist unabhängig vom Entwicklungsstack. Kontrollierte und explizite Verbindungen zwischen Modulen ohne unerwartete Nebenwirkungen. Geschäftsorientierte Architekturmethodik. Nachteile Eine höhere Eintrittsbarriere im Vergleich zu vielen anderen Architekturlösungen. Erfordert Bewusstsein, Teamkultur und die Einhaltung von Konzepten. Herausforderungen und Probleme müssen sofort und nicht erst später angegangen werden. Codeprobleme und Abweichungen von Konzepten sind sofort sichtbar. Dies kann jedoch auch als Vorteil angesehen werden. Abschluss Feature-Sliced Design ist eine interessante und wertvolle Entdeckung, die Frontend-Entwickler kennen und nutzen können sollten. FSD kann Teams eine flexible, standardisierte und skalierbare Architektur und Entwicklungskultur bieten. Die Nutzung der positiven Aspekte der Methodik erfordert jedoch Wissen, Bewusstsein und Disziplin im Team. FSD hebt sich von anderen Architekturen durch seine klare Geschäftsausrichtung, Entitätsdefinition, Funktionszusammensetzung und Komponentenzusammensetzung der Anwendung ab. Sie können auch unabhängig voneinander Beispiele für die FSD-Nutzung in Projekten und die offizielle Feature-Sliced-Design-Dokumentation erkunden: Offizielle Dokumentation Beispiel. GitHub-Client Beispiel. Nike Sneaker- und Schuhgeschäft Beispiel. Sudoku Dieser Beitrag mag lang sein, aber ich hoffe, Sie haben etwas Neues gelernt. Ich freue mich, dass Sie diesen Beitrag zu Ende gelesen haben. Wenn Sie irgendwelche Gedanken oder Fragen haben, hinterlassen Sie gerne einen Kommentar! Auch veröffentlicht hier
