Feature-Sliced Design: ουσία, μεθοδολογία διαχωρισμού σε λειτουργίες

Τι είναι το Feature-Sliced Design;

Feature-Sliced Design (FSD) — μια μεθοδολογία αρχιτεκτονικής εφαρμογών frontend, που προτάθηκε για πρώτη φορά το 2021 από την κοινότητα feature-sliced.design. Η κύρια ιδέα του FSD — η ομαδοποίηση κώδικα ανά επιχειρηματικές λειτουργίες (φέτες), καθεμία από τις οποίες είναι μια αυτάρκης μονάδα: περιέχει τη δική της επιχειρηματική λογική, διεπαφή χρήστη, εργασία με API, μοντέλα δεδομένων και δοκιμές. Αυτό διαφοροποιεί το FSD από την κλασική πολυεπίπεδη αρχιτεκτονική, όπου ο κώδικας χωρίζεται ανά τεχνικό κριτήριο (controller, service, repository).

Η μεθοδολογία δανείζεται έννοιες από το Domain-Driven Design (DDD) και το Bounded Context: κάθε λειτουργία της εφαρμογής είναι ένα ξεχωριστό bounded context με σαφή όρια. Οι αλλαγές μέσα σε μια λειτουργία δεν θα πρέπει να χαλούν άλλες λειτουργίες, εάν χρησιμοποιούν μόνο το δημόσιο API της φέτας. Σύμφωνα με τα δεδομένα της έρευνας State of Frontend 2024, το FSD καταλαμβάνει τη δεύτερη θέση σε δημοτικότητα μεταξύ των αρχιτεκτονικών React (23%), πίσω μόνο από την ανεπίσημη δομή Feature-based (31%).

Στην κινητή ανάπτυξη, το FSD προσαρμόζεται στα χαρακτηριστικά των ενοτήτων Android και των πλαισίων iOS. Στην IT Sectr χρησιμοποιούμε το FSD για έργα με 10+ οθόνες και 3+ ομάδες — η μεθοδολογία επιτρέπει την ανεξάρτητη ανάπτυξη λειτουργιών και μειώνει τον αριθμό συγκρούσεων στο git κατά 40% σε σύγκριση με ένα monorepository χωρίς όρια φετών.

Επτά επίπεδα FSD: δομή και κανόνες εισαγωγής

Το FSD ορίζει επτά ιεραρχικά επίπεδα, καθένα από τα οποία περιέχει κώδικα συγκεκριμένου επιπέδου αφαίρεσης. Ο κύριος αρχιτεκτονικός κανόνας — τα επίπεδα μπορούν να εισάγουν μόνο κώδικα από κατώτερα επίπεδα. Η παραβίαση αυτού του κανόνα (εισαγωγή του επιπέδου features σε entities) θεωρείται αρχιτεκτονικό σφάλμα και αποκλείεται από τον linter.

Παράδειγμα δομής καταλόγου έργου FSD:

src/
├── app/                    // Επίπεδο εφαρμογής
│   ├── providers/
│   ├── router/
│   └── styles/
├── pages/                   // Σελίδες — σύνθεση λειτουργιών
│   └── main/
├── features/                // Λειτουργίες — σενάρια χρήστη
│   ├── auth/                // Φέτα ταυτοποίησης
│   │   ├── ui/
│   │   ├── model/
│   │   └── api/
│   └── productList/         // Φέτα λίστας προϊόντων
│       ├── ui/
│       └── model/
├── entities/                // Επιχειρηματικές οντότητες
│   ├── user/
│   └── product/
├── widgets/                 // Συνθετικά στοιχεία
│   └── header/
└── shared/                  // Γενικά βοηθητικά προγράμματα και UI-kit
    └── ui/

