Feature-Sliced Design: ماهیت، روششناسی تقسیم به ویژگیها
توضیح میدهیم Feature-Sliced Design چیست — روششناسی معماری ماژولار فرانتاند، مبتنی بر تقسیم پروژه بر اساس ویژگیهای تجاری، نه بر اساس لایههای فنی. برخلاف معماری لایهای کلاسیک (کنترلرها، سرویسها، مخازن)، FSD کد را بر اساس قابلیتهای کاربردی برنامه گروهبندی میکند: هر ویژگی شامل منطق، رابط کاربری و دادههای خاص خود است. طبق دادههای نظرسنجی State of Frontend 2024، 23% از توسعهدهندگان React از FSD به عنوان روششناسی معماری اصلی استفاده میکنند که آن را پس از ساختار خالص Feature-based به دومین روش محبوب تبدیل میکند.
نکات اصلی
- Feature-Sliced Design (FSD) — روششناسی گروهبندی کد بر اساس ویژگیهای تجاری (اسلایسها)، که هرکدام شامل UI، منطق، API و تستها است.
- ساختار استاندارد FSD شامل 7 لایه است: app, processes, pages, features, entities, shared, widgets — هرکدام با قوانین سختگیرانه واردات.
- قانون اصلی FSD — «لایهها فقط به پایین نگاه میکنند»: لایه features میتواند entities را وارد کند، اما برعکس نه.
- مزایای FSD: ایزولهسازی ویژگیها، استفاده مجدد از اسلایسها بین پروژهها، توسعه موازی بدون تعارض.
- عیب اصلی — تو در تویی بیش از حد برای پروژههای کوچک: FSD با 10+ توسعهدهنده و 20+ صفحه توجیهپذیر است.
Feature-Sliced Design چیست؟
Feature-Sliced Design (FSD) — روششناسی معماری برنامههای فرانتاند، که اولین بار در سال 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% در مقایسه با مخزن یکپارچه بدون مرزهای اسلایس کاهش میدهد.
هفت لایه FSD: ساختار و قوانین واردات
FSD هفت لایه سلسلهمراتبی تعریف میکند، که هرکدام شامل کد با سطح انتزاع مشخصی است. قانون اصلی معماری — لایهها فقط میتوانند کد را از لایههای پایینتر وارد کنند. نقض این قانون (واردات لایه features در entities) یک خطای معماری محسوب میشود و توسط لینتر مسدود میگردد.
| لایه | کاربرد | وارد میکند |
|---|---|---|
| app | راهاندازی برنامه، ارائهدهندگان، استایلهای سراسری، مسیریابی | هر لایهای |
| processes | فرآیندهای تجاری که چندین ویژگی را ترکیب میکنند (معرفی، پرداخت) | pages, features, entities, shared |
| pages | ترکیب ویژگیها در صفحه، مسیریابی صفحات | features, entities, shared |
| features | سناریوهای کاربر: فرم ورود، لیست علاقهمندیها، فیلتر جستجو | entities, shared |
| entities | موجودیتهای تجاری: User, Product, Order, Cart | shared |
| widgets | کامپوننتهای ترکیبی UI: Header, Sidebar, ArticleCard | shared, entities |
| shared | ابزارها، UI-kit، کلاینت API، تنظیمات — مستقل از منطق تجاری | فقط کتابخانههای خارجی |
نمونه ساختار دایرکتوری پروژه 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) یا لینترهای مخصوص 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 (تنظیمات ویژگی) است.
| بخش | محتوا | مثال |
|---|---|---|
| ui/ | کامپوننتهای React/Vue/SwiftUI، استایلها، Storybook | LoginForm.tsx, login.module.css |
| model/ | Store, Reducer, Actions, انواع، قراردادها | LoginStore.ts, authReducer.ts |
| api/ | کلاینتهای HTTP، جهشها، فراخوانیهای RPC | authApi.ts, loginMutation.ts |
| lib/ | توابع کمکی، اعتبارسنجها | validateEmail.ts, formatPhone.ts |
| config/ | ثابتها، تنظیمات ویژگی | authConfig.ts, endpoints.ts |
بخشها یک توصیه هستند، نه یک قانون سختگیرانه. اگر اسلایس کوچک است، بخشها قابل ترکیب هستند. برای اسلایسهای بزرگ (ویژگی با 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% کاهش مییابد (دادههای case studies feature-sliced.design). ویژگیهای جدید بدون خطر خراب کردن ویژگیهای موجود اضافه میشوند، اگر فقط از API عمومی اسلایسها استفاده کنند. بازسازی یک ویژگی نیازی به تغییر دیگران ندارد — کافی است ui/model/api را درون یک اسلایس بازنویسی کنید، در حالی که API عمومی را حفظ میکنید.
| جنبه | FSD | Feature-based (بدون FSD) | معماری لایهای |
|---|---|---|---|
| ایزولهسازی ویژگیها | سختگیرانه | متوسط | کم |
| توسعه موازی | 10+ تیم | 3–5 تیم | 1–2 تیم |
| استفاده مجدد بین پروژهها | بله (اسلایس-بستهها) | فقط از طریق copy-paste | از طریق ماژولهای shared |
| آستانه ورود | بالا | پایین | متوسط |
| ایزولهسازی Gradle (Android) | بومی (ماژولها) | بومی (ماژولها) | ضعیف |
معایب FSD — تو در تویی بیش از حد برای پروژههای کوچک. اگر برنامه از 3–5 صفحه تشکیل شده باشد، هفت لایه و بخشبندی درون هر اسلایس کد سازمانی بیشتری نسبت به خود برنامه ایجاد میکند. آستانه ورود بالا است: توسعهدهندگان جدید 2–4 هفته را صرف یادگیری روششناسی میکنند. همچنین FSD با نمونهسازی سریع سازگاری ضعیفی دارد — نمونه اولیه نیاز به واردات متقاطع لایهای مکرر دارد که در FSD ممنوع است و تکرارها را کند میکند.
توصیه میشود با ساختار سادهتر Feature-based شروع کنید و زمانی که تعداد صفحات از 20 و تیم از 5 توسعهدهنده فراتر رفت، به FSD مهاجرت کنید.
سوالات متداول
تفاوت بین FSD و معماری Feature-based چیست؟
معماری Feature-based کد را بر اساس ویژگیها بدون قوانین سختگیرانه واردات گروهبندی میکند — ویژگی Auth میتواند ویژگی Profile دیگر را بدون محدودیت وارد کند. FSD سلسلهمراتب لایهها و قانون «لایهها فقط به پایین نگاه میکنند» را اضافه میکند. در Feature-based، entity و feature میتوانند در یک سطح باشند و یکدیگر را وارد کنند; در FSD، entity پایینتر از feature قرار دارد و feature entity را وارد میکند، نه برعکس. Feature-based برای پروژههای کوچک مناسب است، FSD — برای پروژههای بزرگ.
چگونه یک اسلایس ایزوله را تست کنیم؟
ایزولهسازی اسلایسها تست ماژولار را ساده میکند — هر اسلایس به طور مستقل با جایگزینی وابستگیهای لایههای پایینتر تست میشود. برای ویژگی auth کافی است موجودیت user را mock کنید. تستهای یکپارچهسازی API عمومی اسلایس را بررسی میکنند. در ماژول Gradle Android، ویژگی شامل دایرکتوری test خاص خود با تستهای Reducer، کلاینت API و UI (از طریق Compose Test) است. در iOS، بسته-اسلایس شامل تستهای تمام بخشها است.
آیا میتوان از FSD با Jetpack Compose استفاده کرد؟
بله، FSD به خوبی با Jetpack Compose ترکیب میشود، به ویژه در پروژههای چندماژولی Android. هر اسلایس یک ماژول Gradle جداگانه با API عمومی از طریق دستور exported است. لایه features شامل ویژگیهای Composable (LoginFeature, ProductListFeature)، لایه entities — کلاسهای داده و Repository، shared — UI-kit (MaterialTheme-wrapper، کامپوننتهای سفارشی) است. FSD برای پروژههای بزرگ Compose با 5+ توسعهدهنده توصیه میشود.
کدام لایهها اجباری و کدام اختیاری هستند؟
لایههای اجباری — app, shared, entities و features. بقیه (processes, pages, widgets) اختیاری هستند و در صورت نیاز اضافه میشوند. در توسعه موبایل، لایه pages اغلب با مسیریابی ناوبری ترکیب میشود، و widgets با shared/ui-kit جایگزین میشوند. فرآیندها (processes) معمولاً در پروژههای موبایل استفاده نمیشوند — نقش آنها توسط لایه domain یا منطق تجاری در ViewModel انجام میشود. نکته اصلی رعایت قانون سلسلهمراتب واردات است.
FSD چگونه با Domain-Driven Design مرتبط است؟
FSD از DDD مفهوم Bounded Context و Ubiquitous Language را به عاریت میگیرد. هر اسلایس متناظر با bounded context است — مرزی که درون آن اصطلاحات معنای یکسانی دارند. درون اسلایس از یک زبان واحد (ubiquitous language) استفاده میشود که هم برای توسعهدهندگان و هم برای تحلیلگران تجاری قابل فهم است. به عنوان مثال، در اسلایس auth اصطلاحات «ورود»، «رمز عبور»، «توکن» برای همه اعضای تیم یک معنا دارند که تعداد سوءتفاهمها بین تحلیلگران و توسعهدهندگان را 30–50% کاهش میدهد.
خلاصه
- Feature-Sliced Design (FSD) — روششناسی معماری ماژولار با گروهبندی کد بر اساس ویژگیهای تجاری (اسلایسها)، که هرکدام شامل UI، منطق، API و تستها است.
- هفت لایه FSD: app, processes, pages, features, entities, widgets, shared — با قانون سختگیرانه واردات از بالا به پایین.
- اسلایسها از طریق API عمومی ایزوله شدهاند — ساختار داخلی برای سایر اسلایسها نامرئی است که از وابستگیهای چرخهای جلوگیری میکند.
- بخشهای درون اسلایس (ui, model, api, lib, config) کد را بر اساس معیار فنی سازماندهی میکنند، اما برای اسلایسهای کوچک اجباری نیستند.
- در توسعه موبایل، FSD از طریق ماژولهای Gradle (Android) و بستههای Swift (iOS) تطبیق داده میشود و ایزولهسازی را در سطح کامپایل فراهم میکند.
- مزایای اصلی — توسعه موازی، ایزولهسازی ویژگیها، استفاده مجدد بین پروژهها.
- معایب اصلی — افزونگی برای پروژههای کوچک، آستانه ورود بالا، ناسازگاری با نمونهسازی سریع.
ما یک اپلیکیشن موبایل به صورت کلید در دست توسعه خواهیم داد
IT Sectr از سال 2017 برنامههای iOS و Android را برای استارتاپها و کسبوکارها ایجاد میکند. ما به شما مشاوره میدهیم و بهترین راهحل را پیشنهاد خواهیم کرد.
همچنین بخوانید