سنگ بنای توسعه نرم‌افزار مدرن (The Cornerstone of Modern Software Development)
“برنامه‌هایی بنویسید که یک کار را انجام دهند و آن را به خوبی انجام دهند”، داگلاس مک‌ایلروی، یکی از معماران کلیدی یونیکس در بل لبز، این فلسفه را بیان کرد. این دیدگاه سال‌هاست توسعه نرم‌افزار را شکل داده و بر همه چیز از میکروسرویس‌های مبتنی بر API و کانتینری‌سازی تا WebAssembly، طراحی کرنل و کتابخانه‌های زبان‌های خاص دامنه تأثیر گذاشته است. در هسته خود، این اصل جداشدگی مسئولیت‌ها (SoC) را تجسم می‌بخشد — عملی که نرم‌افزار را به‌صورت اجزای مدولار طراحی می‌کند که هر یک عملکرد مشخصی دارند و مستقل عمل می‌کنند.
SoC یک مفهوم بنیادی در مهندسی نرم‌افزار است و با اصولی مانند «تکرار نکن» (DRY)، SOLID و معماری تمیز همسو است. اغلب به‌صورت اصل مسئولیت واحد (SRP) بیان می‌شود — ایده‌ای که هر واحد نرم‌افزاری باید هدف مشخصی داشته باشد.
از جدا کردن لایه رابط کاربری از بک‌اند گرفته تا APIهای قابل ترکیب، SoC به تیم‌ها کمک می‌کند پروژه‌های بزرگ را به اجزای متمرکز و قابل مدیریت تقسیم کنند. جیکوب آیدسکوگ، مدیر فناوری Curity می‌گوید: “به‌طور کلی، هنگام برخورد با یک مشکل، بهتر است زودتر مسئولیت‌ها را جدا کنید. این اساس ساختار هر سیستم است.”
اما با شتاب توسعه مبتنی بر هوش مصنوعی، آیا SoC هنوز به همان اندازه گذشته اهمیت دارد؟ در ادامه، نقش آن در نرم‌افزار مدرن و تأثیر روندهای نوظهور بر مدولار بودن و میکروسرویس‌های مبتنی بر API بررسی می‌شود.
SoC چیست؟
جداشدگی مسئولیت‌ها (SoC) یک استاندارد سخت و سریع نیست بیشتر یک فلسفه معماری است که در روش‌های مختلف خود را نشان می‌دهد. گاهی اوقات، منطقی است که چیزها را به بلوک‌های سازنده فردی یا «مسئولیت‌ها» تقسیم کنیم. در این زمینه، یک مسئولیت به یک مشکل خاص اشاره دارد که یک واحد نرم‌افزاری برای حل آن طراحی شده است.
تجلیات این اصل همه جا وجود دارد از ترمینال Bash تا معماری‌های میکروسرویس، بارهای کاری کانتینری موقت و فراتر از آن. آیدسکوگ می‌گوید: “این اصل طراحی همه جا حضور دارد. بنابراین SoC همیشه مرتبط و بی‌زمان است.” او اضافه می‌کند: “وقتی مسئولیت‌ها را مخلوط می‌کنید، برای یک مهندس ارشد آزاردهنده است این چیزی است که تجربه به شما می‌دهد.”
اگرچه برخی معماری‌های مونولیتیک هنوز معتبر هستند، مدولار بودن به روند غالب تبدیل شده است. اکثر محصولات مدرن در واقع ترکیبی از واحدهای متمایز هستند — گزارش State of the API 2024 پستمن نشان داد که به‌طور متوسط بین ۲۶ تا ۵۰ API هر برنامه را تغذیه می‌کنند.
مزایای SoC
جدا کردن مسئولیت‌ها نرم‌افزاری قابل توسعه، تطبیق‌پذیر و آسان‌تر برای نگهداری ایجاد می‌کند. آیدسکوگ می‌گوید: “ما این کار را اوایل هنگام ساخت یک سیستم هویت انجام دادیم. جدا کردن چیزها باعث می‌شود رشد آن در طول زمان بسیار آسان‌تر باشد.”
بدون SoC، اجزای به‌شدت وابسته می‌توانند مقیاس‌پذیری را به یک کابوس تبدیل کنند. برای مثال، اگر تجربه‌های فرانت‌اند به منطق بک‌اند وابسته باشند، حتی به‌روزرسانی‌های جزئی ممکن است نیازمند تکرار و تغییر کد در چندین مکان باشد. مدولار نبودن ضعیف همچنین منجر به یادگیری مجدد و بازنویسی کد در طول زمان می‌شود و اصطکاک غیرضروری ایجاد می‌کند.
برعکس، SoC تکرار کد را کاهش می‌دهد، کشف کد را بهبود می‌بخشد و به توسعه‌دهندگان کمک می‌کند پروژه‌ای ساختاریافته را به‌طور مؤثرتر مدیریت کنند. اگر نرم‌افزار شما یک کار خاص را به خوبی انجام دهد و بتواند با سایر اجزا از طریق APIهای استاندارد تعامل داشته باشد، آماده مواجهه با ناشناخته‌ها هستید. جدا کردن مسئولیت‌ها بدون مهندسی بیش از حد نرم‌افزاری مقاوم در برابر آینده ایجاد می‌کند که می‌تواند همراه با نیازهای کسب‌وکار تکامل یابد.
این طرز فکر فراتر از کد نیز اعمال می‌شود و در توسعه محصول و معماری سیستم قابل مشاهده است. به امنیت API فکر کنید اکوسیستم‌های مدرن بر اجزای خارجی متمایز مانند پلتفرم‌های مدیریت API، ابزارهای نظارت و دروازه‌ها متکی هستند. هر کدام نقش منحصر به فردی دارند، اما همه باید به‌طور یکپارچه ادغام شوند.
نمونه‌ای از SoC: سیستم‌های هویت مدرن
یک نمونه واقعی SoC را می‌توان در سیستم‌های هویت جداشده یافت. مدیریت هویت و دسترسی مشتری (CIAM) شامل استانداردهای ورود متعدد، سیستم‌های داده قدیمی و جریان‌های احراز هویت است که باید به خوبی با هم کار کنند. آیدسکوگ می‌گوید: “حل این مشکل به‌صورت نقطه‌به‌نقطه یا سفارشی دشوار است. باید از دیدگاه معماری به آن فکر کنید.”
معماری‌های هویت بر اجزای مدولار با مسئولیت‌های متمایز متکی هستند تا نیازهای متنوع احراز هویت و ذخیره‌سازی داده‌های کاربران را مدیریت کنند. در Curity، هویت حول چهار بلوک اصلی ساختاریافته است:
-
سرویس احراز هویت: استانداردسازی جریان‌های احراز هویت برای مشتریان مختلف، شامل روش‌های ورود متعدد از جمله ۲FA و MFA.
-
سرویس توکن امن: عملکرد به‌عنوان سرور OAuth و صدور و اعتبارسنجی توکن‌ها برای APIها و برنامه‌ها.
-
سرویس فدراسیون: در لایه برنامه عمل می‌کند و دسترسی متقابل دامنه‌ای را با استانداردهایی مانند SAML و OpenID Connect ممکن می‌سازد.
-
سرویس پروفایل: مدیریت داده‌های حساب کاربری و داده‌های ذخیره شده.
اگرچه این بلوک‌های سازنده پایه را تشکیل می‌دهند، پایان داستان نیست. معماری‌های هویت اغلب نیازمند جداسازی جزئی بیشتر هستند. آیدسکوگ می‌گوید: “وقتی چیزها را چیده‌ایم، می‌پرسیم: ‘یک جعبه جدید بسازیم یا در جعبه موجود جا می‌گیرد؟'” ظهور هویت غیرمتمرکز پیچیدگی‌های جدیدی ایجاد کرده است، مانند نیاز به یک مؤلفه اختصاصی برای مدیریت صدور مدارک قابل تأیید.
مخالفت‌ها با SoC
البته، قرار دادن همه چیز در جعبه‌های مرتب و منظم می‌تواند پیامدهای منفی داشته باشد. گاهی، توسعه‌دهندگان می‌توانند این نظریه را بیش از حد جدی بگیرند و طراحی‌های جزئی بیش از حد ایجاد کنند که بهره‌وری را کاهش می‌دهد.
برای مقابله با این مشکل، برخی توسعه‌دهندگان از “قاعده سه” که توسط مارتین فاولر در Refactoring محبوب شد، پیروی می‌کنند. این قانون پیشنهاد می‌دهد که کد تنها زمانی به اجزای قابل استفاده مجدد refactor شود که سه بار یا بیشتر ظاهر شده باشد، تا از انتزاع زودهنگام جلوگیری شود.
مزایای استفاده مجدد SoC نیز اغلب اغراق‌آمیز است، می‌گوید آیدسکوگ. گاهی هرگز یک مؤلفه استفاده نمی‌شود. اما وقتی استفاده مجدد لازم می‌شود، عدم جداسازی مسئولیت‌ها در اوایل می‌تواند استخراج عملکرد را در آینده بسیار دشوارتر کند.
بسیاری از استدلال‌های منطقی نیز علیه معماری‌های میکروسرویس وجود دارد. واقعیت این است که معماری‌های میکروسرویس اغلب نیازمند سربار شبکه‌ای اضافی، ابزارهای نظارت و الگوهای جدید استقرار برای حفظ عملکرد شبکه‌ای خدمات هستند.
اما حتی در توسعه مونولیتیک، SoC هنوز در تعریف مرزهای واضح نقش دارد. آیدسکوگ می‌گوید: “اساساً همه چیز باید فرآیندهای جداگانه یا ماشین‌های جداگانه باشند. می‌تواند یک برنامه باشد اما جدا شده.” یک برنامه خاص کاربردی، مانند ویرایشگر عکس، ممکن است مونولیتیک باشد، اما هنوز از ماژول‌های جداگانه تشکیل شده است.
با اینکه SoC یک اصل راهنما باقی مانده، دانستن زمان جداسازی مسئولیت‌ها — و زمان اجتناب از پیچیدگی غیرضروری — یک فرآیند شهودی است که با تجربه به دست می‌آید.
آیا SoC در عصر هوش مصنوعی کم‌رنگ می‌شود؟
ظهور توسعه مبتنی بر هوش مصنوعی چالش‌های جدیدی برای اصول طراحی نرم‌افزار سنتی ایجاد کرده است. در حالی که دستیاران کدنویسی تولیدی می‌توانند بهره‌وری را به‌طور چشمگیری افزایش دهند، اغلب توانایی دیدن تصویر بزرگ‌تر را ندارند و بازسازی کد را دشوارتر می‌کنند و به نگرانی‌های بدهی فنی کمک می‌کنند.
اگرچه معماری‌های جداشده هنوز ارزشمند هستند، آیدسکوگ اشاره می‌کند که صنعت کمی از ذهنیت SoC در عصر هوش مصنوعی فاصله گرفته است. او می‌گوید: “هوش مصنوعی واقعاً برای این مشکل راه‌حل ارائه نمی‌دهد. مانند هر تکنولوژی جدید، ابتدا نمی‌توان آن جعبه‌ها را به وضوح دید — همه چیز مبهم است. اما با بلوغ تکنولوژی، شفاف می‌شود و به حالت قبل بازمی‌گردد.”
در حالی که برخی معتقدند SoC در برخی حوزه‌ها از مد افتاده، هنوز در حوزه‌های دیگر عمیقاً جا افتاده است. آیدسکوگ به مانفیست‌های Kubernetes اشاره می‌کند که نقش اجزای فردی را به‌طور صریح تعریف می‌کنند. به همین ترتیب، مدل TCP/IP، که بخشی بنیادی از اینترنت است، جداسازی واضح بین لایه‌های برنامه، انتقال و شبکه را حفظ می‌کند.
SoC: ضروری برای توسعه مدرن
با وجود تغییرات در روند نرم‌افزار، جداشدگی مسئولیت‌ها همچنان بخش ضروری توسعه مدرن است. این اصل همچنان به‌عنوان سنگ بنای معماری مقیاس‌پذیر عمل می‌کند، حتی اگر همیشه در کانون توجه نباشد.
به‌طور خلاصه، مدولار بودن همچنان ادامه دارد. بسیاری از شرکت‌ها هنوز در حال تقسیم مونولیت خود هستند. آن‌ها نمی‌توانند با روش قدیمی مقیاس‌پذیر باشند، می‌گوید آیدسکوگ — هزینه‌ها بیش از حد بالاست. اگرچه میکروسرویس‌ها و معماری‌های جداشده پیش‌فرض هر مورد استفاده نیستند، اما هنوز استراتژی‌های کلیدی در تلاش‌های تحول دیجیتال برای باز کردن سیستم‌های به‌شدت وابسته هستند.
با این حال، SoC همیشه به‌صورت رسمی کدگذاری نمی‌شود گاهی فقط جعبه‌های نظری روی کاغذ هستند. بنابراین، دانستن زمان جداسازی مسئولیت‌ها و درک تأثیرات تجاری و نگهداری تصمیمات شما عمدتاً یک فرآیند شهودی است، چیزی که مهندسان ارشد حس ششم برای آن دارند.
SoC می‌تواند برای افراد مختلف معانی متفاوتی داشته باشد. اما برای بیشتر رهبران فنی، این اصل برای تفکر سیستمی حیاتی است. او می‌گوید: “با رشد سیستم‌ها، اگر سازماندهی نکنید، با دیوار برخورد خواهید کرد. من جداشدگی مسئولیت‌ها را سنگ بنای مهمی برای جلوگیری از بدهی فنی می‌بینم.”