Ο κανόνας τα επίπεδα κοιτούν μόνο προς τα κάτω — ο ακρογωνιαίος λίθος του FSD. Εάν η λειτουργία auth εισάγει την οντότητα user — αυτό είναι σωστό. Εάν η οντότητα user αρχίσει να εισάγει τη λειτουργία auth — αυτή είναι κυκλική εξάρτηση και παραβίαση της απομόνωσης. Για τη διασφάλιση της τήρησης του κανόνα, χρησιμοποιούνται πρόσθετα ESLint (eslint-plugin-fsd) ή δικοί linters του δημόσιου API των φετών.

Φέτες: όρια επιχειρηματικών τομέων

Φέτα (slice) — η βασική μονάδα ομαδοποίησης στο FSD, που αντιστοιχεί σε μία επιχειρηματική λειτουργία ή οντότητα. Κάθε φέτα βρίσκεται μέσα σε ένα από τα επτά επίπεδα (features, entities, widgets, pages) και περιέχει το πλήρες σύνολο κώδικα για την υλοποίηση συγκεκριμένης λειτουργικότητας: στοιχεία UI, μοντέλο δεδομένων, πελάτη API, σταθερές και δοκιμές.

Τα όρια των φετών καθορίζονται από τον επιχειρηματικό τομέα: η λειτουργία auth περιλαμβάνει ό,τι σχετίζεται με την ταυτοποίηση (φόρμα σύνδεσης, φόρμα εγγραφής, επαναφορά κωδικού πρόσβασης); η οντότητα user περιλαμβάνει το μοντέλο User, το UserRepository και τη σειριοποίηση. Τα όρια δεν πρέπει να αλληλοκαλύπτονται: εάν η λειτουργία auth χρειάζεται δεδομένα χρήστη — εισάγει την οντότητα user, αντί να αντιγράφει τη λογική. Στην κινητή ανάπτυξη, η φέτα FSD συχνά αντιστοιχεί σε μια ενότητα Gradle στο Android ή σε ένα πακέτο Swift στο iOS.

Οι φέτες είναι αυστηρά απομονωμένες: η εσωτερική δομή μιας φέτας είναι αόρατη για άλλες φέτες. Για αλληλεπίδραση μεταξύ φετών χρησιμοποιείται το δημόσιο API — το αρχείο index.ts/index.js που εξάγει μόνο ό,τι επιτρέπεται για χρήση από έξω. Όλα τα υπόλοιπα είναι ιδιωτικές ενότητες. Αυτή η προσέγγιση αποτρέπει τυχαίες εξαρτήσεις και απλοποιεί την αναδόμηση: η αλλαγή της ιδιωτικής υλοποίησης μιας φέτας δεν επηρεάζει άλλες φέτες.

Τμήματα: UI, API, Model, Lib μέσα σε μια φέτα

Μέσα σε κάθε φέτα FSD, ο κώδικας οργανώνεται περαιτέρω ανά τμήματα — τεχνικές κατηγορίες που επαναλαμβάνονται σε όλες τις φέτες. Το τυπικό σύνολο τμημάτων περιλαμβάνει ui (στοιχεία διεπαφής), model (επιχειρηματική λογική, Store, Actions, Reducer), api (αιτήματα διακομιστή, μεταλλάξεις), lib (βοηθητικά προγράμματα και βοηθοί) και config (διαμόρφωση λειτουργίας).

Τα τμήματα είναι σύσταση, όχι αυστηρός κανόνας. Εάν η φέτα είναι μικρή, τα τμήματα μπορούν να συνδυαστούν. Για μεγάλες φέτες (λειτουργία με 10+ αρχεία), η τμηματοποίηση είναι υποχρεωτική — χωρίς αυτήν η εσωτερική δομή γίνεται γρήγορα ένα καλάθι με 50 αρχεία, όπου η εύρεση του απαιτούμενου στοιχείου διαρκεί λεπτά. Στην κινητή ανάπτυξη, τα τμήματα συχνά αντικαθίστανται από δομή αρχείων ανά τύπο: κάθε λειτουργία είναι ένα ξεχωριστό αρχείο Swift ή κλάση Kotlin με εσωτερικούς τύπους.

