‏معماری مقیاس‌پذیر انگولار با Nx

تو این مقاله از تیم Nx اومده که هدف اصلی یه معماری خوب، باز نگه‌داشتن دستِ تیمه: تصمیم‌های برگشت‌پذیر، تکامل تدریجی، و عقب انداختن تعهدها تا وقتی که اطلاعات بیشتری داری. راهش هم طراحی ماژولاره؛ یعنی کپسوله‌کردن، امکان تغییر تدریجی و شکستن وابستگی‌ها با مرزهای روشن. تمرکز مطلب روی معماری در زمان توسعه‌ست، نه فقط زمان اجرا.

نویسنده معماری‌های افقی مثل لایه‌ای، پیازی و شش‌ضلعی رو در برابر رویکرد عمودی می‌ذاره: به‌جای تقسیم کد بر اساس مسئولیت فنی (کامپوننت، سرویس، دایرکتیو)، کد حول دامنه‌های کسب‌وکار سازماندهی می‌شه. دامنهٔ خوب اونیه که قابلیت کسب‌وکاری مشخصی داره، با ساختار تیم‌ها هم‌خونی داره (قانون کانوی)، مسئولیتش روشنه و می‌تونه مستقل از بقیه رشد کنه. توصیه‌ش اینه اول درشت شروع کنین و بعد ریزترش کنین.

هر دامنه به چند کتابخانه تقسیم می‌شه: کتابخانه‌های feat-* برای قابلیت‌ها و صفحه‌ها، ui-* برای کامپوننت‌های نمایشی و data-access برای ارتباط با API و مدیریت state (تو انگولار امروزی معمولاً سیگنال‌محور). این پروژه‌ها قرار نیست روی npm منتشر بشن؛ فقط مرز می‌سازن و با path mapping تو tsconfig.base.json به هم وصل می‌شن. خود اپلیکیشن هم باید نازک باشه: عمدتاً روتینگ، بوت‌استرپ و چیدمان، و بقیهٔ منطق تو کتابخونه‌ها. نویسنده تأکید می‌کنه برای این کار لزوماً به مونوریپو نیاز ندارین.

بخش مهم مقاله اینه که مرزِ پوشه‌ای بدون ضمانت اجرا بی‌فایده‌ست. Nx با قانون‌های module boundary تو کانفیگ ESLint این مرزها رو اجباری می‌کنه؛ اونم با دو نوع تگ: تگ scope: برای دامنه و تگ type: برای لایهٔ معماری.

{
  sourceTag: 'type:ui',
  onlyDependOnLibsWithTags: ['type:ui', 'type:util', 'type:data-access']
},
{
  sourceTag: 'scope:products',
  onlyDependOnLibsWithTags: ['scope:products', 'scope:shared']
}

با این قانون‌ها مثلاً دامنهٔ سفارش‌ها می‌تونه به محصولات وابسته باشه ولی برعکسش نه، و کد shared فقط به shared وصل می‌شه تا چرخهٔ وابستگی درست نشه. تخلف هم موقع لینت و تو چک‌های CI به‌سرعت خطا می‌ده. نویسنده در آخر می‌گه استانداردهای تیم رو با ژنراتورهای سفارشی Nx خودکار کنین و نشونه‌هایی مثل تغییر مکرر چند کتابخونه برای یه فیچر یا وابستگی حلقوی رو علامت این بدونین که مرزها باید بازتعریف بشن.

نکات کلیدی:

• کد رو حول دامنه‌های کسب‌وکار بشکنین، نه حول نوع فنی فایل‌ها
• الگوی کتابخانه‌ها: feat-* برای قابلیت، ui-* برای نمایش، data-access برای API و state
• اپلیکیشن فقط ظرف لینک‌شدن و دیپلویه؛ منطق تو کتابخونه‌ها می‌مونه
• مرزها با تگ‌های scope: و type: و قانون‌های ESLint اجباری می‌شن
• برای ماژولار کردن حتماً لازم نیست از اول مونوریپو بسازین