Thinking in Frontend Architecture

ممکنه هر پروژهای که دیده باشین، ساختار فولدرها، نحوه مدیریت State و جریان دادههاش کاملاً متفاوت باشه. این طبیعی است، چون روشها و معماریها متفاوته و هر تیم یه سبک خودش رو داره. اما چیزی که همه پروژههای موفق مشترک دارن اینه که یک اسکلت و اصول معماری مشخص دارن. بدون این اسکلت، حتی بهترین کدها هم با کوچکترین تغییر یا فشار، دچار آشفتگی میشوند و نگهداریشون سخت میشه.

جلوتر میخوام به صورت حرفهای معماریها رو توضیح بدم و بگم هر کدوم کجا به درد میخوره تا وقتی پروژه بعدیتون رو شروع میکنین، راحتتر تصمیم بگیرین کدوم روش بهترینه.

بدون معماری، پروژهها مثل ساختمان بدون اسکلت میشوند: ظاهراً خوب، اما با اولین فشار فرو میریزند.

Layered Architecture

Layered Architecture یکی از قدیمیترین و کلاسیکترین معماریهاست و ایده اصلی آن تقسیم پروژه به لایههای مسئولیت مشخص است. هر لایه فقط با لایه پایینتر خود ارتباط دارد و مسئولیتش مشخص است.

مزایا:
این معماری بسیار ساده و قابل فهم است، به ویژه برای تیمهای کوچک یا پروژههای تازه. جداسازی واضح Presentation Layer، Business Logic Layer و Data/API Layer باعث میشود که توسعه و تست هر لایه مستقل انجام شود. برای مثال میتوان Business Logic را بدون رندر UI تست کرد و API Layer را بدون توجه به سایر لایهها تغییر داد. این ساختار پایهای محکم برای شروع پروژهها فراهم میکند و دید روشن درباره جریان دادهها و مسئولیتها ارائه میدهد.

محدودیتها:
با رشد پروژه، لایهها میتوانند بزرگ و پیچیده شوند و مدیریت وابستگیها بین آنها چالشبرانگیز شود. اگر قوانین مرزبندی رعایت نشود، تغییرات در یک لایه ممکن است اثرات غیرمنتظرهای روی لایههای دیگر داشته باشد. بنابراین، معماری لایهای به تنهایی برای پروژههای بزرگ یا چند تیمی کافی نیست و معمولاً با Feature-based یا Domain-oriented ترکیب میشود.

این مثال رو ببنید:

// Data/API Layer
export async function fetchProducts() {
  const res = await fetch('/api/products');
  return await res.json();
}

// Business Logic Layer
import { useState, useEffect } from 'react';
export function useProductList() {
  const [products, setProducts] = useState([]);
  useEffect(() => { fetchProducts().then(setProducts); }, []);
  return products;
}

// Presentation Layer
function ProductList() {
  const products = useProductList();
  return <ul>{products.map(p => <li key={p.id}>{p.name}</li>)}</ul>;
}

Component-based Architecture

Component-based Architecture پایه فریمورکهای مدرن مثل React، Vue و Svelte است.ایده اصلی این است که برنامه را به کامپوننتهای کوچک، مستقل و قابل استفاده مجدد تقسیم کنیم.

مزایا:
این معماری باعث میشود که بخشهای مختلف UI ماژولار و دوبارهاستفاده پذیر باشند. یک Button یا Modal میتواند در چندین صفحه بدون تغییر مجدد استفاده شود، که هم سرعت توسعه را بالا میبرد و هم خطاها را کاهش میدهد. علاوه بر این، تیمها میتوانند روی کامپوننتهای مختلف به صورت موازی کار کنند و وابستگی بین توسعهدهندگان کمتر شود.

محدودیتها:
با وجود مزایا، صرفاً استفاده از کامپوننتها کافی نیست. بدون مدیریت دقیق State و وابستگیها، پروژه به سرعت پیچیده و شکننده میشود. تغییر یک کامپوننت کوچک میتواند باعث بروز باگ در بخشهای دیگر شود، به ویژه اگر کامپوننتها بدون مرزهای مشخص به State یا API مشترک دسترسی داشته باشند.

مثال:
یک کامپوننت Button که UI + logic خودش را دارد، اما نباید مستقیم با API یا state global تعامل کند.

Atomic Design / UI-driven Architecture

Atomic Design بر پایه سلسلهمراتب UI است:

Atoms → Molecules → Organisms → Templates → Pages.
هدف اصلی این معماری استانداردسازی UI و افزایش قابلیت reuse است.