FSD στην κινητή ανάπτυξη: προσαρμογή για Android και iOS

Στην κινητή ανάπτυξη, το FSD προσαρμόζεται στα χαρακτηριστικά πλατφόρμας — στην αρθρωτή δομή του Android (ενότητες Gradle) και στο Swift Package Manager. Προσαρμογή Android προϋποθέτει ότι κάθε φέτα είναι μια ξεχωριστή ενότητα Gradle με το δικό της build.gradle. Οι ενότητες feature-auth, feature-profile, entity-user, shared-ui είναι απομονωμένες μεταξύ τους σε επίπεδο μεταγλώττισης: η feature-auth δεν μπορεί να εισάγει την feature-profile, εάν δεν ορίζεται στις dependencies.

Προσαρμογή iOS βασίζεται στο Swift Package Manager: κάθε φέτα είναι ένα πακέτο Swift με δημόσιο API. Σε έργα TCA, η φέτα feature.auth περιέχει το δικό της Reducer, Store, View και πελάτη API. Σύμφωνα με τα δεδομένα του Swift Community Survey 2024, το 28% των έργων iOS με TCA χρησιμοποιούν αρχιτεκτονική φετών κοντά στο FSD.

Το κύριο πρόβλημα της προσαρμογής κινητού FSD — η αντιγραφή του επιπέδου shared. Στην κινητή ανάπτυξη, τα στοιχεία UI (shared/ui) συχνά εξαρτώνται από την πλατφόρμα (Android Views vs Jetpack Compose vs SwiftUI), που απαιτεί ξεχωριστές ενότητες shared για κάθε τεχνολογία. Στο FSD, το επίπεδο shared είναι συνήθως ανεξάρτητο από την πλατφόρμα (βοηθητικά προγράμματα, διαμορφώσεις), και το UI-kit μεταφέρεται σε ξεχωριστή ενότητα ή βιβλιοθήκη στοιχείων.

Πλεονεκτήματα και μειονεκτήματα του Feature-Sliced Design

Πλεονεκτήματα του FSD γίνονται ορατά σε μεγάλα έργα με 10+ προγραμματιστές. Κάθε προγραμματιστής ή ομάδα ασχολείται με τη δική του φέτα, χωρίς να αγγίζει τον κώδικα άλλων. Οι συγκρούσεις στο git μειώνονται κατά 40–60% (δεδομένα από μελέτες περιπτώσεων feature-sliced.design). Νέες λειτουργίες προστίθενται χωρίς τον κίνδυνο να χαλάσουν τις υπάρχουσες, εάν χρησιμοποιούν μόνο το δημόσιο API των φετών. Η αναδόμηση μιας λειτουργίας δεν απαιτεί αλλαγή άλλων — αρκεί να ξαναγράψετε ui/model/api μέσα σε μία φέτα, διατηρώντας το δημόσιο API.

Μειονεκτήματα του FSD — υπερβολική ένθεση για μικρά έργα. Εάν η εφαρμογή αποτελείται από 3–5 οθόνες, επτά επίπεδα και τμηματοποίηση μέσα σε κάθε φέτα δημιουργούν περισσότερο οργανωτικό κώδικα από την ίδια την εφαρμογή. Το κατώφλι εισόδου είναι υψηλό: νέοι προγραμματιστές ξοδεύουν 2–4 εβδομάδες για να μάθουν τη μεθοδολογία. Επίσης, το FSD είναι ελάχιστα συμβατό με γρήγορη δημιουργία πρωτοτύπων — το πρωτότυπο απαιτεί συχνές διασταυρούμενες εισαγωγές επιπέδων, που απαγορεύονται στο FSD και επιβραδύνουν τις επαναλήψεις.

Συνιστάται να ξεκινήσετε με απλούστερη δομή Feature-based και να μεταβείτε στο FSD όταν ο αριθμός οθονών υπερβεί τις 20 και η ομάδα — τους 5 προγραμματιστές.