در دنیای توسعه نرم‌افزار، اصول زیادی هستند که شاید اسم‌شان را زیاد شنیده باشیم اما به‌مرور زمان، در عمل از آن‌ها فاصله گرفته‌ایم. تفکیک مسئولیت‌ها (Separation of Concerns یا به اختصار SoC) یکی از همان اصول کلیدی است که اغلب، در سایه‌ی فشارهای روزمره، تحویل سریع فیچرها و معماری‌های پیچیده، فراموش می‌شود.

اما این اصل دقیقاً چیست؟ چرا مهم است؟ و چطور می‌تواند مسیر توسعه‌ی ما را پایدارتر و حرفه‌ای‌تر کند؟


اصل ماجرا چیست؟

تفکیک مسئولیت‌ها می‌گوید:

«هر بخش از یک سیستم نرم‌افزاری، باید تنها مسئول انجام یک نوع کار یا رسیدگی به یک نوع دغدغه باشد.»

یعنی ما نباید کلاس‌هایی داشته باشیم که هم داده را از دیتابیس بخوانند، هم تصمیم‌های تجاری بگیرند، هم داده را به فرانت‌اند بدهند، و تازه لاگ هم بنویسند!

این اصل ساده به ما کمک می‌کند که نرم‌افزار را به بخش‌های مستقل تقسیم کنیم. بخش‌هایی که:

  • هر کدام یک مسئولیت مشخص دارند،

  • قابل تست و نگهداری‌اند،

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


یک مثال روزمره

فرض کنید در حال ساخت یک فروشگاه اینترنتی هستید. اگر همه‌ی منطق نمایش محصول، تخفیف‌ها، محاسبه‌ی موجودی و تعامل با پایگاه داده در یک فایل PHP یا یک کلاس React قرار گیرد، چه اتفاقی می‌افتد؟

  • اگر بخواهید فقط UI را عوض کنید، باید در دل کدی بروید که محاسبات مالی انجام می‌دهد.

  • اگر دیتابیس را از MySQL به PostgreSQL تغییر دهید، ناگهان بخش بزرگی از کد را باید بازنویسی کنید.

  • اگر یک باگ کوچک در محاسبه‌ی قیمت بیفتد، احتمالاً ظاهر سایت هم دچار مشکل می‌شود!

اما اگر طبق اصل تفکیک مسئولیت‌ها عمل کرده باشید، این بخش‌ها از هم جدا هستند. هر کدام تست مخصوص خود را دارند و تغییر در یکی، باعث اختلال در دیگری نمی‌شود.


ارتباط با معماری مدرن: Headless CMS

تفکیک مسئولیت‌ها فقط یک اصل نظری نیست. در معماری‌های مدرن مثل Headless CMS‌ دقیقاً با همین نگاه شکل گرفته‌اند.

در اپیزود ششم پادکست کدشناسی با عنوان «Headless CMS»، درباره‌ی این موضوع دقیق‌تر صحبت کرده‌ام:

اینکه چگونه با جدا کردن لایه‌ی مدیریت محتوا از لایه‌ی نمایش، می‌توان تجربه‌های کاربری متنوع و مقیاس‌پذیر ساخت. اینکه چرا سیستم‌های Headless اساساً بر پایه‌ی تفکیک دغدغه‌ها طراحی شده‌اند: یک بخش فقط محتوا را مدیریت می‌کند، بخش دیگر فقط محتوا را نمایش می‌دهد.

اگر علاقه دارید ببینید این اصل چگونه در معماری‌های واقعی مثل CMSها یا طراحی APIها اعمال می‌شود، شنیدن این اپیزود را از دست ندهید:

🎧 کدشناسی – اپیزود ششم: Headless CMS


جمع‌بندی

تفکیک مسئولیت‌ها اصل ساده‌ای است، اما اجرای آن نیاز به تفکر معماری، صبر و گاهی نه گفتن به راه‌حل‌های سریع دارد.

در عصری که معماری‌های مدرن مثل microservices، headless systems و serverless‌ها همه حول محور همین اصل شکل گرفته‌اند، شاید وقتش رسیده دوباره به این سؤال برگردیم:

«آیا این کدی که می‌نویسم، فقط یک دغدغه را حل می‌کند؟ یا در حال حمل چند مسئولیت متناقض است؟»


پانوشت:

اگر تجربه‌ای از رعایت (یا عدم رعایت!) این اصل در پروژه‌هایتان دارید، خوشحال می‌شوم در بخش دیدگاه‌ها درباره‌اش بخوانم. و اگر از علاقه‌مندان به معماری نرم‌افزار هستید، سری به بقیه‌ی اپیزودهای پادکست کدشناسی بزنید 😉