مزایا:
توسعه سریع UI، دوبارهاستفاده آسان از عناصر کوچک و داشتن استاندارد مشخص در طراحی، مزایای اصلی این رویکرد هستند. تیمها میتوانند سریعاً بخشهای مختلف UI را ایجاد و با سایر بخشها ترکیب کنند.

محدودیتها:
این معماری فقط بر UI تمرکز دارد و به مسائل بیزنسی یا State Management نمیپردازد. پروژه ممکن است از نظر ظاهری مرتب باشد اما اگر Featureها یا Domains به درستی مدیریت نشوند، maintainability پایین خواهد بود.

Feature-based Structure چیست؟

Feature-based Structure یعنی پروژه را بر اساس ویژگیها (Features) یا قابلیتهای کوچک قابل تحویل تقسیم کنیم، نه بر اساس نوع فایل یا صفحه.

• هر Feature شامل همه چیزهایی است که آن قابلیت نیاز دارد: UI، منطق، state و ارتباط با API.

• هدف این است که اضافه کردن یا تغییر یک ویژگی، کمترین تأثیر را روی سایر بخشها داشته باشد.

مثال عملی:

فرض کن اپلیکیشن فروشگاهی داریم، Feature-based Structure میتواند اینطور باشد:

/features/login
  ├── ui/          ← کامپوننتهای فرم لاگین
  ├── model/       ← منطق و validation مربوط به login
  ├── api/         ← تماس با سرور برای login
  └── index.ts     ← export یکپارچه feature

/features/product-list
  ├── ui/
  ├── model/
  ├── api/
  └── index.ts

Domain-oriented Structure چیست؟

Domain-oriented Structure یعنی ساختار پروژه را بر اساس حوزههای کاری (Domain) یا قابلیتهای بیزنسی اصلی تقسیم کنیم، نه صرفاً نوع فایل یا صفحه.

• هر دامنه کاری، مجموعهای از featureها، منطق بیزنسی و دادههای مرتبط را در خودش نگه میدارد.

• این کار باعث میشود تیمها بتوانند روی یک دامنه مستقل کار کنند، وابستگیها محدود شوند و تغییرات بیزنسی راحتتر اعمال شود.

مثال عملی:

فرض کن یک اپلیکیشن فروشگاهی داریم:

/domains/auth
  ├── features/login/
  ├── features/register/
  ├── api/
  └── model/

/domains/product
  ├── features/listing/
  ├── features/detail/
  ├── api/
  └── model/

/domains/cart
  ├── features/cart-view/
  ├── features/checkout/
  ├── api/
  └── model/

Module-based / Package-oriented Architecture

چی هست؟
در معماری Module-based، پروژه به ماژول‌های کاملاً مستقل تقسیم می‌شود که می‌توانند به صورت جداگانه توسعه، تست و حتی deploy شوند. هر ماژول شامل همه چیزهایی است که برای عملکرد خودش نیاز دارد: UI، منطق بیزنسی، State و API.

این رویکرد شبیه Feature-based Architecture است، اما با تمرکز روی استقلال کامل ماژول‌ها و قابلیت انتشار یا استفاده مجدد در پروژه‌های دیگر (مثلاً npm package یا Micro-Frontend).

فرض کنید یک اپلیکیشن فروشگاهی داریم:

/modules/auth
  ├── features/login/
  ├── features/register/
  ├── api/
  └── package.json

/modules/product
  ├── features/listing/
  ├── features/detail/
  ├── api/
  └── package.json

• هر ماژول می‌تواند جداگانه build و deploy شود.

• ماژول auth می‌تواند در پروژه‌های دیگر هم استفاده شود، بدون اینکه به product وابسته باشد.

• State و logic هر ماژول در خودش نگه داشته می‌شود و وابستگی بین ماژول‌ها محدود می‌شود.

مزایا

• استقلال کامل ماژول‌ها: تیم‌ها می‌توانند بدون وابستگی به بخش‌های دیگر روی ماژول خودشان کار کنند.

• Reusability: ماژول‌ها می‌توانند در پروژه‌های دیگر یا در Micro-Frontend دوباره استفاده شوند.

• Deploy مستقل: اگر هر ماژول به صورت package مدیریت شود، امکان به‌روزرسانی و release مستقل فراهم است.

• Scalability: پروژه‌های بزرگ و چند تیمی با این رویکرد راحت‌تر مقیاس‌پذیر می‌شوند.

محدودیت‌ها

• Overhead بیشتر: نیاز به تنظیمات build، versioning و dependency management برای هر ماژول وجود دارد.

• Coordination بین ماژول‌ها: باید قوانین واضحی برای تعامل بین ماژول‌ها داشته باشید، در غیر این صورت پروژه پیچیده و غیرقابل نگهداری می‌شود.

• Initial complexity: برای پروژه‌های کوچک، این معماری ممکن است اضافه و پیچیده باشد.

Micro-Frontend Architecture

Micro-Frontend یعنی پروژه فرانت‌اند را به چند اپلیکیشن مستقل کوچک تقسیم کنیم که هر کدام به تنهایی build، deploy و run می‌شوند.
این معماری مشابه Microservices در بک‌اند است، اما برای فرانت‌اند.
ایده اصلی این است که تیم‌ها کاملاً مستقل کار کنند و پروژه بزرگ و چندتیمی راحت‌تر مقیاس‌پذیر شود.

مثال :

/microfrontends/auth-app
  ├── login-feature/
  ├── register-feature/
  └── package.json

/microfrontends/product-app
  ├── listing-feature/
  ├── detail-feature/
  └── package.json

/microfrontends/cart-app
  ├── cart-view-feature/
  ├── checkout-feature/
  └── package.json

مزایا

• تیم‌ها مستقل توسعه می‌دهند: هر تیم می‌تواند اپ خودش را بدون نگرانی از بخش‌های دیگر توسعه دهد.

• Deploy مستقل: امکان انتشار feature یا بخش جدید بدون تاثیر روی کل پروژه.

• مقیاس‌پذیری بالا: مناسب پروژه‌های بزرگ با چندین تیم و چند دامنه کاری.

محدودیت‌ها

• پیچیدگی بالای runtime: برای مدیریت routing، state و استایل‌ها بین Micro-Frontendها نیاز به معماری دقیق داریم.

• Build و deploy پیچیده: هر اپ باید pipeline و versioning جداگانه داشته باشد.

• وابستگی‌ها باید مدیریت شوند: داده و state مشترک بین Micro-Frontendها نیاز به تعریف clear boundary دارد.

  نکته :
  Micro-Frontend زمانی ارزش واقعی دارد که پروژه بسیار بزرگ، چند تیمی و دارای چند دامنه کاری باشد. برای پروژه‌های کوچک یا متوسط، complexity و overhead آن معمولاً توجیه ندارد.

معماری برای آینده و عملکرد (Performance as Architecture)

وقتی درباره Performance صحبت میکنیم، معمولاً ذهنها مستقیم به optimizationهای بعدی مثل minify کردن فایلها یا استفاده از CDN میرود. اما Performance بخشی از معماری است و تصمیماتی که در سطح ساختار پروژه گرفته میشود، میتواند تاثیر بزرگی روی سرعت و کارایی داشته باشد.

معماری حرفهای روی مواردی مثل Critical Rendering Path، Bundle Size، Lazy Loading و Cache Boundary اثر میگذارد. این یعنی Performance فقط یک مرحله بعد از توسعه نیست، بلکه باید از لحظه طراحی ساختار پروژه مد نظر باشد.

مثال عملی:

• جداسازی Featureها و Lazy Loading:
  وقتی هر Feature مستقل باشد و فقط وقتی لازم است بارگذاری شود، زمان Initial Load کاهش پیدا میکند و کاربران سریعتر به محتوا دسترسی دارند.

• تعریف مرزهای واضح برای Cache:
  وقتی boundary برای Cache مشخص شود، مرورگر و شبکه میتوانند از memory و bandwidth بهینه استفاده کنند، بدون اینکه دادههای قدیمی یا غیرضروری دوباره دانلود شوند.

به عبارت دیگر، یک معماری حرفهای نه تنها ساختار و maintainability پروژه را تضمین میکند، بلکه Performance را هم از همان ابتدا در هسته پروژه قرار میدهد.

جمعبندی

هیچ معماری کامل نیست؛ معمولاً ترکیب معماریها بهترین نتیجه را میدهد:

• پروژه کوچک → Feature-based + Component-based

• پروژه بزرگ → Domain-oriented + Feature-based + Component-based

• پروژه چند تیمی → Micro-Frontend + Domain-oriented + Layered

💡 نکته حرفهای: قبل از نوشتن اولین خط کد، از خودتان بپرسید:

• این منطق کجا باید باشد؟

• وابستگیها چگونه محدود شوند؟

• تغییرات بیزنسی آینده چه تأثیری خواهند داشت؟

دوست داشتین تو لینکدین با من در ارتباط باشین :)