https://virgool.ir/feed/@alikhorasani2002fa2026-11-11 21:51:24https://virgool.ir/images/default-avatar.jpghttps://virgool.ir/@alikhorasani2002https://virgool.ir/@alikhorasani2002/گزارش-جامع-تحلیلی-و-بررسی-کتاب-team-topologies-q3gh4ncu6r82 مقدمهکتابی که طی این ترم مطالعه کردم و قصد دارم در این گزارش جامع، برداشت‌ها و نتایج حاصل از خواندن آن را به اشتراک بگذارم، کتاب Team Topologies نوشته متیو اسکلتون و مانوئل پایس است. دنیای توسعه نرم‌افزار، همواره با این چالش مواجه بوده‌است که چرا با وجود استفاده از بهترین ابزارها و متدولوژی‌های چابک، سرعت تحویل نرم‌افزار در سازمان‌های بزرگ کمتر می‌شود و کیفیت فدای سرعت می‌شود. با خواندن این کتاب متوجه شدم که ریشه بسیاری از این مشکلات در کدها یا ابزارها نیست، بلکه در نحوه نگاه ما به ساختار تیم‌ها و الگوهای ارتباطی بین انسان‌ها پنهان شده است. این گزارش، چکیده‌ای تحلیلی و مفصل از یادگیری‌های من در طول مطالعه فصول مختلف این کتاب است که سعی شده با توضیحاتی روان نوشته شود. بخش اولدر فصل‌های ابتدایی کتاب، یکی از مهم‌ترین مسائلی که ذهن من را به خود درگیر کرد، نقد کردن ساختارهای سنتی سازمان‌ها بود. من متوجه شدم که امروزه سازمان‌های فعال در حوزه فناوری اطلاعات را باید به عنوان موجوداتی زنده، پیچیده و انعطاف‌پذیر در نظر گرفت، نه سیستم‌هایی خطی و مکانیکی.بسیاری از سازمان‌ها برای مدیریت کارهای پیچیده، همچنان به چارت‌های سازمانی سلسله‌مراتبی و از بالا به پایین اتکا می‌کنند. اما نویسندگان کتاب به درستی استدلال می‌کنند که این چارت‌های سازمانی قدیمی، به هیچ وجه نمی‌توانند نشان دهند که اعضای یک سازمان در واقعیت چجوری با همدیگه ارتباط برقرار می‌کنند. در دنیای واقعی، مهندسان و کارکنان برای پیشبرد کارهای خود به این مرزها پایبند نمی‌مانند، بلکه مستقیماً با هر فرد یا گروهی که به آن وابسته هستند، ارتباط برقرار می‌کنند.من از این بخش یاد گرفتم که تکیه کردن به ساختارهای ثابت و مدل‌هایی مثل مدیریت ماتریسی، دیگه پاسخگوی نیازهای مدرن نیست. این تغییر ساختارهای مداوم و سلیقه‌ای، معمولاً موجی از ترس را بین کارکنان ایجاد کرده و انرژی سازمان را هدر می‌دهد. هر سازمان در واقع از سه ساختار همزمان تشکیل شده است:ساختار رسمی که همان چارت اداری است که صرفاً برای کارهای قانونی و نظارتی کاربرد دارد.ساختار غیررسمی که شامل روابط و میزان نفوذ آدم‌ها روی یکدیگر است.ساختار خلق ارزش که نشان می‌دهد کارها در واقعیت چطور و بر اساس اعتبار افراد پیش می‌روند. بخش دومیکی از جذاب‌ترین مفاهیمی که در این کتاب با آن روبه‌رو شدم، قانون کانوی (Conway's Law) بود. ملوین کانوی در سال ۱۹۶۸ بیان کرد که ساختار هر نرم‌افزار، در نهایت نشان‌دهنده الگوهای ارتباطی همان سازمانی است که آن را می‌سازد. این یعنی یک نیروی پنهان و قدرتمند وجود دارد که معماری نرم‌افزار و ساختار ارتباطات تیمی را دقیقاً شبیه به هم می‌کند.برای مثال اگر یک سازمان تیم‌های خود را در بخش‌های کاملاً جدا و ایزوله مثل تیم تست، تیم پایگاه داده و تیم امنیت قرار دهد، هرگز نمی‌تواند نرم‌افزاری بسازد که جریان کار در آن یکپارچه باشد. برای مثال، اگر چهار تیم مجزا برای اعمال تغییرات در پایگاه داده مجبور باشند کارشان را به یک تیم مجزای مدیریت پایگاه داده بسپارند، بطور طبیعی خروجی این ساختار، نرم‌افزارهایی جداگانه اما متصل به یک پایگاه داده بزرگ و مشترک خواهد بود.استفاده از مانور معکوس کانوی (Reverse Conway Maneuver): برای من بسیار جالب بود که سازمان‌ها می‌توانند از این محدودیت به عنوان یک مزیت استفاده کنند. در این روش، یک سازمان بخصوص، ساختار ارتباطی تیم‌های خود را قبل از ساخت نرم‌افزار، دقیقاً مشابه معماری ایده‌آلی که برای سیستم نهایی در نظر دارد، طراحی می‌کند. به عنوان مثال، اگر سازمانی معماری میکروسرویس مستقل می‌خواهد، باید تخصص کار با پایگاه داده را مستقیماً به داخل خود تیم‌های توسعه‌دهنده اضافه کند تا وابستگی به تیم خارجی از بین برود.شرکت آدیداس نمونه مشخصی بود که در کتاب به آن اشاره شد؛ آن‌ها با الگوبرداری از قانون کانوی، ۸۰ درصد مهندسان خود را به تیم‌های چندتخصصی متمرکز بر محصول تبدیل کردند و توانستند سرعت انتشار محصولات خود را ۶۰ برابر کنند. بخش سومفصل‌های بعدی کتاب، دیدگاه من را نسبت به نیروی انسانی متحول کرد. در تولید نرم‌افزار مدرن، به دلیل سرعت بالا و پیچیدگی تغییرات، تکیه بر تک‌تک افراد غیرعملی است و تیم باید به عنوان کوچک‌ترین و بنیادی‌ترین واحد انجام یک کار در نظر گرفته شود.محدودیت‌های انسانی و عدد دانبار: نویسندگان با اشاره به عدد دانبار، توضیح می‌دهند که ذهن انسان محدودیت‌های تکاملی برای اعتماد و ارتباط دارد و موارد زیر را بررسی میکنند:اندازه ایده‌آل برای یک تیم موفق نرم‌افزاری، حداکثر حدود هفت تا نه نفر است.بزرگ شدن بیش از حد تیم باعث از بین رفتن اعتماد عمیق بین اعضا شده و احتمال گرفتن تصمیمات نادرست را بالا می‌برد.آمازون با قانون معروف خود مبنی بر تیم‌هایی که با دو پیتزا سیر شوند، این محدودیت را به خوبی درک و پیاده‌سازی کرده است.شاید یکی از مهم‌ترین نکاتی که یاد گرفتم، مفهوم بار شناختی یا به اصظلاح Cognitive Load بود. به این معنی که ذهن هر انسان ظرفیت محدودی برای نگهداری اطلاعات دارد و ظرفیت یک تیم نیز برابر با مجموع ظرفیت اعضای آن است. همچنین این بار شناختی به سه دسته تقسیم می‌شود:بار شناختی ذاتی: مربوط به دانش و مهارت پایه‌ای برای انجام کار است، مثل تسلط بر زبان برنامه‌نویسی.بار شناختی اضافی: مربوط به حواشی و محیط انجام کار است، مثل حفظ کردن دستورات پیچیده راه‌اندازی محیط تست.بار شناختی مرتبط: مربوط به اصل چالش و منطق کاری است که ارزش‌آفرینی می‌کند است.کتاب تاکید می‌کند که اندازه و پیچیدگی هیچ بخشی از سیستم نباید از توان ذهنی تیمی که مسئول آن است فراتر برود. سازمان‌ها باید با انجام خودکارسازی کارها، بار شناختی اضافی را به حداقل برسانند تا تمام فضای ذهن تیم برای تفکر و حل مسئله و همان بار مرتبط خالی بماند. اگر به تیمی مسئولیت‌های سنگین و حوزه‌های کاری متعددی بدهیم، تیم به یک گلوگاه تبدیل شده و انگیزه اعضا نابود می‌شود.بخش چهارمدر اواسط کتاب، تمرکز کتاب روی معماری نرم‌افزار و تعیین مرزهای سیستم قرار می‌گیرد. اگر معماری به درستی خرد و کوچک نشود، کدهای ما به بن‌بست می‌رسند. یکی از الگوهای مخربی که من در این بخش با آن آشنا شدم، وجود مونولیت‌های پنهان بود. مونولیت یا همان سیستم یکپارچه و به شدت جفت‌شده، همیشه فقط یک اپلیکیشن غول‌پیکر نیست، بلکه انواع مختلفی دارد:مونولیت متصل به دیتابیس مشترک: زمانی که چندین سرویس مستقل به یک دیتابیس زنجیر شده‌اند.ریلیزهای مونولیتیک: زمانی که میکروسرویس‌ها محیط تست مستقلی ندارند و مجبوریم همه را با هم باندل و ریلیز کنیم.مونولیت توزیع‌شده: این پدیده زمانی رخ می‌دهد که زاویه دید تیم‌محور را نادیده گرفته و سیستم را در نقاط اشتباهی برش می‌زنیم. در این حالت، سرویس‌ها در ظاهر از هم جدا و مستقل هستند، اما برای اعمال یک تغییر کوچک، تیم‌ها مجبورند کدهای چندین سرویس دیگر را هم به صورت هم‌زمان دستکاری کنند که این کار عملاً هیچ خودمختاری و استقلالی برای تیم باقی نمی‌گذارد.محیط کار مونولیتیک: طراحی دفاتر اوپن‌پلان و یکسان برای همه، بدون در نظر گرفتن نیازهای متفاوت تیم‌ها برای تمرکز. صفحات شکست (Fracture Planes): برای خرد کردن سیستم‌های بزرگ، نویسندگان کتاب از اصطلاح صفحات شکست استفاده کرده‌اند؛ این مفهوم به معنی پیدا کردن خطوط طبیعی و شکاف‌های درونی سیستم برای تکه کردن تمیز آن است. استراتژی‌های مهمی برای این کار معرفی شده است:طراحی دامنه محور (DDD): هم‌راستا کردن کدهای نرم‌افزار با زبان و ساختار واقعی دامنه‌های کسب‌وکار.انطباق با قوانین: جداسازی بخش‌هایی که نیاز به حسابرسی و امنیت قانونی دارند تا سرعت بقیه سیستم کند نشود.ریتم و تواتر تغییرات: تفکیک کردن بخش‌های پرسرعت سیستم مثل فرانت‌اند از بخش‌های کند مثل گزارش‌گیری مالی.سطح ریسک‌پذیری و کارایی: جداسازی کدهایی که به مقیاس‌پذیری بالا نیاز دارند یا ریسک بالایی در قطعی دارند.من از این بخش یاد گرفتم که تست اصلی برای مشخص کردن صحت این مرزها این است که از خودمان بپرسیم که آیا ما به عنوان یک تیم می‌توانیم این زیرسیستم را به عنوان یک سرویس مستقل به دیگران ارائه بدهیم. اگر بله، مرز انتخابی کاملاً درست است. بخش پنجمیکی از متحول کننده‌ترین مفاهیم کتاب برای من، کاهش هرج‌ومرج ساختاری تیم‌ها بود. نویسندگان معتقدند که وجود ده‌ها مدل تیم مختلف مثل تیم دیتابیس، تیم تست، تیم معماری و... باعث سردرگمی می‌شود. برای موفقیت، تمام سازمان باید تحت چهارتا توپولوژی بنیادی شکل بگیرد: 1.    تیم‌های هم‌راستا با جریان (Stream-Aligned Teams):o       این تیم‌ها اسکلت اصلی یک سازمان هستند.o       تمرکز آن‌ها روی یک جریان پیوسته از کار مثل یک سفر کاربر یا یک محصول است و اختیار کامل دارند تا ارزش را از ایده تا محیط واقعی تحویل دهند.o       قانون مهم این است که پاسکاری یا همان Handover به تیم‌های دیگر در این مدل باید صفر باشد. این تیم‌ها موقتی نیستند و بودجه بلندمدت دارند. 2.    تیم‌های پلتفرم (Platform Teams):o       هدف این تیم، فراهم کردن استقلال برای تیم‌های هم‌راستا با جریان است تا آن‌ها مجبور نشوند کارهای اولیه را انجام بدهند و به اصطلاح چرخ را از نو اختراع کنند.o       این تیم سرویس‌های داخلی مثل مانیتورینگ، استقرار و لاگ‌گیری را به صورت قابلیت‌های سلف‌سرویس ارائه می‌دهد.o       مهم‌ترین درسی که از این بخش گرفتم، مفهوم کمینه‌ترین پلتفرم زیست‌پذیر (TVP) بود؛ پلتفرم نباید به یک غول پیچیده تبدیل شود، بلکه باید تا حد امکان ساده و نازک بماند. علاوه بر این، موفقیت این پلتفرم در گرو تمرکز شدید بر تجربه توسعه‌دهندهDeveloper Experience است. پلتفرم باید آن‌قدر شفاف و کاربرپسند طراحی شود که از سر راه تیم‌ها کنار برود و بهترین تست برای کیفیت آن، این است که ببینیم یک برنامه‌نویس جدید چقدر راحت و سریع می‌تواند کار با آن را یاد بگیرد. 3.    تیم‌های توانمندساز (Enabling Teams):o       این تیم تشکیل شده از متخصصانی است که زمان کافی برای تحقیق درباره ابزارها و تکنولوژی‌های جدید دارند.o       آن‌ها به تیم‌های جریان کمک می‌کنند تا این شکاف مهارتی را پر کنند.o       هدف نهایی آن‌ها رهبری خدمت‌گزار است و اگر کارشان را درست انجام دهند، بعد از مدتی تیم جریان از نیاز به این مسئله مستقل شده و دیگر به آن‌ها نیازی نخواهد داشت. 4.    تیم‌های زیرسیستم پیچیده (Complicated-Subsystem Teams):o       این تیم‌ها فقط زمانی تشکیل می‌شوند که بخشی از سیستم به شدت نیازمند دانش و تخصص عمیق مثل پردازش ویدیو یا هوش مصنوعی باشد.o       هدف آن‌ها کاهش بار شناختی از روی دوش تیم‌های جریان است تا نیازی نباشد متخصصان بسیار گران‌قیمت در تمام تیم‌ها پخش شوند. کتاب به صراحت می‌گوید که تیمی مجزا به نام تیم پشتیبانی یا Ops نباید وجود داشته باشد؛ بلکه تیمی که نرم‌افزار را می‌سازد باید خودش مسئول اجرای عملیاتی و پشتیبانی آن باشد (You build it, you run it). بخش ششمبعد از شناخت چهار نوع تیم، متوجه شدم که همچنان فقط مشخص کردن نوع تیم‌ها کافی نیست؛ بلکه سازمان باید بداند این تیم‌ها دقیقاً چطوری باید با هم تعامل کنند. کتاب سه مدل تعامل اساسی را معرفی می‌کند که تیم‌ها باید بر اساس هدفشان یکی را انتخاب کنند:1.    همکاری نزدیک (Collaboration):o       زمانی استفاده می‌شود که دو تیم در حال کشف چیزهای جدید یا یادگیری سریع هستند.o       این تعامل نوآوری را به شدت افزایش می‌دهد، اما چون بار ذهنی را زیاد کرده و مرزها را محو می‌کند، باید موقت و هدفمند باشد.o       رفتار مورد نیاز در این مدل تعامل بالا و احترام متقابل است. 2.    حالت ارائه سرویس (X-as-a-Service):o       در این حالت یک تیم مثل پلتفرم، سرویسی را آماده کرده و تیم دیگر با کمترین ارتباط روزمره از آن استفاده می‌کند.o       این مدل برای تحویل قابل پیش‌بینی بسیار عالی است.o       رفتار مورد نیاز در این مدل تاکید شدید روی تجربه کاربری برای تیمی است که سرویس را ارائه می‌دهد. 3.    حالت تسهیل‌گری (Facilitating):o       زمانی که یک تیم که معمولاً تیم توانمندساز است، به تیم دیگر برای رفع موانع یا یادگیری رویکردهای جدید کمک می‌کند.o       رفتار مورد نیاز در این مدل کمک کن و کمک بگیر است؛ یعنی تیم مقابل نیز باید ذهنی باز و پذیرای کمک داشته باشد.بنابراین در نهایت من از این بخش نتیجه گرفتم که اگر تعامل بین دو تیم سخت، عجیب یا پر از اصطکاک است، بنابراین این بی‌دقتی در ارتباطات یک سیگنال خطر است. این موضوع نشان می‌دهد که مرز مسئولیت‌ها اشتباه انتخاب شده و باید با استفاده از سازمان‌دهی مجدد تعاملات، این شکاف را پر کرد. بخش هفتمدر فصل‌های پایانی کتاب، نویسندگان به سراغ پویایی و تکامل سازمان می‌روند. هیچ ساختار سازمانی از ابتدا کامل نیست و سازمان باید با گذشت زمان خود را تکمیل کند.یکی از تشبیه‌های جالب کتاب این بود که تیم‌ها و نحوه ارتباط آن‌ها باید مثل حسگرهای یک موجود زنده عمل کنند. در گذشته، تیم‌های توسعه (Dev) نرم‌افزار را می‌ساختند و به تیم عملیات (Ops) می‌دادند. این کار باعث می‌شد اطلاعات و تجربیات محیط واقعی هرگز به تیم توسعه برنگردد.کتاب تاکید می‌کند که تیم‌های عملیات نباید فقط نگهدارنده سیستم باشند، بلکه نقش یک ورودی حسی با ارزش بالا را دارند. تیم‌های توسعه باید از سیستم‌های قدیمی‌تر (BAU) نیز نگهداری کنند تا درک عمیق‌تری از رفتار واقعی کاربران به دست بیاورند و بین کارهای جدید و نگهداری شکاف دانشی ایجاد نشود. محرک‌های تکامل (Triggers for Evolution):من یاد گرفتم که سازمان باید علائم خطر را بشناسد و به موقع ساختار خود را تغییر دهد. برخی از این محرک‌ها عبارتند از:نرم‌افزار بیش از حد بزرگ شده است پس زمانی که یک تیم نمی‌تواند کل سیستم را درک کند و گلوگاه ایجاد می‌شود.سرعت تحویل کُند شده است پس نشان‌دهنده افزایش وابستگی‌های سنگین بین تیم‌هاست و باید به سمت تعاملات سرویس‌محور حرکت کرد.وابستگی به سرویس‌های زیربنایی متعدد یعنی زمانی که تیم‌های محصول به مجموعه‌ای پراکنده از سرویس‌ها وابسته‌اند، نیاز به یک لایه پلتفرم (Platform Wrapper) به شدت احساس می‌شود.بخش هشتمنویسندگان به جنبه‌های عملیاتی و فیزیکی کار تیمی نیز پرداخته‌اند. و می‌گویند وقتی تیم را به عنوان واحد اصلی پذیرفتیم، باید رابط‌های ارتباطی آن را نیز دقیقاً مشخص کنیم.تعریف رابط تیم (Team API): همان‌طور که نرم‌افزارها از طریق API با هم حرف می‌زنند، تیم‌ها نیز باید API داشته باشند. این API شامل کدها، مستندات، نحوه نسخه گذاری، اصول کاری، کانال‌های ارتباطی ترجیحی و برنامه کاری تیم است. یک تیم باید همواره از خودش بپرسد که آیا تعامل با ما برای بقیه تیم‌ها راحت است؟ و این رابط را دائماً به‌روز کند.از مطالعات موردی کتاب مثل شرکت اسپاتیفای و Auto Trader یاد گرفتم که معماری محیط کار تاثیر مستقیمی بر الگوهای ارتباطی دارد. نه اتاقک‌های کاملاً بسته مناسب‌اند و نه محیط‌های اوپن‌پلان پر از سروصدا.محیط کار باید سه حالت کار فردی با تمرکز بالا، همکاری درون‌تیمی و همکاری بین‌تیمی را پوشش دهد. چیدمان میزها، دیوارهای قابل‌نوشتن و فضاهای غیررسمی باید به گونه‌ای طراحی شوند که تعاملات هدفمند را تسهیل کرده و ارتباطات غیرضروری را محدود کنند. جمع‌بندیبا تموم کردن مطالعه کتاب Team Topologies، دیدگاه من نسبت به مدیریت و مهندسی نرم‌افزار به سطح بهتری رسید. متوجه شدم که ممکن است دلیل بسیاری از مشکلات مثل کندی سرعت، باگ‌های مکرر و استرس بالای کارکنان، کمبود فناوری نباشد، بلکه طراحی ضعیف سازمان باشد.برای اینکه یک سازمان واقعاً موثر باشد، داشتن ساختار درست تیمی کافی نیست. نویسندگان به درستی اشاره می‌کنند که توپولوژی‌های تیمی مثل طراحی یک باغ هستند، اما فرهنگ سازمانی سالم، روش‌های مهندسی درست، بودجه‌ریزی منعطف و شفافیت کسب‌وکار، مانند خاک، آب و کود عمل می‌کنند. بدون این موارد پایه‌ای، بهترین ساختارها نیز شکست می‌خورند.اين مطلب، بخشي از تمرينهاي درس معماري نرم‌افزار در دانشگاه شهيدبهشتي استسید علی سادات خراسانیسید علی سادات خراسانیTue, 11 Aug 2026 00:22:43 +0330https://virgool.ir/@alikhorasani2002/ارکستراسیون-در-سیستم-های-توزیع-شده-مسیری-به-سوی-موفقیت-مروری-بر-رویداد-qcon-2024-cwjezxxgorumعنوان سخنرانی: Orchestrating A Path to Success - a Conversation with Bernd Rueckerسخنران: Bernd Rueckerرویداد: همایش بین‌المللی QCon 2024 :لینک ویدیوhttp://www.youtube.com/watch?v=cxh2IrfGLvQمقدمه:یکی از بنیادی‌ترین چالش‌ها در گذار از معماری‌های یکپارچه به سیستم‌های توزیع‌شده و میکروسرویس‌ها، مسئله مدیریت وضعیت یا همان State Management و هماهنگی جریان‌های کاری یا Workflow Coordination است. زمانی که یک سیستم به ده‌ها سرویس مستقل تجزیه می‌شود، فرآیندهای تجاری یکپارچه مثل فرآیند ثبت و پردازش یک سفارش نیز تکه‌تکه شده و در سراسر شبکه پخش می‌شوند. در این نقطه، معماری با یک دوراهی کلاسیک مواجه می‌شود: استفاده از الگوی Choreography یا الگوی Orchestration. برنت روکر، از معماران پیشگام در حوزه اتوماسیون فرآیند، در سخنرانی خود در رویداد QCon 2024، به بررسی عمیق و تحلیلی این دو الگو می‌پردازد. این سخنرانی تلاش می‌کند تا با رد تعصبات رایج نسبت به معماری‌های رویدادمحور، رویکردی مهندسی و عمل‌گرایانه برای مدیریت تراکنش‌های توزیع‌شده ارائه دهد. در این نوشتار، استدلال‌های مطرح شده در این زمینه را کالبدشکافی کرده و منطق بازگشت به ارکستراسیون در سیستم‌های مدرن را تحلیل خواهیم کرد.تله رقص‌آرایی محض - The Fallacy of Pure Choreographyدر سال‌های اخیر، معماری رویدادمحور و الگوی رقص‌آرایی (Choreography) به عنوان راه‌حل نهایی برای کاهش وابستگی در میکروسرویس‌ها تبلیغ شده است. در این الگو، هیچ کنترل‌کننده مرکزی وجود ندارد؛ هر سرویس وظیفه خود را انجام داده و یک رویداد منتشر می‌کند تا سرویس بعدی با شنیدن آن رویداد، کار خود را آغاز کند.روکر این رویکرد را از منظر ساختاری به شدت نقد می‌کند و آن را معماری ماشین پین‌بال (Pinball Machine Architecture) می‌نامد. در یک ماشین پین‌بال، شما توپ را شلیک می‌کنید (شروع فرآیند) و توپ به صورت تصادفی به موانع مختلف برخورد می‌کند (رویدادها منتشر می‌شوند)، اما هیچ‌کس دقیقاً نمی‌داند توپ در نهایت چه مسیری را طی خواهد کرد. در سیستم‌های نرم‌افزاری، رقص‌آرایی محض باعث می‌شود که هیچ کدی به صورت متمرکز نمایانگر یک فرآیند تجاری کامل نباشد. اگر در فرآیند ثبت سفارش مشکلی پیش بیاید، مهندسان برای ردیابی خطا مجبورند لاگ‌های پراکنده ده‌ها سرویس مختلف را کنار هم قرار دهند تا متوجه شوند فرآیند در کدام نقطه متوقف شده است. این نبود شفافیت، هزینه نگهداری سیستم را به شدت افزایش می‌دهد.  عبور از سایه سنگین ESBبخش مهمی از این ارائه، به ریشه‌یابی ترس مهندسان از الگوی ارکستراسیون می‌پردازد. در دهه گذشته و در دوران معماری سرویس‌گرا (SOA)، ابزارهایی به نام گذرگاه سرویس سازمانی (ESB) برای ارکستراسیون استفاده می‌شدند که به شدت سنگین و غیرمنعطف بودند و منطق تجاری را درون خود حبس می‌کردند. همین تجربه تلخ باعث شد تا معماران مدرن به سمت رقص‌آرایی فرار کنند.اما روکر مفهوم ارکستراسیون مدرن و سبک‌وزن یا همان Lightweight Orchestration را معرفی می‌کند. در این پارادایم جدید، موتور ارکستراسیون صرفاً یک تسهیل‌گر جریان کار است، نه محلی برای نوشتن کدهای تجاری. موتور ارکستراتور دقیقاً می‌داند که فرآیند X از مراحل A، B و C تشکیل شده است. او سرویس A را فراخوانی می‌کند، منتظر نتیجه می‌ماند و سپس به سراغ سرویس B می‌رود. در این حالت، منطق تجاری همچنان درون خود میکروسرویس‌ها باقی می‌ماند، اما منطق جریان کار در یک نقطه مرکزی و شفاف مدیریت می‌شود.مدیریت تراکنش‌های توزیع‌شده و الگوی ساگا - The Saga Patternاز دیدگاه مهندسی نرم‌افزار، پیچیده‌ترین مسئله در سیستم‌های توزیع‌شده، عدم امکان استفاده از تراکنش‌های استاندارد پایگاه‌داده یعنی ACID Transactions در سطح شبکه است. اگر در مرحله اول از حساب کاربر پول کسر شود و در مرحله دوم سیستم انبار دچار قطعی گردد، چگونه می‌توان پول را به صورت امن و خودکار بازگرداند؟سخنران، الگوی Saga را به عنوان راه‌حل منطقی این بحران مطرح می‌کند. ساگا یک تراکنش طولانی‌مدت را به مجموعه‌ای از تراکنش‌های محلی تقسیم می‌کند که هر کدام دارای یک عملیات جبرانی هستند. اجرای دقیق الگوی ساگا در بستر رقص‌آرایی به شدت پیچیده و مستعد خطاست، چون نیازمند شبکه‌ای درهم‌تنیده از رویدادهای بازگشتی است. اما در یک معماری مبتنی بر ارکستراسیون، موتور مرکزی به راحتی و به صورت خودکار، در صورت بروز خطا در هر مرحله، عملیات جبرانی مراحل قبل را به ترتیب معکوس فراخوانی می‌کند تا سیستم به وضعیت پایدار بازگردد.همسویی فناوری با کسب‌وکار - Business-IT Alignmentیکی از ارزش‌های افزوده‌ای که ارکستراسیون مدرن ایجاد می‌کند، ایجاد یک زبان بصری مشترک است. ابزارهای مدرن ارکستراسیون معمولاً از استانداردهایی مثل BPMN برای مدل‌سازی فرآیند استفاده می‌کنند. این امر باعث می‌شود که یک فرآیند پیچیده تجاری به شکل یک فلوچارت گرافیکی زنده و قابل اجرا در بیاید.این شفافیت بصری، شکاف تاریخی میان تحلیلگران کسب‌وکار و مهندسان نرم‌افزار را پر می‌کند. تحلیلگر می‌تواند با نگاه به مانیتورینگ موتور ارکستراسیون متوجه شود که در حال حاضر چند هزار سفارش در مرحله پرداخت متوقف شده‌اند. این سطح از شفافیت و نظارت، در سیستم‌های رویدادمحور و مبتنی بر رقص‌آرایی تقریباً غیرممکن است. تحلیل از مباحث سخنرانیکالبدشکافی استدلال‌های برنت روکر، یک اصل بنیادین در طراحی سیستم‌ها را یادآوری می‌کند: وابستگی در فرآیندهای تجاری یک واقعیت گریزناپذیر است.نخستین نتیجه‌گیری منطقی از این ارائه آن است که تلاش برای پنهان کردن وابستگی‌های ذاتی یک فرآیند تجاری از طریق رویدادهای نامتمرکز، یک خطای معماری است. زمانی که فرآیند ارسال کالا، ذاتاً و منطقاً وابسته به موفقیت‌آمیز بودن پرداخت وجه است، معماری نرم‌افزار باید این وابستگی را به شکلی شفاف، صریح و کنترل‌شده مدیریت کند، نه اینکه آن را در پشت زنجیره‌ای از پیام‌های ناهمگام مخفی کند.دومین محور تحلیلی، مسئله توزیع پیچیدگی است. رقص‌آرایی پیچیدگی را از بین نمی‌برد، بلکه آن را از یک نقطه متمرکز یعنی موتور ارکستراتور به تمام نقاط شبکه پمپاژ می‌کند. منطق سیستمی نشان می‌دهد که تمرکز پیچیدگی در یک ماژول مشخص که ابزارهای قدرتمندی برای نظارت بر آن وجود دارد، بسیار ایمن‌تر از توزیع همان پیچیدگی در میان ده‌ها سرویس مختلف است.در نهایت، دفاع از ارکستراسیون نشان‌دهنده یک رویکرد واقع‌گرایانه به مهندسی است. در دنیای واقعی، قابلیت دیباگ کردن و مدیریت خطاهای شبکه‌ای مهم‌تر از دستیابی به یک معماری کاملاً غیرمتمرکز روی کاغذ است. موتورهای ارکستراسیون با مدیریت بومی این خطاهای شبکه‌ای، بار شناختی سنگینی را از روی دوش توسعه‌دهندگان برمی‌دارند.به طور خلاصه، این سخنرانی اثبات می‌کند که در معماری سیستم‌های توزیع‌شده مدرن، رقص‌آرایی و ارکستراسیون نباید به عنوان دو رقیب متقابل دیده شوند، بلکه باید بر اساس نیاز سیستم انتخاب گردند؛ رقص‌آرایی برای واکنش به تغییرات محیطی و ایجاد اتصال نرم یا به اصطلاح Loose Coupling میان دامنه‌های مختلف، و ارکستراسیون برای کنترل دقیق و قطعیِ فرآیندهای حیاتی درون یک دامنه مشخص.منابع و مراجع:·       ویدیو و پنل تخصصی Orchestrating A Path to Success در رویداد QCon 2024·       مفاهیم مرتبط با الگوی Saga و مدیریت تراکنش‌های توزیع‌شده در میکروسرویس‌ها·       اصول طراحی BPMN و اتوماسیون فرآیندهای تجاری در معماری مدرن·       این مطلب، بخشی از تمرین درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.سید علی سادات خراسانیسید علی سادات خراسانیMon, 06 Jul 2026 21:56:23 +0330https://virgool.ir/@alikhorasani2002/گزارش-روندها-و-ترندهای-معماری-نرم-افزار-در-سال-۲۰۲۴-مروری-بر-رویداد-qcon-ufolothscdebعنوان سخنرانی: 2024 Architecture and Design Trends Reportسخنرانان: پنل تخصصی سردبیران و معماران ارشد InfoQرویداد: همایش بین‌المللی QCon 2024لینک ویدیو: http://www.youtube.com/watch?v=PSVZVAbdURIمقدمه:دنیای مهندسی نرم‌افزار با سرعتی بسیار زیاد در حال تغییر است و گرفتن تصمیمات معماری در چنین محیط پرنوسانی، نیازمند یک قطب‌نمای دقیق برای ارزیابی ریسک و بلوغ تکنولوژی‌هاست. هر ساله، وب‌سایت مرجع InfoQ با جمع کردن تیمی از برجسته‌ترین معماران نرم‌افزار در رویداد QCon، گزارشی جامع از ترندها و روندهای معماری ارائه می‌دهد. این گزارش مبتنی بر منحنی پذیرش فناوری (Technology Adoption Curve) تنظیم می‌شود و فناوری‌ها را در دسته‌های نوآوران (Innovators)، پذیرندگان آغازین (Early Adopters)، اکثریت پیشگام (Early Majority) و اکثریت پیرو (Late Majority) طبقه‌بندی می‌کند. سخنرانی  2024 Architecture and Design Trends Report  یکی از مهم‌ترین ارائه‌های این همایش است که به جای تمرکز بر یک فناوری خاص، تصویری کلان از مسیر حرکت صنعت نرم‌افزار در سال‌های پیش رو رسم می‌کند. در این مقاله، محورهای اصلی این گزارش شامل بازگشت به معماری‌های یکپارچه، ظهور معماری‌های سلولی، ادغام هوش مصنوعی در لایه معماری و تکامل مهندسی پلتفرم را با رویکردی تحلیلی بررسی خواهیم کرد.پیمایش در منحنی پذیرش فناورینقطه شروع این پنل تخصصی، تشریح اهمیت استفاده از ابزارهای تحلیلی برای فیلتر کردن هیاهوی رسانه‌ای از واقعیت‌های مهندسی است. اعضای پنل استدلال می‌کنند که یکی از خطاهای مهلک معماران نرم‌افزار، استفاده از تکنولوژی‌های لایه نوآوران برای سیستم‌های حیاتی کسب‌وکار است. فناوری‌هایی که در سمت چپ منحنی قرار دارند، فاقد مستندات کافی، ثبات ساختاری و جامعه کاربری بزرگ هستند.معمار وظیفه دارد سبد تکنولوژی سازمان را به گونه‌ای مدیریت کند که هسته اصلی سیستم بر روی فناوری‌های لایه اکثریت پیشگام یا اکثریت پیرو بنا شود تا بالاترین میزان ثبات تضمین گردد، و تنها بخش‌های جانبی و آزمایشی سیستم به تکنولوژی‌های نوظهور اختصاص یابد. این گزارش به وضوح نشان می‌دهد که بسیاری از الگوهایی که تا چند سال پیش به عنوان یک انقلاب معرفی می‌شدند، اکنون یا به بلوغ رسیده‌اند و یا به طور کامل از رده خارج شده‌اند.بازگشت به مونولیت‌های ماژولارشاید شگفت‌انگیزترین و بحث‌برانگیزترین ترندی که در گزارش سال ۲۰۲۴ به لایه اکثریت پیشگام منتقل شده است، مفهوم مونولیت ماژولار باشد. در یک دهه گذشته، صنعت نرم‌افزار با سرعت شدیدی به سمت تجزیه سیستم‌ها به صدها میکروسرویس حرکت کرد. با این حال، داده‌های میدانی بررسی شده در این پنل نشان می‌دهد که بسیاری از سازمان‌ها اکنون در حال پرداخت تاوان سنگین این توزیع‌شدگی افراطی هستند.میکروسرویس‌ها مشکلات پیچیده‌ای مثل مدیریت تراکنش‌های توزیع‌شده، تاخیر شبکه، سربار زیرساختی عظیم و سختی در ردیابی خطاها را به سیستم تحمیل می‌کنند. پنل InfoQ تأکید می‌کند که معماری مونولیت ماژولار، راهکاری میانه‌رو و به شدت کارآمد است. در این الگو، تمامی کدها در یک فرآیند واحد اجرا می‌شوند و از دیتابیس مشترکی استفاده می‌کنند، اما در سطح منطقی و درون کدبیس، با استفاده از مفاهیم طراحی دامنه-محور (DDD)، مرزهای کاملاً ایزوله و نفوذناپذیری بین ماژول‌ها رسم می‌شود. این رویکرد، سادگی استقرار و دیباگ مونولیت کلاسیک را با مزایای تفکیک دغدغه‌های میکروسرویس‌ها ترکیب می‌کند و اکنون به عنوان انتخاب پیش‌فرض برای شروع پروژه‌های جدید توصیه می‌شود.معماری مبتنی بر سلول (Cell-Based Architecture)در حالی که مونولیت‌های ماژولار برای بسیاری از سازمان‌ها راهگشا هستند، سیستم‌هایی که در مقیاس‌های غول‌آسا فعالیت می‌کنند نیازمند الگوهای پیشرفته‌تری می‌باشند. گزارش سال ۲۰۲۴، معماری سلولی را به عنوان یکی از ترندهای قدرتمند لایه پذیرندگان آغازین معرفی می‌کند.به جای اینکه تک‌تک میکروسرویس‌ها به صورت مستقل مقیاس‌پذیر شوند، در معماری سلولی، سیستم به واحدهای مستقلی به نام سلول تقسیم می‌شود. هر سلول شامل مجموعه‌ای کامل از سرویس‌ها، پایگاه‌های داده و منطق تجاری است که می‌تواند بار کاری گروه مشخصی از کاربران مثل کاربران یک منطقه جغرافیایی خاص را پردازش کند. مزیت بنیادین این معماری، کنترل شعاع تخریب یا Blast Radius است. اگر یک سلول به دلیل ترافیک غیرعادی یا خطای نرم‌افزاری دچار فروپاشی شود، این خرابی به هیچ وجه به سلول‌های دیگر سرایت نمی‌کند. این الگو که در سیستم‌های ابری آمازون (AWS) هم به کار گرفته شده است، تاب‌آوری را در سطح کلان معماری نهادینه می‌سازد.تغییر پارادایم با هوش مصنوعیورود Generative AI و مدل‌های زبانی بزرگ، دیگر صرفاً یک ابزار برای برنامه‌نویسان نیست، بلکه به عنوان یک مؤلفه فعال وارد نمودارهای معماری شده است. پنل QCon به بررسی چگونگی یکپارچه‌سازی این سیستم‌ها در معماری‌های سنتی می‌پردازد.در این گزارش به صراحت بیان می‌شود که اضافه کردن LLM به سیستم، مفاهیم جدیدی را به معماری تحمیل می‌کند. معماران اکنون باید برای مدیریت پایگاه‌های داده برداری (Vector Databases)، الگوهای بازیابی اطلاعات (RAG) و جریان‌های کاری چندعاملی (Multi-Agent Workflows) برنامه‌ریزی کنند. از آنجا که فراخوانی مدل‌های زبانی معمولاً با تاخیر بالا و عدم قطعیت همراه است، معماران باید از الگوهای ارتباطی ناهمگام، صف‌های پیام و استراتژی‌های مدیریت خطای پیشرفته استفاده کنند تا کندی هوش مصنوعی باعث فلج شدن کل سیستم کاربری نشود. تکامل مهندسی پلتفرم و شاخص‌های سنجش بهره‌وریبخش پایانی گزارش به تکامل حوزه عملیات اختصاص دارد. مفهوم DevOps که زمانی یک فرهنگ بود، اکنون در سازمان‌های بالغ به بلوک‌های سازنده‌ای تحت عنوان مهندسی پلتفرم تبدیل شده است. تیم پلتفرم، زیرساخت را به عنوان یک محصول داخلی با مجموعه‌ای از APIها و پورتال‌های سلف‌سرویس در اختیار توسعه‌دهندگان قرار می‌دهد تا Cognitive Load آن‌ها کاهش یابد.در همین راستا، استفاده از شاخص‌های استاندارد مانند DORA برای سنجش سرعت و پایداری استقرار و متریک‌های SPACE برای سنجش رضایت و بهره‌وری توسعه‌دهندگان از حالت یک مزیت رقابتی خارج شده و به یک الزام برای سنجش سلامت معماری تبدیل گردیده است. اگر معماری سیستم به گونه‌ای باشد که شاخص زمان بازیابی از خطا (MTTR) در دایره متریک‌های DORA همواره بالا باشد، آن معماری از منظر تجاری مردود است.برداشت و تحلیل مباحث گزارشکالبدشکافی دقیق این گزارش، پرده از یک تکامل ایدئولوژیک در مهندسی نرم‌افزار برمی‌دارد، گذر از ایده‌آل‌گرایی آکادمیک به سمت واقع‌گرایی صنعتی.اولین برداشت از این پنل آن است که پیچیدگی، دیگر یک ارزش محسوب نمی‌شود. بازگشت ترندها به سمت مونولیت‌های ماژولار نشان‌دهنده یک بلوغ در تصمیم‌گیری‌های مهندسی است. منطق سیستماتیک حکم می‌کند که تا زمانی که یک کسب‌وکار به مقیاس گوگل یا آمازون نرسیده است، استفاده از الگوهای توزیع‌شده مختص این شرکت‌ها، نه تنها بهینه‌سازی نیست، بلکه نوعی تخریب ساختاری است.دومین محور تحلیلی، تأثیر غیرقابل انکار الگوهای ایزوله‌سازی بر پایداری سیستم است. چه در سطح کوچک مثل مونولیت‌های ماژولار و DDD و چه در سطح کلان مثل معماری‌های مبتنی بر سلول، هدف نهایی معماری ممانعت از انتشار خطا است. این گزارش به لحاظ منطقی اثبات می‌کند که تاب‌آوری نرم‌افزار، حاصل قرار دادن اجزای شکننده درون حصارهای منطقی قدرتمند است.در نهایت، تحلیل نحوه برخورد با تکنولوژی‌های مبتنی بر هوش مصنوعی در این گزارش، نشان‌دهنده آن است که ادغام هر نوآوری، بدون تطبیق زیرساخت ارتباطی آن یعنی استفاده از فرآیندهای ناهمگام به جای همگام، به یک گلوگاه عملکردی منجر خواهد شد.به طور خلاصه، گزارش روندهای معماری ۲۰۲۴ یک پیام شفاف برای مهندسان دارد، موفقیت یک سیستم نرم‌افزاری بر اساس تکنولوژی‌های مدرن به کار رفته در آن سنجیده نمی‌شود، بلکه بر اساس توازن هوشمندانه‌ای سنجیده می‌شود که معمار بین نیازهای فعلی تجاری و پیچیدگی‌های فنی اضافه شده برقرار می‌سازد.منابع و مراجع:·       ویدیو و پنل تخصصی Architecture and Design Trends Report در رویداد QCon 2024·       گزارش سالانه ترندهای معماری در وب‌سایت InfoQ·       مفاهیم مرتبط با منحنی پذیرش فناوری Technology Adoption Curve·       مستندات شاخص‌های ارزیابی عملکرد سیستم DORA Metrics·       این مطلب، بخشی از تمرین درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است. سید علی سادات خراسانیسید علی سادات خراسانیMon, 06 Jul 2026 21:54:49 +0330https://virgool.ir/@alikhorasani2002/تفکر-معمارانه-گذار-از-توسعه-دهنده-به-رهبر-فنی-مروری-بر-رویداد-qcon-2024-k9exo8hte3u0عنوان سخنرانی: Thinking Like an Architectسخنران: Gregor Hohpeرویداد: همایش بین‌المللی QCon 2024 :لینک ویدیوhttp://www.youtube.com/watch?v=Oib06l1CHMEمقدمه:یکی از پیچیده‌ترین گذارها در مسیر شغلی یک مهندس نرم‌افزار، ارتقاء از جایگاه یک توسعه‌دهنده ارشد به یک معمار نرم‌افزار است. بسیاری از مهندسان به اشتباه تصور می‌کنند که این تغییر جایگاه، صرفاً با یادگیری الگوهای طراحی پیچیده‌تر، تسلط بر پایگاه‌های داده مقیاس‌پذیر یا آشنایی با زیرساخت‌های ابری اتفاق می‌افتد. با این حال، پنل تخصصی Thinking Like an Architect در همایش QCon 2024، این پیش‌فرض رایج را به چالش می‌کشد. گرگور هوپ که از معماران برجسته صنعت نرم‌افزار هستند، استدلال می‌کنند که معماری بیش از آنکه مجموعه‌ای از مهارت‌های سخت باشد، یک تغییر بنیادین در الگوی تفکر و نحوه مواجهه با مسائل پیچیده است. این سخنرانی به بررسی ابعاد روان‌شناختی، ارتباطی و تحلیلی نقش معمار می‌پردازد. در این نوشتار، مفاهیم مطرح شده در این پنل را با تمرکز بر تفاوت‌های ساختاری میان تفکر برنامه‌نویسی و تفکر معمارانه، کالبدشکافی خواهیم کرد.تغییر زاویه دیداولین و مهم‌ترین محور این سخنرانی، بررسی تفاوت در زاویه دید میان یک برنامه‌نویس و یک معمار است. توسعه‌دهندگان به اقتضای مسئولیت خود، برای حل مسائل نیازمند تمرکز عمیق هستند. آن‌ها با جزئیات پیاده‌سازی، بهینه‌سازی الگوریتم‌ها و رفع خطاهای سطح کد درگیرند. در این حالت، تفکر مهندس به صورت Reductionist عمل می‌کند؛ یعنی مسئله بزرگ را به قطعات کوچک‌تر مثل توابع و کلاس‌ها تقسیم کرده و هر یک را حل می‌کند.در نقطه مقابل، تفکر معمارانه نیازمند فاصله‌گیری از کد و نگریستن به سیستم از یک نمای کلان است. معمار به جای تمرکز بر عملکرد درون یک ماژول، بر نحوه تعامل ماژول‌ها با یکدیگر، جریان داده‌ها در سطح سیستم، و تأثیر یک تغییر محلی بر کل اکوسیستم تمرکز دارد. گرگور هوپ تأکید می‌کند که یکی از بزرگترین تله‌ها برای معماران تازه‌کار، بازگشت ناخودآگاه به منطقه امن خود، یعنی کدنویسی و درگیر شدن با جزئیات کوچک است، که این امر باعث غفلت از تصویر بزرگ‌تر سیستم می‌شود.   درک بستر کسب‌وکار (Business Context) به عنوان قطب‌نمای معماریبخش عمده‌ای از این سخنرانی به نقد پدیده‌ای اختصاص دارد که می‌توان آن را معماری در برج عاج نامید. معمارانی که بدون درک دقیق از نیازهای واقعی کسب‌وکار، شروع به طراحی سیستم‌های فوق‌پیشرفته، توزیع‌شده و پیچیده می‌کنند. گرگور هوپ می‌گوید که معماری بی‌نقص از نظر فنی، اگر پاسخگوی نیازهای تجاری سازمان نباشد، یک معماری شکست‌خورده است.تفکر معمارانه ایجاب می‌کند که نرم‌افزار به عنوان ابزاری برای تولید ارزش تجاری دیده شود. در این تفکر، محدودیت‌های بودجه، زمان عرضه به بازار و سطح مهارت تیم توسعه، به اندازه ویژگی‌های کیفی نظیر مقیاس‌پذیری اهمیت دارند. یک معمار واقعی می‌داند که گاهی بهترین تصمیم معماری، استفاده از یک دیتابیس رابطه‌ای ساده و یک معماری یکپارچه است، زیرا سازمان در مرحله‌ای از بلوغ قرار دارد که نیاز به توسعه سریع دارد و تحمل سربار نگهداری سیستم‌های توزیع‌شده را ندارد. معمار باید زبان تجارت را بفهمد و تصمیمات فنی خود را با استراتژی‌های کلان سازمان همسو کند. دموکراتیک کردن معماری و رهبری بدون اقتدار مطلقیکی از جذاب‌ترین مفاهیم مدرن که در این پنل مطرح شد، تغییر نقش معمار از یک دیکتاتور فنی به یک تسهیل‌گر و رهبر است. در گذشته، معمار نرم‌افزار کسی بود که در یک اتاق ایزوله نمودارهای UML را رسم می‌کرد و به تیم توسعه دستور می‌داد تا دقیقاً همان را پیاده‌سازی کنند. اما در تیم‌های چابک امروزی، این رویکرد به شدت منسوخ شده است.معماران موفق امروز، از فرآیندی به نام Advice Process استفاده می‌کنند. آن‌ها به جای دیکته کردن تصمیمات، با تیم‌های توسعه‌دهنده همفکری کرده، ریسک‌ها را شفاف می‌کنند و به تیم‌ها اجازه می‌دهند در چارچوب‌های تعیین‌شده، خودشان تصمیمات فنی سطح پایین‌تر را اتخاذ کنند. در اینجا، معمار به عنوان یک منتور عمل می‌کند که بینش سیستمی خود را به برنامه‌نویسان انتقال می‌دهد. تفکر معمارانه یعنی توانایی تأثیرگذاری و رهبری تیم، بدون اینکه لزوماً قدرت سازمانی برای دستور دادن مستقیم را داشته باشید. مهارت‌های نرم و ترجمه ریسک فنیبخش پایانی سخنرانی به موضوعی می‌پردازد که اغلب در آموزش‌های آکادمیک نرم‌افزار نادیده گرفته می‌شود: مهارت‌های ارتباطی. معمار نرم‌افزار، پل ارتباطی میان دنیای صفر و یک مهندسی و دنیای سود و زیان تجارت است.زمانی که یک سیستم دچار بدهی فنی یا به اصطلاح Technical Debt شدیدی است، مدیران اجرایی معمولاً تمایلی به تخصیص بودجه برای بازنویسی کدها ندارند، زیرا ارزش زیادی در آن نمی‌بینند. تفکر معمارانه به این معناست که معمار بتواند این پیچیدگی و بدهی فنی را به زبانی که برای مدیران قابل فهم است مثل افزایش ریسک امنیتی، کند شدن روند توسعه در ۶ ماه آینده، یا ریزش مشتریان به دلیل تاخیر سیستم ترجمه کند. هنر متقاعدسازی، مذاکره و مدیریت تعارضات میان ذی‌نفعان مختلف، ابزارهایی هستند که یک معمار بسیار بیشتر از محیط‌های توسعه با آن‌ها سروکار دارد. برداشت و تحلیل از مباحث سخنرانیتحلیل ساختاری مباحث این پنل نشان می‌دهد که دیسیپلین معماری نرم‌افزار، ماهیتی اجتماعی-فنی دارد. نخستین استنتاج از این سخنرانی آن است که پیچیدگی‌های معماری، غالباً ریشه در ساختارهای سازمانی دارند، نه محدودیت‌های تکنولوژیک (مفهومی که با قانون Conway's Law همسو است). وقتی گرگور هوپ بر اهمیت مهارت‌های ارتباطی و درک کسب‌وکار تأکید می‌کند، در واقع اثبات می‌کند که سیستم نرم‌افزاری، آینه‌ای از نحوه تعاملات انسانی درون سازمان است.دومین محور تحلیلی، رد قاطعانه تقلیل‌گرایی در طراحی سیستم است. برنامه‌نویسی ماهیتی تقلیل‌گرا دارد، اما معماری ماهیتی کل‌گرا می‌طلبد. منطق حکم می‌کند فردی که نتواند اثرات جانبی تصمیم خود را در لایه‌های مختلف تجاری، زیرساختی و انسانی پیش‌بینی کند، در جایگاه معماری دچار خطاهای مهلک خواهد شد.در نهایت، تأکید بر گذار از معماری دستوری به معماری تسهیل‌گرانه، نشان‌دهنده یک تکامل در بلوغ تیم‌های مهندسی است. در دنیایی که فناوری با سرعتی غیرقابل پیش‌بینی تغییر می‌کند، هیچ معماری نمی‌تواند بر تمامی ابزارها مسلط باشد. بنابراین، منطقی‌ترین شیوه، توزیع تصمیم‌گیری فنی در میان تیم‌های توسعه و تبدیل شدن معمار به حافظ یکپارچگی کلان سیستم است.به طور خلاصه، این سخنرانی به صورت علمی و تحلیلی اثبات می‌کند که تفکر معمارانه یک ویژگی ذاتی نیست، بلکه مهارتی اکتسابی است که نیازمند خروج شجاعانه از منطقه امن کدنویسی، و ورود به دنیای پر از ابهام تصمیم‌گیری‌های استراتژیک، مدیریت ریسک و تعاملات انسانی است. منابع و مراجع:·       ویدیو و پنل تخصصی Thinking Like an Architect در رویداد QCon 2024·       مفاهیم مرتبط با قانون Conway's Law و معماری اجتماعی-فنی·       مستندات حوزه رهبری فنی و فرآیند تصمیم‌گیری توزیع‌شده در تیم‌های چابک·       این مطلب، بخشی از تمرین درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.سید علی سادات خراسانیسید علی سادات خراسانیMon, 06 Jul 2026 21:53:04 +0330https://virgool.ir/@alikhorasani2002/معماری-نرم-افزار-کوبرنتیز-نیست-گذار-از-تفکر-زیرساختی-به-تفکر-سیستمی-مروری-بر-رویداد-goto-2024-hss6iyxfbeplعنوان سخنرانی: Architecture Isn’t Kubernetesسخنران: Diana Montalionرویداد: همایش بین‌المللی GOTO 2024 :لینک ویدیو http://www.youtube.com/watch?v=v50oJao8W1Yمقدمه:در سیستم پرشتاب توسعه نرم‌افزار مدرن، ظهور ابزارهای قدرتمند زیرساختی و دواپس تحولات شگرفی در نحوه استقرار و نگهداری سیستم‌ها ایجاد کرده است. با این حال، این پیشرفت ابزاری منجر به شکل‌گیری یک خطای شناختی بزرگ در میان تیم‌های مهندسی شده است و آن هم این است که تقلیل دادن مفهوم پیچیده معماری نرم‌افزار به پیکربندی زیرساخت ابری.دایانا مونتالیون در سخنرانی خود در همایش GOTO 2024، با انتخاب عنوان معماری کوبرنتیز نیست، به نقد این جریان فکری می‌پردازد. او استدلال می‌کند که استقرار کدهای درهم‌تنیده بر روی کلاسترهای توزیع‌شده، مشکلات ساختاری سیستم را حل نمی‌کند، بلکه صرفاً آن‌ها را از سطح کد به سطح شبکه منتقل می‌سازد. در این توضیح، به کالبدشکافی استدلال‌های مطرح شده در این سخنرانی پرداخته و تفاوت‌های بنیادین میان طراحی سیستم و مدیریت زیرساخت را از منظر تفکر سیستمی تحلیل خواهیم کرد.توهم معماری از طریق ابزارگرایی -  The Illusion of Architecture Through Toolingنقطه آغاز و محور اصلی این سخنرانی، نقد پدیده‌ای است که می‌توان آن را سندرم گلوله نقره‌ای زیرساخت نامید. زمانی که سازمان‌ها با مشکلاتی نظیر کاهش کارایی، سختی در افزودن ویژگی‌های جدید یا کندی در فرآیند استقرار مواجه می‌شوند، اغلب به جای بازنگری در طراحی دامنه و مرزبندی‌های منطقی کدهای خود، به ابزارهایی مثل کوبرنتیز پناه می‌برند.سخنران واضحا می‌گوید که کوبرنتیز یک پلتفرم ارکستریشن کانتینر فوق‌العاده است، اما وظیفه آن حل مشکلات مربوط به محل و نحوه اجرای کد است، نه منطق و نحوه تعامل اجزای نرم‌افزار. اگر ما یک معماری مونولیت بدساخت با وابستگی‌های شدید متقابل یا به اصطلاح Tight Coupling داشته باشیم و آن را درون کانتینرهای داکر قرار داده باشیم و با کوبرنتیز مدیریت کنیم، ما یک معماری میکروسرویس خلق نکرده‌ایم؛ بلکه یک مونولیت توزیع‌شده (Distributed Monolith) ساخته‌ایم. این رویکرد نه تنها مشکلات قبلی را برطرف نمی‌کند، بلکه چالش‌های جدیدی مثل تاخیر شبکه، پیچیدگی در ردیابی خطاها و سربار ارتباطات بین‌سرویسی را نیز به سیستم تحمیل می‌کند.  تقابل تفکر خطی با تفکر سیستمی - Linear vs Systems Thinkingبخش عمیق‌تر این ارائه، ریشه‌یابی این خطای شناختی در الگوهای تفکر مهندسان است. مونتالیون تفاوت میان تفکر خطی و تفکر سیستمی را به عنوان مرز جداکننده برنامه‌نویسان و معماران معرفی می‌کند. در تفکر خطی، سیستم به عنوان مجموعه‌ای از قطعات مجزا دیده می‌شود که به صورت ترتیبی کار می‌کنند یعنی الف باعث ب می‌شود، ب باعث ج می‌شود. در این دیدگاه، اگر قطعه‌ای کند باشد، راهکار خطی این است که منابع سخت‌افزاری آن مثل CPU یا RAM از طریق ابزارهایی مثل کوبرنتیز افزایش پیدا کند.اما در مقابل، تفکر سیستمی تأکید دارد که ویژگی‌های کلیدی یک سیستم مثل مقیاس‌پذیری و تاب‌آوری از درون تعاملات بین اجزا نشأت می‌گیرد، نه از خود اجزا به تنهایی. معماری نرم‌افزار علم طراحی این تعاملات است. اگر ماژول ثبت سفارش برای انجام کار خود به شدت نیازمند فراخوانی همزمان ماژول‌های انبار و پرداخت باشد، اضافه کردن pods جدید در کوبرنتیز مشکل گلوگاه گلوگاه ارتباطی را حل نخواهد کرد. معمار باید با تفکر سیستمی، جریان اطلاعات و تعاملات ناهمگام را طراحی کند تا وابستگی‌ها در سطح منطقی کاهش یابند.جریان دانش و مرزبندی‌های دامنه - Knowledge Flow and Domain Boundariesیکی دیگر از مفاهیم کلیدی مطرح شده در این سخنرانی، اولویت دادن به جریان دانش بر جریان داده است. طراحی نرم‌افزار باید بازتابی از نحوه جریان یافتن قوانین کسب‌وکار در سازمان باشد. سخنران با ارجاع به مفاهیم طراحی دامنه-محور (DDD)، تأکید می‌کند که معماری اصیل زمانی شکل می‌گیرد که مرزهای مشخصی بین حوزه‌های مختلف سیستم تعریف شود.در نبود مرزبندی‌های منطقی صحیح، داده‌ها در سراسر سیستم نشت می‌کنند و سرویس‌ها برای انجام ساده‌ترین وظایف به داده‌های یکدیگر وابسته می‌شوند. در چنین سناریویی، ابزارهای مدیریت استقرار کاملاً ناتوان هستند. معماری واقعی نیازمند کشف مفاهیم پنهان در کسب‌وکار، تفکیک مسئولیت‌ها و تعیین استراتژی‌های ارتباطی است. کوبرنتیز تنها زمانی می‌تواند ارزش واقعی خود را نشان دهد که بر روی یک بستر معماری شده و منطقاً تفکیک شده، مستقر گردد.بحران بار شناختی برای تیم‌های توسعه - Cognitive Load Crisisبخش پایانی سخنرانی به تأثیرات مخرب ابزارگرایی بر روی بهره‌وری تیم‌های مهندسی می‌پردازد. زمانی که مرز بین معماری سیستم و زیرساخت محو می‌شود، توسعه‌دهندگان نرم‌افزار مجبور می‌شوند برای نوشتن یک قابلیت ساده تجاری، با مفاهیم پیچیده شبکه‌سازی، فایل‌های حجیم YAML، و تنظیمات ارکستریشن درگیر شوند.این امر منجر به افزایش شدید بار شناختی یا همان Cognitive Load می‌شود. توسعه‌دهنده به جای تمرکز بر روی حل مسئله کسب‌وکار و بهبود کیفیت کد، انرژی ذهنی خود را صرف یادگیری و رفع خطای ابزارهای زیرساختی می‌کند. مونتالیون استدلال می‌کند که یک معماری خوب باید زیرساخت را از دید برنامه‌نویس پنهان کند تا تیم‌ها بتوانند با حداکثر سرعت، ارزش تجاری تولید کنند. برداشت و تحلیل من از مباحث سخنرانیتحلیل عمیق و منطقی استدلال‌های مطرح شده در این ارائه، حقایق مهمی را درباره بلوغ مهندسی نرم‌افزار آشکار می‌کند.اولین استدلال من این است که فناوری‌ها و ابزارهای استقرار هرگز نمی‌توانند جبران‌کننده ضعف در طراحی مفهومی باشند. وقتی سازمانی تلاش می‌کند با استفاده از کوبرنتیز، سیستمی با وابستگی‌های منطقی بالا را مقیاس‌پذیر کند، در واقع در حال درمان Symptoms است، نه خود بیماری. بیماری اصلی در لایه معماری منطقی و نحوه تفکیک دامنه‌ها نهفته است.دومین محور تحلیلی، ضروری بودن تفکیک دغدغه‌ها در سطح کلان سازمانی است. این سخنرانی به لحاظ منطقی اثبات می‌کند که مهندسی پلتفرم یا زیرساخت و معماری نرم‌افزار، دو دیسیپلین کاملاً مجزا با اهداف متفاوت هستند. هدف مهندسی زیرساخت، فراهم کردن محیطی امن، مقیاس‌پذیر و خودکار برای اجرای کد است؛ در حالی که هدف معماری نرم‌افزار، سازماندهی کدها و داده‌ها به گونه‌ای است که سیستم در برابر تغییرات تجاری منعطف بماند. ترکیب این دو مفهوم باعث ایجاد سیستم‌هایی می‌شود که از نظر زیرساختی مدرن به نظر می‌رسند، اما از نظر تغییرپذیری و نگهداری نرم‌افزاری کاملاً فلج هستند.در نهایت، تأکید بر تفکر سیستمی به جای تمرکز بر ابزارها، یک تغییر الگو ضروری برای تیم‌های توسعه مدرن است. معماری یک عمل Reductionist نیست که در آن با بهبود یک سرور یا یک کانتینر، کل سیستم بهبود یابد. کیفیت سیستم در گرو طراحی صحیح ارتباطات میان گره‌هاست.به طور خلاصه، این سخنرانی یک نقد ساختارمند و کاملاً مهندسی‌شده بر استفاده بی‌رویه از ابزارهای ابری است. و پیام آن روشن است: قبل از آنکه نگران نحوه اجرای کد خود در یک کلاستر کوبرنتیز باشیم، باید نگران نحوه سازماندهی منطق تجاری در درون کدهای خود باشیم. معماری، طراحی بستر نیست؛ معماری طراحی ماهیت و ذات سیستم است.منابع و مراجع:·       ویدیو و اسلایدهای ارائه Architecture Isn’t Kubernetes در همایش GOTO 2024·       مفاهیم پایه تفکر سیستمی در مهندسی نرم‌افزار·       اصول طراحی دامنه-محور و تأثیر آن بر معماری·       این مطلب، بخشی از تمرین درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.سید علی سادات خراسانیسید علی سادات خراسانیMon, 06 Jul 2026 21:51:08 +0330https://virgool.ir/@alikhorasani2002/معماری-نرم-افزار-عمل-گرایانه-رهایی-از-تله-راهکارهای-جادویی-مروری-بر-2024-goto-book-club-zb3h7dmjr4jzعنوان سخنرانی: Master Software Architectureسخنرانان: Maciej «MJ» Jedrzejewski و Artur Skowrońskiرویداد: مصاحبه تخصصی GOTO Book Club 2024 :لینک ویدیوhttp://www.youtube.com/watch?v=cI9dfQLTXlUمقدمه:یکی از چالش‌های همیشگی در مسیر توسعه نرم‌افزار، مواجهه با مفاهیم انتزاعی معماری و پیوند دادن آن‌ها با مسائل واقعی کسب‌وکار است. در این گفتگوی تخصصی از سری برنامه‌های GOTO Book Club، آرتور اسکورونسکی با مکئی (MJ)، معمار نرم‌افزار و نویسنده کتاب Master Software Architecture به مصاحبه می‌پردازد. این ویدیو برخلاف ارائه‌های صرفاً تئوریک، رویکردی کاملاً عمل‌گرایانه به معماری دارد و بر اهمیت نگاه کل‌نگر، پرهیز از تعصبات تکنولوژیک و درک معماری به عنوان یک موجودیت زنده و پویا تمرکز می‌کند. در این نوشتار، محورهای اصلی این گفتگو را در قالب اصول کلیدی و چالش‌های واقعی معماری نرم‌افزار کالبدشکافی خواهیم کرد.تله راهکارهای جادویی (Silver Bullets) و پیچیدگی‌های پنهانیکی از جذاب‌ترین بخش‌های این مصاحبه، نقد صریح استفاده کورکورانه از ترندهای روز به عنوان راهکارهای جادویی است. مکئی توضیح می‌دهد که چگونه مهاجرت شتاب‌زده به معماری میکروسرویس می‌تواند به جای حل مسئله، به فاجعه‌ای از پیچیدگی‌های شبکه، تاخیر و چالش‌های تست یکپارچه تبدیل شود. او همچنین ایده تغییر زبان برنامه‌نویسی مثل مهاجرت از جاوا به Rust یا Go برای رفع کندی سیستم را نقد کرده و معتقد است ریشه مشکل معمولاً در مرزبندی‌های اشتباه معماری یا طراحی بد پایگاه داده است، نه خود زبان. استفاده از کش بدون بهینه‌سازی کوئری‌های دیتابیس و مهاجرت نسنجیده به معماری Serverless که می‌تواند در صورت عدم کنترل به هزینه‌های نجومی صد هزار دلاری ختم شود، از دیگر تله‌هایی هستند که معماران باید از آن‌ها دوری کنند.چالش‌های پیاده‌سازی Domain-Driven Design (DDD)در بخش دیگری از گفتگو، به آسیب‌شناسی طراحی مبتنی بر دامنه (DDD) پرداخته می‌شود. سخنران دو خطای شناختی و اجرایی رایج را در این زمینه مطرح می‌کند: نخست، پرش مستقیم تیم‌های توسعه به سراغ مفاهیم تاکتیکی مثل Aggregates و Entities بدون درک عمیق از دامنه مشکل و ماهیت کسب‌وکار. دوم، غفلت از مفاهیم استراتژیک مثل Bounded Contexts پس از فاز اولیه پروژه. او تأکید می‌کند که معماری یک سیستم ایستا نیست؛ با رشد و تغییر کسب‌وکار، مرزهای سیستم نیز باید تکامل یابند. در غیر این صورت، پروژه به سرعت به یک سیستم غیرقابل نگهداری تبدیل می‌شود. معماری به عنوان یک سرمایه‌گذاری بلندمدت تجارینگاه کسب‌وکار به معماری، چالش مهم دیگری است که در این مصاحبه بررسی می‌شود. معماری خوب معمولاً برای مدیران غیرفنی نامرئی است، زیرا نتیجه آن سیستم‌هایی با هزینه نگهداری پایین، عملکرد پایدار و بدون قطعی است. با این حال، غفلت از معماری در ابتدای کار، منجر به رشد نمایی هزینه‌های نگهداری در بازه زمانی ۳ تا ۵ ساله می‌شود؛ تا جایی که ممکن است هزینه‌های نگهداری از سودآوری محصول پیشی گرفته و عملاً کسب‌وکار را با شکست مواجه کند. معمار نرم‌افزار به عنوان یک سرمایه‌گذاری پیشگیرانه عمل می‌کند.ترندها و نقش هوش مصنوعی در معماریدر مواجهه با موج هوش مصنوعی، مکئی دیدگاهی واقع‌بینانه ارائه می‌دهد. او معتقد است که AI امروز می‌تواند کدهای سریع و ظاهراً بی‌نقصی برای فرانت‌اند یا بخش‌های مشخص تولید کند، اما واگذاری طراحی کلان سیستم به آن، در بلندمدت منجر به تولید هیولاهای کدی غیرقابل نگهداری می‌شود. هوش مصنوعی باید صرفاً به عنوان یک ابزار کمکی دیده شود، نه جایگزین تفکر نقادانه معمار. در مقابل، او از Platform Engineering به عنوان یکی از ترندهای کلیدی و مؤثر روز نام می‌برد که تمرکز آن بر توانمندسازی تیم‌های توسعه و ایجاد ابزارهای داخلی برای تسهیل فرآیند تحویل نرم‌افزار است.برداشت و تحلیل من از مباحث مصاحبهرویکرد حاکم بر این مصاحبه، بازگشت به اصول واقع‌گرایی مهندسی است. اولین برداشت من این است که هنر یک معمار، تنها تسلط بر ابزارهای جدید ابری یا فریم‌ورک‌های توسعه نیست، بلکه توانایی متصل کردن نقاط و درک عمیق Trade-offs در هر تصمیم فنی است. وقتی سخنران بر اهمیت تکامل مداوم سیستم تأکید می‌کند، به لحاظ آکادمیک اثبات می‌کند که معماری نرم‌افزار یک فرآیند مستمر است، نه یک فاز ایستا که صرفاً در ابتدای چرخه حیات توسعه انجام و سپس رها شود.دومین محور تحلیلی، تأیید این موضوع است که راهکارهای فنی ایزوله، مشکلات سیستماتیک سازمانی را حل نمی‌کنند. به عنوان یک مهندس نرم‌افزار، نباید فریب زرق و برق فریم‌ورک‌ها را خورد؛ بلکه باید همواره این سوال بنیادین را پرسید که آیا ابزار انتخاب شده چه میکروسرویس و چه دیتابیس‌های پیچیده، ارزش تجاری متناسب با سربار نگهداری‌اش را برای سازمان به ارمغان می‌آورد یا صرفاً تحمیل یک پیچیدگی غیرضروری است.منابع و مراجع:ویدیو و مصاحبه تخصصی Master Software Architecture در رویداد 2024 GOTO Book Clubمفاهیم مرتبط با مهندسی پلتفرم Platform Engineering و آسیب‌شناسی پیاده‌سازی DDDکتاب The Software Architect Elevator اثر Gregor Hohpe (منبع توصیه‌شده در ویدیو)کتاب Designing Data-Intensive Applications اثر Martin Kleppmann (منبع توصیه‌شده در ویدیو)اين مطلب، بخشي از تمرين درس معماري نرم‌افزار در دانشگاه شهيدبهشتي است.سید علی سادات خراسانیسید علی سادات خراسانیMon, 06 Jul 2026 21:49:02 +0330https://virgool.ir/@alikhorasani2002/چند-خط-درباره-تکنیک‎-های-مدرن-معماری-نرم-افزار-c8ovbd27ohu01- مهندسی آشوب - Chaos Engineeringمهندسی آشوب یک رویکرد جذاب و در عین حال عجیب در توسعه نرم‌افزار است. درواقع ما می‌آییم و به جای اینکه صبر کنیم تا سیستم در دنیای واقعی خراب شود، خودمان به صورت عمدی و کنترل‌شده در سیستم خرابی ایجاد می‌کنیم. هدف این است که نقاط ضعف سیستم را قبل از اینکه در محیط عملیاتی و برای کاربران نهایی مشکل‌ساز شوند، کشف کنیم.برای مثال فرض کنید شرکتی مثل نتفلیکس برای اطمینان از اینکه قطع شدن یک سرور باعث توقف پخش فیلم‌ها نمی‌شود، ابزاری می‌سازد که به صورت تصادفی سرورهایش را خاموش می‌کند. این کار به تیم‌ها کمک می‌کند تا سیستم‌هایی تاب‌آورتر یا به اصطلاح Resilient بسازند. اگر بخواهیم تشبیه کنیم در واقع مهندسی آشوب شبیه به واکسن زدن است؛ ما یک ویروس ضعیف‌شده را به سیستم تزریق می‌کنیم تا سیستم ایمنی آن در برابر حملات و قطعی‌های بزرگ‌تر مقاوم شود. 2- بک‌اند برای فرانت‌اند - Backend for Frontend – BFFدر معماری‌های جدید، کلاینت‌ها و کاربران مختلفی مثل اپلیکیشن موبایل، وب‌سایت و ساعت‌های هوشمند داریم. هر کدام از این رابط‌های کاربری، نیازهای متفاوتی به داده‌ها دارند. الگوی BFF پیشنهاد می‌دهد که به جای داشتن یک بک‌اند غول‌پیکر و عمومی برای همه، برای هر فرانت‌اند یک بک‌اند اختصاصی و کوچک بسازیم. این بک‌اند که بهش بک‌اند واسط هم میگن، دقیقا همان داده‌هایی را جمع‌آوری و بهینه‌سازی می‌کند که فرانت‌اند مربوطه‌اش نیاز دارد. این کار باعث می‌شود کدهای سمت فرانت‌اند سبک‌تر بمانند، ترافیک شبکه بهینه شود و تیم‌های توسعه‌دهنده بتوانند با استقلال بیشتری روی برخی محصولات خود مثل اندروید کار کنند، بدون اینکه تغییراتشان روی نسخه وب تاثیر منفی بگذارد. 3- هوش مصنوعی برای مهندسی نرم‌افزار - AI4SEاین مفهوم به معنای استفاده از ابزارهای هوش مصنوعی برای بهبود، سریعتر کردن و بهینه‌سازی فرآیند مهندسی نرم‌افزار است. اینروزا هوش مصنوعی دیگه فقط یک محصول نهایی نیست، بلکه تبدیل به دستیار برنامه‌نویسان شده. ابزارهایی مثل GitHub Copilot یا سیستم‌های تولید خودکار تست نرم‌افزار، نمونه‌های بارز AI4SE هستند. با استفاده از این رویکرد، کارهای تکراری مثل نوشتن کدهای پایه، کشف باگ‌ها، و حتی مستندسازی کدها به هوش مصنوعی سپرده می‌شود. در نتیجه، برنامه‌نویسان می‌توانند تمرکز خود را روی حل مسائل پیچیده‌تر و طراحی معماری‌های بهینه‌تر بگذارند. این فناوری نه‌تنها سرعت توسعه را بالا می‌برد، بلکه با شناسایی زودهنگام خطاها، کیفیت نهایی نرم‌افزار را نیز به شکل چشمگیری افزایش می‌دهد. 4- مهندسی نرم‌افزار برای هوش مصنوعی - SE4AIدر بخش قبل گفتیم که AI4SE درباره کمک هوش مصنوعی به برنامه‌نویسی است، SE4AI دقیقاً برعکس آن عمل می‌کند؛ یعنی چگونه از اصول مهندسی نرم‌افزار برای ساخت و مدیریت سیستم‌های هوش مصنوعی استفاده کنیم.مدل‌های یادگیری ماشین به خودی خود فقط مدل‌های ریاضی و آماری هستند، اما برای اینکه این مدل‌ها به یک محصول قابل اعتماد تجاری تبدیل شوند، نیاز به معماری درست، تست‌پذیری، کنترل نسخه و نگهداری مداوم دارند. در برنامه‌نویسی سنتی، رفتار سیستم قطعی است، اما در هوش مصنوعی رفتار سیستم بر اساس داده‌ها تغییر می‌کند. پس SE4AI تلاش می‌کند با ارائه چارچوب‌ها و استانداردهای مهندسی، توسعه سیستم‌های مبتنی بر هوش مصنوعی را قابل پیش‌بینی، امن و پایدارتر کند. 5- عملیات یادگیری ماشین - MLOpsکلمه MLOps از ترکیب دو کلمه Machine Learning و DevOps بوجود آمده است. وقتی یک مهندس داده مدل هوش مصنوعی خوبی روی کامپیوتر خودش می‌سازد، کار تمام نشده است؛ این مدل باید روی سرورها قرار بگیرد، به صورت مداوم با داده‌های جدید آموزش ببیند و عملکرد آن بررسی بشود. MLOps مجموعه‌ای از روندها و ابزارهاست که هدف آن استقرار و نگهداری یکپارچه و خودکار مدل‌های یادگیری ماشین در محیط عملیاتی است.این رویکرد کمک می‌کند تا فاصله بین تیم‌های هوش مصنوعی و تیم‌های زیرساخت از بین برود. با MLOps، مدل‌ها سریع‌تر به دست کاربر نهایی می‌رسند، به‌روزرسانی آن‌ها خودکار می‌شود و در صورت افت دقت مدل، سیستم بلافاصله هشدار می‌دهد.6- زیرساخت به عنوان کد - Infrastructure as Code - IaCدر گذشته، برای راه‌اندازی یک سرور جدید، مهندسان شبکه باید به صورت دستی سیستم‌عامل نصب می‌کردند، پورت‌ها را باز می‌کردند و نرم‌افزارها را پیکربندی می‌کردند. این کار بسیار زمان‌بر و دارای خطای انسانی بود. زیرساخت به عنوان کد یا همان IaC راهکاری است که در آن تمام نیازمندی‌های زیرساختی مثل سرورها، شبکه‌ها و دیتابیس‌ها در قالب کدهای متنی قابل خواندن نوشته می‌شوند. ابزارهایی مثل Terraform این کدها را می‌خوانند و زیرساخت را به صورت کاملاً خودکار در سرورهای ابری می‌سازند.بزرگترین مزیت IaC این است که می‌توانیم تنظیمات سرور خود را مانند کدهای برنامه‌نویسی، کنترل نسخه کنیم و بارها آن را بدون تغییر و با اطمینان در محیط‌های مختلف اجرا کنیم. 7- درگاه API و شبکه سرویس - API Gateway & Service Meshدر معماری مایکروسرویس، سیستم از ده‌ها یا صدها سرویس کوچک و مستقل تشکیل شده است.API Gateway مثل یک دربان یا پذیرشگر یک هتل عمل می‌کند؛ تمام درخواست‌های کاربران خارجی اول به این درگاه می‌رسند و بعد درگاه تصمیم می‌گیره که هر درخواست را به کدام سرویس داخلی بفرسته و همچنین کارهایی مثل احراز هویت را هم انجام می‌دهد.اما Service Mesh بیشتر شبیه سیستم ارتباطی داخلی کارمندان هتل است. وقتی سرویس‌های داخلی می‌خواهند با هم صحبت کنند، شبکه سرویس ارتباطات بین آن‌ها را مدیریت، رمزنگاری و مانیتور می‌کند. ترکیب این دو مفهوم به مهندسان کمک می‌کند تا ترافیک خارجی و داخلی سیستم را با بالاترین امنیت و بدون پیچیده کردن کدهای اصلی مدیریت کنند. 8- جداسازی مسئولیت خواندن و نوشتن - CQRSالگوی CQRS یک ایده ساده اما بسیار قدرتمند را بیان می‌کند و آن این است که در بسیاری از سیستم‌های نرم‌افزاری، تعداد دفعاتی که اطلاعات را می‌خوانیم بسیار بیشتر از دفعاتی است که اطلاعات را تغییر می‌دهیم یا اضافه می‌کنیم. پس چرا باید هر دو کار توسط یک دیتابیس یا یک مدل پردازشی انجام شود؟در این معماری، مسیر خواندن داده‌ها یا همان کوئری از مسیر نوشتن آن‌ها یا همان کامند، کاملاً جدا می‌شود. ما می‌توانیم برای نوشتن اطلاعات از یک دیتابیس ایمن با قفل‌های قوی استفاده کنیم، اما برای خواندن، داده‌ها را در یک دیتابیس فوق‌سریع و کش‌شده قرار دهیم. این کار عملکرد سیستم‌هایی با ترافیک خواندن بالا مثل شبکه‌های اجتماعی یا فروشگاه‌ها را به شدت بهبود می‌بخشه. 9- معماری رویدادمحور - Event-Driven Architecture - EDAمعماری رویدادمحور، سبکی از طراحی سیستم است که در آن اجزای نرم‌افزار بر اساس زمان وقوع رویدادها با هم تعامل می‌کنند، نه بر اساس درخواست‌های مستقیم و همگام.برای مثال فرض کنید در یک فروشگاه اینترنتی خرید می‌کنید؛ به جای اینکه سیستم ثبت سفارش منتظر بماند تا با سیستم انبارداری هماهنگ کند، صرفاً یک پیام صادر می‌کند که یک سفارش جدید ثبت شد. حالا هر سرویسی که به این موضوع نیاز داشته باشد مثل سرویس انبارداری، صدور فاکتور یا درگاه پرداخت، این پیام را دریافت کرده و کار خودش را مستقل انجام می‌دهد. این معماری وابستگی سیستم‌ها به یکدیگر را کاهش داده و آن‌ها را در برابر ترافیک‌های ناگهانی، مقیاس‌پذیرتر می‌کند. 10- معماری بدون سرور - Serverless Architectureمعماری بدون سرور به این معنی نیست که اصلاً سخت‌افزار یا سروری وجود ندارد، بلکه به این معناست که برنامه‌نویس دیگر هیچ دغدغه‌ای بابت مدیریت، نگهداری، آپدیت سیستم‌عامل یا افزایش منابع سرورها ندارد و تمام این وظایف بر عهده یک ارائه‌دهنده خدمات ابری مثل AWS یا برخی سرویس‌های ابری داخلی است. توسعه‌دهنده فقط کدهای منطقی خود را می‌نویسد و روی پلتفرم آپلود می‌کند.جذاب‌ترین ویژگی Serverless مدل قیمت‌گذاری آن است؛ ما فقط به همان اندازه که کدمان در حال اجراست هزینه پرداخت می‌کنیم، نه برای سروری که ۲۴ ساعته روشن است. این روش هزینه‌های استارتاپ‌ها را به شدت کاهش داده و سرعت استقرار نرم‌افزار را بالا می‌برد. 11- رویکرد API-firstرویکرد API-first یک تغییر تفکر اساسی در روند توسعه محصول است. به طور سنتی، تیم‌ها اول دیتابیس و منطق برنامه را می‌نوشتند و در آخر، برای وصل کردن آن به رابط کاربری، یک API طراحی می‌کردند. اما در رویکرد API-first، قبل از نوشتن حتی یک خط کد، اول قرارداد و ظاهر APIها با دقت طراحی و مستند می‌شود.این کار باعث می‌شود تیم‌های فرانت‌اند و بک‌اند بتوانند به صورت کاملاً موازی کار خودشون را شروع کنند. این رویکرد باعث می‌شود نرم‌افزار از همان روز اول مقیاس‌پذیرتر طراحی شود و قابلیت اتصال به سرویس‌های شخص ثالث در آن بسیار ساده‌تر باشد. 12- طراحی دامنه محور - Domain Driven Design - DDDطراحی دامنه محور یا DDD، رویکردی است که تلاش می‌کند زبان، ساختار و کد نرم‌افزار را دقیقاً با زبان و منطق کسب‌وکار واقعی مشتری هماهنگ کند.مشکل بسیاری از پروژه‌هایی که شکست‌خورده‌اند، این است که برنامه‌نویسان با اصطلاحات فنی صحبت می‌کنند، در حالی که مدیران کسب‌وکار ادبیات خودشان را دارند. DDD مفهومی به نام زبان همه‌جا حاضر) را معرفی می‌کند که همه افراد پروژه باید از آن استفاده کنند.در این رویکرد، معماری برنامه بر اساس بخش‌های مختلف کسب‌وکار مدل‌سازی می‌شود نه صرفا بر اساس جدول‌های دیتابیس. این روش برای توسعه سیستم‌های بزرگ، پیچیده و سازمانی که منطق تجاری سنگینی دارند، یک ضرورت حیاتی محسوب می‌شود. 13- معماری شش ضلعی  - Hexagonal Architectureمعماری شش ضلعی که به عنوان معماری پورت‌ها و آداپتورها نیز شناخته می‌شود، معرفی شد تا گره خوردن منطق اصلی نرم‌افزار با تکنولوژی‌های بیرونی را حل کند. در این معماری، هسته اصلی کسب‌وکار در مرکز سیستم و مثل یک شش ضلعی قرار می‌گیرد و کاملاً مستقل از دیتابیس‌ها، رابط‌های کاربری وب یا فریم‌ورک‌ها نوشته می‌شود.هر چیزی در دنیای بیرون، صرفاً از طریق پورت‌ها یا رابط‌های تعریف شده و آداپتورها یا همان کدهای تبدیل‌کننده، با این هسته ارتباط برقرار می‌کنند. این یعنی اگر روزی بخواهیم دیتابیس خودمان را تغییر دهیم یا نرم‌افزار را از بستر وب به بستر موبایل ببریم، کدهای مرکزی دست‌نخورده باقی می‌مانند و فقط آداپتورهای بیرونی تغییر می‌کنند. 14- منبع‌سنجی رویداد - Event Sourcingدر دیتابیس‌های قدیمی، ما معمولاً فقط آخرین وضعیت یک رکورد را ذخیره می‌کنیم؛ مثلاً موجودی حساب بانکی ما الان ۵ میلیون تومان است. اما در رویکرد Event Sourcing، به جای ذخیره وضعیت فعلی، تمام اتفاقاتی که باعث رسیدن به این وضعیت شده‌اند را به صورت یک زنجیره متوالی ذخیره می‌کنیم مثل مثل دفتر کل حسابداری.یعنی برای مثال ثبت می‌کنیم: ۱۰ میلیون واریز شد، ۳ میلیون برداشت شد و ۲ میلیون دیگر برداشت شد. با پردازش این رویدادها از اول تا آخر، موجودی حال حاضر محاسبه می‌شود. این روش امکانات بی‌نظیری مثل قابلیت بازگشت دقیق به وضعیت سیستم در هر زمان از گذشته، حسابرسی صددرصدی و کشف ریشه‌ای باگ‌های پیچیده را فراهم می‌کند.15- پلتفرم‌های Low-code و No-codeپلتفرم‌های Low-code یا No-code، ابزارهایی هستند که به کاربران اجازه می‌دهند با حداقل برنامه‌نویسی یا حتی بدون نوشتن یک خط کد، و صرفاً با استفاده از رابط‌های گرافیکی و کشیدن و رها کردن، نرم‌افزار بسازند.پلتفرم‌های No-code بیشتر برای مدیران و کاربران تجاری مناسب‌اند تا فرآیندهای ساده خود را خودکار کنند. در مقابل، پلتفرم‌های Low-code علاوه بر ابزارهای بصری، امکان نوشتن کدهای سفارشی را به توسعه‌دهندگان می‌دهند تا پروژه‌های پیچیده‌تری خلق کنند. این ابزارها روند تولید نمونه‌های اولیه و دیجیتالی شدن سازمان‌ها را به شدت تسریع کرده و وابستگی مدوام کسب‌وکارها به برنامه‌نویسان ارشد را برای کارهای تکراری کاهش داده‌اند.16- سیستم‌های مدیریت فرآیند کسب‌وکار - BPMSسیستم‌های مدیریت فرآیندهای کسب‌وکار نرم‌افزارهایی هستند که برای طراحی، اجرا، پایش و بهینه‌سازی فرآیندهای روزمره یک سازمان استفاده می‌شوند. فرض کنید فرآیند تایید قرارداد در یک شرکت شامل چندین مرحله تاییدیه توسط واحدهای حقوقی، مالی و مدیریت است. به جای اینکه این کارها با کاغذ یا تماس تلفنی انجام شود، یک سیستم BPMS این جریان کاری را به صورت خودکار هدایت و پیگیری می‌کند.این ابزارها با استفاده از استانداردهای گرافیکی به مدیران اجازه می‌دهند فرآیندها را رسم کنند. اجرایBPMS باعث شفافیت بیشتر وظایف، کاهش خطاهای انسانی، شناسایی گلوگاه‌های اتلاف وقت و افزایش راندمان کلی کارمندان در یک سازمان می‌شود. 17- صف پیام - Message Queueصف پیام یا Message Queue زیرساختی است که سرویس‌های مختلف نرم‌افزاری می‌توانند پیام‌های خود را به صورت غیرهمزمان در آن قرار دهند تا سرویس‌های دیگر، به نوبت آن‌ها را پردازش کنند. ابزارهایی مثل RabbitMQ یا Kafka دقیقاً همین کار را می‌کنند. برای مثال فکر کنید در یک وب‌سایت شلوغ ثبت‌نام می‌کنید؛ سیستم ثبت‌نام، پیام "ارسال پیامک تایید" را داخل صف می‌اندازد و بلافاصله صفحه خوش‌آمدگویی را به شما نشان می‌دهد.حالا سرور پیامک هر زمان که منابع آزاد داشت، پیام را از صف برداشته و ارسال می‌کند. این معماری تضمین می‌کند که کند شدن یک بخش از سیستم، باعث توقف کل برنامه نشود و سیستم بتواند فشارهای ناگهانی کاربران را تحمل کند. 18- کانتینرها و ارکستراسیون - Containers & Container orchestrationکانتینرها مانند Docker فناوری‌هایی هستند که کد برنامه و تمام پیش‌نیازهای اجرایی آن را در یک بسته مستقل، سبک و قابل حمل قرار می‌دهند. کانتینرها مشکل معروف این برنامه روی کامپیوتر من کار می‌کند اما روی سرور خراب می‌شود را برای همیشه حل میکنند. اما وقتی یک برنامه بزرگ می‌شود و تعداد این کانتینرها به صدها عدد می‌رسد، مدیریت دستی آن‌ها غیرممکن است.اینجاست که ابزارهای ارکستراسیون مثل Kubernetes وارد عمل می‌شوند. کوبرنتیز مانند یک رهبر ارکستر عمل می‌کند؛ مراقب است کانتینرهای خراب را ری‌استارت کند، ترافیک را بین آن‌ها تقسیم کند و در ساعات شلوغی، تعداد آن‌ها را به صورت خودکار افزایش دهد. 19- معماری چندمستاجره - Multi-Tenancy Architectureمعماری چندمستاجره یا همان Multi-Tenancy مدلی است که در آن یک نسخه واحد از نرم‌افزار روی سرور اجرا می‌شود، اما همزمان به چندین مشتری یا سازمان مختلف یا به اصطلاح مستاجرها، خدمات مستقل می‌دهد.اکثر سیستم‌های نرم‌افزار به عنوان سرویس (SaaS) مثل جی‌میل، ترلو یا سرویس‌های حسابداری آنلاین ابری، از این مدل استفاده می‌کنند.در این معماری، به جای اختصاص دادن یک دیتابیس و سرور مجزا به هر مشتری، همه از یک زیرساخت مشترک قدرت می‌گیرند، اما داده‌های هر سازمان از طریق شناسه‌های خاص کاملاً ایزوله و امن می‌ماند. این رویکرد به‌روزرسانی سیستم را به شدت آسان کرده و هزینه‌های زیرساختی ارائه‌دهنده خدمات را به طرز چشمگیری کاهش می‌دهد. 20- مهاجرت داده‌ها - Data Migrationدر واقع به فرآیند حساس و پیچیده انتقال اطلاعات از یک سیستم، دیتابیس یا فضای ذخیره‌سازی قدیمی به یک زیرساخت جدید، مهاجرت داده‌ها گفته می‌شود. این اتفاق معمولاً زمانی رخ می‌دهد که یک شرکت قصد دارد نرم‌افزارهای فرسوده خود را به‌روز کند یا سرورهای فیزیکی خود را به فضاهای ابری مدرن منتقل کند.با اینکه مفهوم آن ساده به نظر می‌رسد، اما Data Migration یکی از پرریسک‌ترین عملیات‌های فناوری اطلاعات است. مسائلی مانند تغییر فرمت داده‌ها در حین انتقال، حفظ جامعیت و امنیت اطلاعات، و جلوگیری از قطع شدن دسترسی کاربران به سیستم در طول فرآیند، نیازمند برنامه‌ریزی بسیار دقیق، بک‌آپ‌گیری‌های چندلایه و تست‌های مکرر پیش از اجرای نهایی است.  منابع و مراجع1-     مقالات آموزشی وب‌سایت GeeksforGeeks:آشنایی با درگاه API  (API Gateway)معرفی کانتینرها و داکر (Containers & Docker)آشنایی با صف پیام (Message Queues)معماری بدون سرور (Serverless Architecture)2-     مستندات معماری مایکروسافت و آمازون:الگوی بک‌اند برای فرانت‌اند (BFF) - مستندات مایکروسافت.الگوی جداسازی مسئولیت خواندن و نوشتن (CQRS) - مستندات مایکروسافتالگوی منبع‌سنجی رویداد (Event Sourcing) - مستندات مایکروسافتمعماری رویدادمحور (Event-Driven Architecture) - مستندات آمازون (AWS)3-     مقالات IBM و Red Hat:زیرساخت به عنوان کد (IaC) - مقالات آموزشی Red Hatعملیات یادگیری ماشین (MLOps) - مقالات آموزشی IBMمعماری چندمستاجره (Multi-Tenancy) - مقالات آموزشی IBM4-     دانشنامه ویکی‌پدیا Wikipedia:مهندسی آشوب (Chaos Engineering)طراحی دامنه‌محور (Domain-Driven Design)معماری شش‌ضلعی (Hexagonal Architecture)5-     گفتگو با ابزارهای هوش مصنوعی:Google Gemini: برای خلاصه‌سازی مقالات تخصصی، درک تفاوت‌های ظریف بین مفاهیمی مانند AI4SE و SE4AI.ChatGPT: برای همفکری جهت پیدا کردن مثال‌های ملموس و دنیای واقعی مانند تشبیه مهندسی آشوب به واکسن یا مثال هتل برای درگاه API.سید علی سادات خراسانیسید علی سادات خراسانیMon, 25 May 2026 13:10:21 +0330https://virgool.ir/@alikhorasani2002/بررسی-و-تحلیل-معیارهای-مرکزیت-برای-شناسایی-افراد-مهم-در-شبکه-های-پیچیده-ou6pklnofbecگزارش نهایی مقاله درس شبکه‌های پیچیده و پویارشته‌ مهندسی کامپيوتر گرايش نرم‌افزار  عنوانبررسی و تحلیل معیارهای مرکزیت برای شناسایی افراد مهم در شبکه‌های پیچیدهاستاد:دکتر علی‌اکبری پژوهشگر:سیدعلی سادات خراسانی بهمن 1404چکيده:شناسایی گره‌های تأثیرگذار و حیاتی در شبکه‌های پیچیده، یکی از چالش‌برانگیزترین مسائل در علم شبکه است که کاربردهای گسترده‌ای از مدیریت جریان اطلاعات تا کنترل شیوع بیماری‌ها دارد. ادبیات کلاسیک این حوزه، با محوریت پژوهش‌های فریمن، مرکزیت را عمدتاً بر اساس ویژگی‌های ساختاری محلی و ایستا مثل درجه، بینابینی و نزدیکی تعریف کرده است. این معیارها فرض می‌کنند که ارزش تمام اتصالات یکسان است. پس از آن بوناسیچ با نقد این دیدگاه، مدل‌های بازگشتی را معرفی کرد که در آن قدرت یک گره تابعی از قدرت همسایگانش است و با پارامتر β، ماهیت تعاملات مثل همکاری یا رقابت را مدل‌سازی می‌کند. این رویکرد بعدها در الگوریتم PageRank برای رتبه‌بندی صفحات وب با استفاده از مدل گردشگر تصادفی توسعه یافت. علیرغم این پیشرفت‌ها، یک چالش بنیادین باقی مانده است، اکثر معیارهای سنتی، شبکه را ساختاری همگن درنظر می‌گیرند و از ساختارهای مزوسکوپیک مثل انجمن‌های همپوشان غافل هستند. پژوهش حاضر با مرور انتقادی سیر تحول معیارهای مرکزیت، نشان می‌دهد که نادیده گرفتن ساختار انجمنی منجر به خطای قابل‌توجه در شناسایی گره‌های پل‌زننده و رهبران محلی می‌شود. در نهایت، این مقاله یک چارچوب پیشنهادی نوین را ارائه می‌دهد که با ترکیب منطق بازگشتی بوناسیچ و مفهوم مرکزیت ماژولار، نفوذ گره‌ها را در دو سطح محلی و جهانی تفکیک کرده و دقت تحلیل را در شبکه‌های واقعی بهبود می‌بخشد.واژگان کليدي: شبکه‌های پیچیده، مرکزیت، بوناسیچ، PageRank، ساختار انجمنی، نفوذ محلی و جهانی. فهرست مطالبفصل اول مقدمه. 71-1- بیان مسئله و اهمیت موضوع. 71-2 – سیر تحول تاریخی.. 71-3 -ظهور مدل‌های بازگشتی و مبتنی بر جریان. 81-4 -چالش ساختارهای انجمنی همپوشان. 81-5 -نوآوری و ساختار مقاله. 9فصل دوم مبانی نظری و مرور ادبیات.. 102-1- مقدمه. 102-2- شفاف‌سازی مفهومی فریمن.. 102-3- خانواده معیارهای بوناسیچ. 122-4- پیج‌رنک: انقلابی در گراف‌های جهت‌دار وب.. 12فصل سوم چالش ساختار انجمنی.. 133-1- مقدمه. 143-2- کوری ساختاری در معیارهای کلاسیک... 143-3- چالش انجمن‌های همپوشان. 153-4- نارسایی معیارهای جهانی در شبکه‌های پویا 153-5- تفکیک نفوذ محلی و جهانی.. 16فصل چهارم روش پیشنهادی.. 174-1- مقدمه. 174-2- مدلسازی ریاضی فضا و تعاریف پایه. 174-3- تجزیه بردار نفوذ محلی.. 184-4- تجزیه بردار نفوذ جهانی.. 184-5- تلفیق بازگشتی.. 194-5-1- تشریح اجزاء و پارامترها 194-6- تحلیل همگرایی و پیچیدگی الگوریتم. 204-6-1- پیچیدگی زمانی.. 204-7- مقایسه کیفی با روش‌های پیشین.. 21فصل پنجم روش تحلیل و آزمایش... 225-1- مقدمه. 225-2- مجموعه داده مورد استفاده 225-3- سناریوی مقایسه و نتایج مورد انتظار 225-3-1- تحلیل تطبیقی.. 235-4- تحلیل نتایج حاصل از اجرا 235-5- تحلیل حساسیت پارامتر α. 25فصل ششم روش نتیجه‌گیری و پیشنهادات.. 266-1- مقدمه. 266-2- محدودیت‌ها و مسیرهای پژوهشی آینده 26فصل هفتم منابع. 28فصل اولمقدمه1-1-    بیان مسئله و اهمیت موضوعشبکه‌های پیچیده، زبان مشترک بسیاری از سیستم‌های طبیعی و مصنوعی هستند؛ از شبکه‌های تعاملات پروتئینی و عصبی گرفته تا زیرساخت‌های اینترنت و شبکه‌های اجتماعی آنلاین. در تحلیل این گراف‌های عظیم، یکی از بنیادی‌ترین سوالات، شناسایی مهم‌ترین گره‌است. پاسخ به این پرسش که کدام گره مرکزی است، بسته به کاربرد متفاوت است. در یک شبکه مخابراتی، مرکزی‌ترین گره ممکن است گره‌ای باشد که بیشترین ترافیک را عبور می‌دهد، در حالی که در یک شبکه اجتماعی، فردی مرکزی است که بیشترین نفوذ کلام را دارد. با این حال، فقدان یک تعریف واحد و جامع از مرکزیت، همواره چالش‌برانگیز بوده است. همان‌طور که فریمن اشاره می‌کند، ابهام در مفهوم مرکزیت منجر به ارائه شاخص‌های متعددی شده که گاهی نتایج متناقضی تولید می‌کنند. 1-2 – سیر تحول تاریخیتلاش‌های اولیه برای کمی‌سازی اهمیت گره‌ها، با دسته‌بندی کلاسیک لینتون فریمن در سال ۱۹۷۹ به بلوغ رسید. او نشان داد که مرکزیت یک مفهوم سه‌وجهی است:1.     مرکزیت درجه: نشان‌دهنده فعالیت ارتباطی است.2.     مرکزیت بینابینی: بر پتانسیل کنترل جریان اطلاعات دلالت دارد.3.     مرکزیت نزدیکی: که شاخصی از استقلال و کارایی دسترسی است. این معیارها، اگرچه بنیادین هستند، اما از یک ضعف بزرگ رنج می‌برند و آنهم این است که آن‌ها کور محتوا[1] هستند و فرض می‌کنند اتصال به یک گره مهم، تفاوتی با اتصال به یک گره حاشیه‌ای ندارد.1-3 -ظهور مدل‌های بازگشتی و مبتنی بر جریانبرای رفع نقص مدل‌های قبلی، فیلیپ بوناسیچ در سال ۱۹۸۷ یک تغییر پارادایم ایجاد کرد. او استدلال کرد که مرکزیت یک ویژگی مطلق نیست، بلکه حاصل تعاملات بازگشتی در شبکه است. در مدل او، مرکزیت هر گره متناسب با مجموع مرکزیت همسایگانش است. بوناسیچ با معرفی پارامتر β نشان داد که در شبکه‌های مبادله‌ای، قدرت ناشی از اتصال به افراد ضعیف و وابسته است (β < 0)، در حالی که در شبکه‌های ارتباطی، اتصال به افراد قدرتمند باعث افزایش نفوذ می‌شود (β > 0).این دیدگاه بازگشتی، پایه و اساس انقلاب موتورهای جستجو در دهه ۹۰ میلادی شد. سرگی برین و لری پیج با معرفی الگوریتم PageRank، ایده بوناسیچ را برای گراف جهت‌دار وب توسعه دادند. آن‌ها با مدل‌سازی رفتار یک گردشگر تصادفی[2] و حل مشکل بن‌بست‌های گراف از طریق بردار منبع E، معیاری ارائه دادند که اهمیت جهانی یک صفحه را بر اساس کیفیت لینک‌های ورودی می‌سنجید، نه صرفاً تعداد آن‌ها. 1-4 -چالش ساختارهای انجمنی همپوشانعلیرغم تکامل معیارهای قبل، اکثر پژوهش‌های کلاسیک شبکه را به صورت یک ساختار یکپارچه و بدون مرز در نظر می‌گیرند. اما مطالعات مدرن نشان می‌دهد که شبکه‌های واقعی دارای ساختار مزوسکوپیک[3] نظیر انجمن‌ها هستند. نکته مهم‌تر آن است که در بسیاری از شبکه‌های اجتماعی و زیستی، این انجمن‌ها همپوشان هستند؛ یعنی یک گره می‌تواند همزمان عضو چندین گروه باشد. مثل فردی که همزمان در شبکه خانواده، همکاران و دوستان خودش عضویت دارد.معیارهای کلاسیک مثل PageRank و بینابینی امکان تفکیک نقش گره‌ها در این لایه‌های مختلف را ندارند. آن‌ها نمی‌توانند تمایز قائل شوند میان یک رهبر محلی که فقط در انجمن خودش نفوذ دارد و یک پل جهانی که انجمن‌های مختلف را به هم وصل می‌کند. غلمان و همکاران در سال ۲۰۱۹ نشان دادند که نادیده گرفتن این ساختار، منجر به درک ناقص از داینامیک شبکه می‌شود و پیشنهاد دادند که مرکزیت باید ترکیبی از نفوذ محلی و نفوذ جهانی باشد. 1-5 -نوآوری و ساختار مقالهاین مقاله تلاش می‌کند تا شکاف میان مدل‌های بازگشتی و مدل‌های مبتنی بر انجمن را پر کند. فرضیه اصلی ما این است که با وزن‌دهی به معیارهای ماژولار بر اساس منطق بازگشتی، می‌توان دقت شناسایی گره‌های حیاتی را افزایش داد. ساختار مقاله بدین شرح است: بخش دوم به مرور عمیق ادبیات و فرمول‌بندی ریاضی معیارهای کلاسیک می‌پردازد. بخش سوم، چالش‌های ساختار انجمنی را تشریح می‌کند. بخش چهارم، روش پیشنهادی و فرمولاسیون نوین ما را ارائه می‌دهد و بخش پنجم به نتیجه‌گیری اختصاص دارد.فصل دوممبانی نظری و مرور ادبیات2-1- مقدمهتحلیل مرکزیت در شبکه‌های پیچیده، مسیری طولانی را از تحلیل‌های جامعه‌شناختی گروه‌های کوچک تا الگوریتم‌های عظیم وب پیموده است. در این بخش، سه جریان اصلی فکری که زیربنای مدل پیشنهادی ما هستند، با جزئیات دقیق بررسی می‌شوند.2-2- شفاف‌سازی مفهومی فریمنلینتون فریمن در مقاله مرجع خود با عنوان (مرکزیت در شبکه‌های اجتماعی: شفاف‌سازی مفهومی)، به آشفتگی موجود در ادبیات آن زمان پایان داد. او با استفاده از گراف ستاره به عنوان نقطه مرجع، استدلال کرد که هر معیار معتبر مرکزیت باید برای گره مرکزی یک گراف ستاره، بیشترین مقدار ممکن را تولید کند. فریمن سه مفهوم متمایز را تفکیک کرد[1]:الف) مرکزیت درجه: فعالیت و قابلیت رویتاین معیار بر پایه ایده فعالیت ارتباطی[1] بنا شده است. گره‌هایی که درجه بالایی دارند، احتمالاً در کانون اتفاقات هستند.برای یک گراف با مشخصات G = (V , E) با n گره، درجه گره pk برابر است با تعداد یال‌های متصل به آن:این شاخص برای سنجش محبوبیت یا پتانسیل جذب جریان‌های تصادفی در شبکه بسیار کارآمد است، اما از درک ساختار کلی شبکه ناتوان است.ب) مرکزیت بینابینی: کنترل و دروازه‌بانیفریمن استدلال کرد که جریان اطلاعات همیشه از مسیرهای مستقیم عبور نمی‌کند. گره‌ای که بین گره‌های دیگر قرار گرفته، پتانسیل کنترل یا قطع جریان را دارد. اگر gij تعداد کل کوتاه‌ترین مسیرها بین گره i و j باشد و gij(pk) تعداد آن مسیرهایی باشد که دقیقاً از گره pk عبور می‌کنند، احتمال اینکه گره k واسطه ارتباط آن دو باشد، برابر است با  مرکزیت بینابینی گره k مجموع این احتمالات برای تمام جفت‌گره‌هاست: ماکزیمم مقدار ممکن برای این شاخص در یک گراف ستاره رخ می‌دهد که برابر است با  بنابراین فرمول نرمال شده آن عبارت است از: این معیار در شناسایی نقاط شکست[2] و گلوگاه‌های شبکه بسیار حیاتی است. ب) مرکزیت نزدیکی: استقلال و کاراییسومین مفهوم، به حداقل رساندن فاصله تا دیگران است. گره‌ای که به بقیه نزدیک است، مستقل است زیرا برای ارسال پیام به واسطه‌های کمتری نیاز دارد. سابیدوسی (۱۹۶۶) این مفهوم را با دوری تعریف کرد که مجموع فواصل ژئودزیک است: همچنین برای مقایسه بین شبکه‌ها، فریمن فرمول زیر را ارایه داد: این شاخص نشان‌دهنده سرعت انتشار اطلاعات از یک گره به کل شبکه است. 2-3- خانواده معیارهای بوناسیچفیلیپ بوناسیچ با نقد رویکرد فریمن، بیان کرد که در نظر گرفتن تنها ساختار محلی کافی نیست. او استدلال کرد که قدرت و مرکزیت دو روی یک سکه هستند و قدرت یک فرد وابسته به قدرت کسانی است که با آن‌ها در ارتباط است. مدل بوناسیچ بر مبنای یک تعریف بازگشتی است. که در آن  یک فاکتور مقیاس‌دهی است و  پارامتر وزن‌دهی به مرکزیت همسایگان است. این رابطه را می‌توان به صورت ماتریسی بازنویسی کرد که منجر به یک معادله جبری خطی می‌شود: که در اینجا R ماتریس مجاورت و I ماتریس همانی است.تحلیل پارامتر :بوناسیچ نشان داد که علامت و اندازه  تفسیر قدرت را تغییر می‌دهد [2]:1.    شبکه‌های ارتباطی (  > 0): در اینجا، اتصال به افراد قدرتمند باعث افزایش قدرت می‌شود. این مدل با مفهوم وضعیت (Status) سازگار است. هرچه همسایگان شما مرکزی‌تر باشند، شما نیز مرکزی‌تر خواهید بود.2.    شبکه‌های مبادله‌ای (  < 0): بر اساس تئوری مبادله کوک (1983)، قدرت در چانه‌زنی ناشی از وابستگی دیگران است. اگر شما به گره‌هایی متصل باشید که ارتباطات کمی دارند، قدرت شما افزایش می‌یابد. بنابراین، داشتن همسایگان ضعیف با درجه پایین باعث افزایش قدرت شما می‌شود.این مدل نشان داد که مرکزیت یک ویژگی مطلق نیست، بلکه تابعی از دینامیک حاکم بر شبکه است.  2-4- پیج‌رنک: انقلابی در گراف‌های جهت‌دار وبدر اواخر دهه ۹۰، پیج و برین الگوریتم PageRank را برای حل مشکل رتبه‌بندی در وب ارائه دادند. این الگوریتم در واقع بسطی از ایده مرکزیت بردار ویژه [3]بود، اما با یک نوآوری حیاتی برای مدیریت گراف‌های جهت‌دار و گسسته. فرمول پایه مشابه بوناسیچ با استفاده از معیار    > 0 بود: اما این مدل در مواجهه با دو پدیده وب شکست می‌خورد:Rank Sinks: صفحاتی که لینک ورودی دارند اما لینک خروجی ندارند یا به خودشان لینک می‌دهند، باعث می‌شوند امتیاز در آن‌ها انباشته شود.گراف‌های ناهمبند: وب یک گراف یکپارچه نیست.راه‌حل: مدل گردشگر تصادفی[4]پیج‌رنک فرض می‌کند کاربر با احتمال d روی لینک‌ها کلیک می‌کند و با احتمال 1-d خسته شده و به صورت تصادفی به یک صفحه دیگر می‌پرد که  به آن Teleportation می‌گویند بنابراین فرمول اصلاح شده آن عبارت است از [3]: معمولاً 0.85 = dدر نظر گرفته می‌شود. از دیدگاه جبر خطی، بردارPageRank بردار ویژه اصلی ماتریس انتقال احتمالاتی[5] شبکه است. این مدل توانست با موفقیت مفهوم کیفیت لینک را کمی‌سازی کند؛ لینکی که از یک صفحه معتبر مثلYahoo می‌آید، وزن بسیار بیشتری نسبت به لینکی از یک صفحه شخصی دارد. فصل سومچالش ساختار انجمنی3-1- مقدمهدر بخش‌های پیشین، سیر تکامل معیارهای مرکزیت از شاخص‌های توپولوژیک محلی فریمن به مدل‌های طیفی و بازگشتی بوناسیچ و PageRank بررسی شدند. با این حال، یک نقد بنیادین بر تمامی این رویکردها وارد است و آنهم فرض همگنی ساختاری[1] است. در این بخش، با استناد به یافته‌های اخیر غلمان و همکاران، نشان می‌دهیم که چگونه نادیده گرفتن ساختارهای مزوسکوپیک و پدیده‌ی همپوشانی انجمن‌ها، اعتبار معیارهای کلاسیک را در شبکه‌های پیچیده واقعی زیر سوال می‌برد. 3-2- کوری ساختاری در معیارهای کلاسیکمعیارهای سنتی مرکزیت، شبکه را به صورت یک توده یکپارچه و مسطح می‌بینند. در این دیدگاه، یک یال تنها یک یال است و تفاوت کیفی میان یال‌های مختلف قائل نمی‌شوند. اما در واقعیت، شبکه‌های پیچیده نظیر شبکه‌های اجتماعی، استنادی و بیولوژیک دارای ساختار انجمنی هستند؛ یعنی نواحی متراکمی که در آن‌ها گره‌ها اتصالات داخلی فراوانی دارند، در حالی که اتصالات بین این نواحی یعنی یال‌های میان‌بر اندک است [4].این کوری ساختاری منجر به خطای سیستماتیک در ارزیابی اهمیت گره‌ها می‌شود. برای تشریح این خطا، دو نوع گره متمایز را در نظر بگیرید:هاب‌های استانی: گره‌هایی که درجه بالایی دارند اما تمام اتصالاتشان محدود به یک انجمن خاص است. این گره‌ها در حفظ انسجام داخلی گروه خود حیاتی هستند اما در انتشار سراسری اطلاعات[2] نقش محدودی دارند.پل‌های ارتباطی: گره‌هایی که ممکن است درجه کمتری داشته باشند، اما اتصالاتشان بین چندین انجمن مختلف توزیع شده است.معیارهای کلاسیک نظیر PageRank یا بردار ویژه، تمایل دارند امتیاز را در نواحی متراکم شبکه هاب‌های استانی انباشته کنند و اغلب ارزش استراتژیک پل‌های ارتباطی را نادیده می‌گیرند. غلمان نشان می‌دهد که در فرآیندهای انتشار اپیدمی یا شایعه، گره‌های پل‌زننده حتی با درجه پایین بسیار خطرناک‌تر و مؤثرتر از هاب‌های ایزوله هستند، زیرا دسترسی سریع به بخش‌های بکر شبکه را فراهم می‌کنند. معیارهای کلاسیک قادر به تمایز میان این دو نقش نیستند [4]. 3-3- چالش انجمن‌های همپوشانپیچیدگی مسئله فراتر از وجود انجمن‌های مجزاست. در اکثر شبکه‌های اجتماعی واقعی، انجمن‌ها دارای مرزهای صلب نیستند، بلکه همپوشان[3] هستند. یک کاربر در توییتر یا فیس‌بوک، همزمان عضو کلاستر همکاران، دوستان دوران تحصیل و علاقه‌مندان به تکنولوژی است. غلمان و همکاران استدلال می‌کنند که معیارهای سنتی که برای هر گره تنها یک عدد اسکالر مثل یک عدد PageRank تولید می‌کنند، ذاتاً برای توصیف این واقعیت چندبعدی ناتوان هستند. وقتی یک گره عضو k انجمن مختلف است، نفوذ او ماهیت برداری پیدا می‌کند. یک گره ممکن است در انجمن A یک رهبر فکری باشد و دارای نفوذ محلی بالا باشد، اما در انجمن B تنها یک عضو حاشیه‌ای باشد. مدل‌های تک‌بعدی[4] با میانگین‌گیری از این نقش‌ها، اطلاعات حیاتی درباره موقعیت استراتژیک گره را از بین می‌برند. 3-4- نارسایی معیارهای جهانی در شبکه‌های پویایکی دیگر از ابعاد نقد ما، مسئله پویایی است. در شبکه‌های پویا که یال‌ها مدام اضافه یا حذف می‌شوند، تأثیر یک تغییر توپولوژیک بر مرکزیت گره‌ها یکسان نیست.اضافه شدن یک یال در داخل یک انجمن متراکم، تأثیر کمی بر ساختار کلان شبکه و طول مسیرها دارد.اما اضافه شدن یک یال میان دو انجمن جدا افتاده، می‌تواند قطر شبکه را به شدت کاهش دهد و الگوی جریان اطلاعات را دگرگون کند.معیارهای کلاسیک مثل Closeness یا PageRank که کل گراف را یک ماتریس واحد می‌بینند، برای به‌روزرسانی نیاز به محاسبات سنگین دارند و نمی‌توانند به سرعت تشخیص دهند که آیا یال جدید یک لینک محلی است یا یک لینک جهانی. این عدم تفکیک پذیری باعث می‌شود در کاربردهای Real-time، شناسایی تغییرات ناگهانی در ساختار قدرت با تأخیر یا خطا همراه باشد. 3-5- تفکیک نفوذ محلی و جهانیبا توجه به نقد‌های فوق، این مقاله همگام با پژوهش‌های غلمان، پیشنهاد می‌کند که مفهوم مرکزیت باید از یک کمیت اسکالر به یک مفهوم دو‌بعدی ارتقا یابد. ما نیازمند چارچوبی هستیم که بتواند برای هر گره u، دو مؤلفه متعامد را محاسبه کند:نفوذ محلی (CL – Local Influence): معیاری که نشان دهد گره u چقدر در داخل انجمن‌های خودش (یک یا چند انجمن) محوریت دارد. این معیار باید نسبت به اندازه انجمن نرمال‌سازی شود تا انجمن‌های بزرگ‌تر به طور ناعادلانه بر انجمن‌های کوچک‌تر سایه نندازند.نفوذ جهانی (CG – Global Influence): معیاری که بر اساس تنوع[5] اتصالات سنجیده می‌شود. این شاخص نباید صرفاً تعداد لینک‌های بیرونی را بشمارد، بلکه باید بسنجد که این لینک‌ها چقدر در سطح شبکه پخش شده‌اند.این تفکیک مفهومی، زیربنای مدل پیشنهادی ما در بخش بعدی است؛ جایی که ما فرمولاسیون ریاضی دقیق این دو مؤلفه را با منطق بازگشتی بوناسیچ ترکیب می‌کنیم تا معیاری ارائه دهیم که هم به ساختار انجمنی حساس باشد و هم پویایی قدرت را لحاظ کند.  فصل چهارمروش پیشنهادی4-1- مقدمهدر بخش‌های پیشین، نشان دادیم که معیارهای کلاسیک مثل درجه، بینابینی و غیره، به دلیل نادیده گرفتن ساختار انجمنی، و معیارهای ماژولار موجود مثل کارهای اولیه غلمان به دلیل نادیده گرفتن ماهیت بازگشتی قدرت، دارای نقص هستند. در این بخش، ما یک مدل ریاضی نوین با عنوان مرکزیت ماژولار بازگشتی پویا (Dynamic Recursive Modular Centrality - DRMC) را توسعه می‌دهیم. این مدل بر مبنای یک فرضیه اصلی بنا شده است و آنهم این است که اهمیت یک گره، حاصل‌ضرب موقعیت استراتژیک آن در ساختار انجمنی (توپولوژی) و کیفیت همسایگان آن (جریان) است.در ادامه، اجزای این مدل را به صورت گام‌به‌گام فرمول‌بندی می‌کنیم. 4-2- مدلسازی ریاضی فضا و تعاریف پایهفرض کنید شبکه مورد مطالعه به صورت گراف G = (V, E) مدل‌سازی شود که در آن V مجموعه شامل N گره و E مجموعه شامل M یال است. ماتریس مجاورت شبکه را با A نشان می‌دهیم که در آن Aij=1 اگر ارتباطی وجود داشته باشد و در غیر این صورت صفر است.برخلاف رویکردهای سنتی که یک افراز[1] سخت برای شبکه در نظر می‌گیرند، ما فرض می‌کنیم شبکه دارای K انجمن همپوشان   است. برای مدل‌سازی ریاضی این همپوشانی، برای هر گره u یک بردار عضویت به شکل زیر تعریف می‌کنیم:  4-3- تجزیه بردار نفوذ محلینخستین مؤلفه مدل پیشنهادی، سنجیدن قدرت گره در قلمرو خودی است. ما این مؤلفه را  می‌نامیم. چالش اصلی در اینجا، تفاوت اندازه انجمن‌هاست. یک گره با ۵ اتصال در یک انجمن ۶ نفره، قدرتمندتر از یک گره با ۵ اتصال در یک انجمن ۱۰۰ نفره است. معیارهای کلاسیک این تفاوت نسبی را درک نمی‌کنند.برای حل این مشکل، ما از فرمول درجه نرمال‌سازی شده درون‌انجمنی استفاده می‌کنیم که مستقیماً از منطق غلمان استخراج شده اما برای مدیریت همپوشانی تعمیم یافته است:تحلیل فرمول:عبارت  نشان می‌دهد گره u چه کسری از همسایگان ممکن در انجمن c را تسخیر کرده است و به آن چگالی اتصال می‌گویند.عبارت  نشان می‌دهد از آنجا که گره ممکن است در چندین انجمن عضو باشد، ما میانگین نفوذ او را در تمام انجمن‌هایش محاسبه می‌کنیم.بنابراین اگر  به عدد 1 میل کند، گره u یک هاب استانی مطلق است که تمام اعضای گروه‌هایش را می‌شناسد و رهبری می‌کند و در همه انجمن‌هایش مهم‌ترین گره است. 4-4- تجزیه بردار نفوذ جهانیدومین مؤلفه یعنی ، نشان‌دهنده توانایی گره در ایفای نقش پل ارتباطی بین کلاسترهای متفاوت است. گره‌هایی که این ویژگی را دارند، گلوگاه‌های انتقال اطلاعات هستند. معیارهایی مثل Betweenness برای محاسبه این ویژگی بسیار پرهزینه هستند و از پیچیدگی  هستند.بنابراین ما برای محاسبه سریع و کارآمد نفوذ جهانی، از مفهوم آنتروپی اتصالات یا ضریب مشارکت[2] استفاده می‌کنیم. این شاخص بر اساس تنوع سیمپسون[3] طراحی شده است:   اثبات رفتار ریاضی:حالت ایزوله: اگر تمام اتصالات گره u فقط در یک انجمن باشد (مثلاً c = 1)، آنگاه مقدار کسر برابر ۱ شده و  این یعنی گره هیچ نفوذ جهانی ندارد.حالت پل ایده‌آل: اگر اتصالات گره u به طور مساوی بین K انجمن توزیع شده باشد، مقدار داخل سیگما مینیمم شده و  به مقدار حداکثر خود یعنی  نزدیک می‌شود.این فرمول تضمین می‌کند که ما گره‌هایی را که صرفاً لینک‌های بیرونی زیادی دارند اما همه به یک انجمن خاص می‌روند با گره‌هایی که واقعاً به انجمن‌های متنوع متصل‌اند، اشتباه نگیریم. 4-5- تلفیق بازگشتیتا این مرحله ما 2 بردار ایستا ( CL و CG) را داریم. نوآوری اصلی استفاده شده این مقاله این است که طبق استدلال ما: یک پل ارتباطی تنها زمانی ارزشمند است که به گره‌های با ارزش دیگری متصل باشد.این منطق، ما را به سمت استفاده از مدل بازگشتی بوناسیچ و PageRank سوق می‌دهد. ما مدل خطی غلمان را به یک مدل غیرخطی و تکراری تبدیل می‌کنیم. فرض کنیم   امتیاز مرکزیت گره u در تکرار tام باشد. فرمول پیشنهادی ما عبارت است از: 4-5-1- تشریح اجزاء و پارامترها1.    ارزش ذاتی: بخش اول فرمول یعنی  نشان‌دهنده قدرتی است که گره به تنهایی و به واسطه جایگاهش در انجمن دارد. این مقدار ثابت است و تضمین می‌کند که حتی اگر گره به همسایگان ضعیفی متصل باشد، به دلیل رهبری محلی‌اش، امتیاز صفر نگیرد.2.     ارزش اکتسابی: بخش دوم، قدرت جریان‌یافته از سمت شبکه است.·      ما مجموع امتیاز همسایگان یعنی  را محاسبه می‌کنیم مثل PageRank.·      ضریب فیلترینگ: نکته مهم اینجاست که ما این مجموع را در  ضرب می‌کنیم. این یعنی گره u تنها به اندازه‌ای می‌تواند از قدرت همسایگانش بهره‌مند شود که توانایی توزیع جهانی داشته باشد. یک گره با  (کاملاً محلی)، هیچ قدرتی از شبکه جهانی دریافت نمی‌کند و فقط به قدرت محلی خود متکی است.3.   پارامتر تنظیم (α): ضریب  نقش یک نوار لغزنده را بازی می‌کند:اگر α به 0 میل کند آنگاه مدل بر حفظ انسجام انجمن‌ها و رهبران محلی تمرکز می‌کند.اگر α به 1 میل کند آنگاه مدل بر جریان اطلاعات و پل‌های میان‌گروهی تمرکز می‌کند. 4-6- تحلیل همگرایی و پیچیدگی الگوریتمیرای پیاده‌سازی این مدل، ما از روش Power Iteration Method استفاده می‌کنیم. این فرمول را می‌توان به صورت ماتریسی و به شکل زیر بازنویسی کرد: که در آن L بردار نفوذ محلی، G ماتریس قطری نفوذ جهانی و W ماتریس انتقال تصادفی است.4-6-1- پیچیدگی زمانی1.     محاسبه  و : با فرض استفاده از لیست مجاورت، پیچیدگی محاسبه این بخش برای هر گره برابر  و برای کل شبکه برابر O(M) است (که M برابر تعداد یال‌هاست).2.     حلقه تکرار: در هر تکرار، یک ضرب ماتریس- بردار اسپارس انجام می‌شود که هزینه آن O(M) است. اگر تعداد تکرارها برای همگرایی برابر T باشد، کل پیچیدگی برابر است با: از آنجا که T معمولاً عدد کوچکی است (حدود ۲۰ تا ۵۰ برای دقت بالا)، این الگوریتم بسیار سریع‌تر از روش‌هایی مثل Betweenness با پیچیدگی  است و قابلیت اجرا روی شبکه‌های عظیم را دارد.        4-7- مقایسه کیفی با روش‌های پیشینجدول زیر تمایز نظری روش پیشنهادی ما یعنی (DRMC) با روش‌های گفته شده را نشان می‌دهد:جدول 4-1: مقایسه روش‌های سابق و روش پیشنهادیویژگیمرکزیت درجهپیج رنکماژولار استاتیکDRMCدرک ساختار انجمتیخیرخیربلهبلههم‌پوشانی انجمن‌هاخیرخیربلهبلهاثر بازگشتی (قدرت همسایه)خیربلهخیربلهتفکیک محلی و جهانیخیرخیربلهبله این جدول به وضوح نشان می‌دهد که روش پیشنهادی، مدل ریاضی جامعی است که سعی کرده است تمام ویژگی‌های مثبت روش‌های قبلی را تجمیع کرده است.  فصل پنجمروش تحلیل و آزمایش5-1- مقدمهبرای ارزیابی کارایی چارچوب پیشنهادی (DRMC)، ما یک سناریوی تجربی را بر روی داده‌های استاندارد طراحی می‌کنیم تا نشان دهیم چگونه ترکیب ساختار انجمنی و منطق بازگشتی می‌تواند گره‌های پنهان اما حیاتی را آشکار سازد که روش‌های کلاسیک از دیدن آن‌ها عاجز هستند. 5-2- مجموعه داده مورد استفادهبه عنوان اثبات مفهوم، از شبکه اجتماعی باشگاه کاراته زاخاری[1] استفاده می‌شود. این شبکه شامل ۳۴ گره (اعضای باشگاه) و ۷۸ یال (ارتباطات دوستی) است.چرا این دیتاست؟ این شبکه دارای یک ساختار انجمنی ذاتی است که پس از اختلاف میان مربی (گره 0) و مدیر (گره ۳3)، باشگاه به دو گروه مجزا تقسیم می‌شود. این ویژگی به ما اجازه می‌دهد تا رفتار معیار DRMC را در شناسایی رهبران محلی و پل‌های ارتباطی بین دو گروه بررسی کنیم. 5-3- سناریوی مقایسه و نتایج مورد انتظارما سه معیار را بر روی این شبکه اعمال و ۱۰ گره برتر را استخراج می‌کنیم:1.     مرکزیت درجه: به عنوان نماینده روش‌های محلی سنتی.2.     پیج‌رنک: به عنوان نماینده روش‌های بازگشتی.3.     روش پیشنهادی (DRMC): با تنظیم پارامتر 0.5 = α تعادل میان نفوذ محلی و جهانی را برقرار می‌کند. 5-3-1- تحلیل تطبیقیتشخیص رهبران (Hubs): انتظار می‌رود که هر سه روش، گره‌ ۱ یعنی مربی و گره ۳۴ یعنی مدیر را به عنوان مهم‌ترین گره‌ها شناسایی کنند. این گره‌ها هم درجه بالا دارند و هم در مرکز انجمن‌های خود هستند. در اینجا  (نفوذ محلی) در فرمول ما نقش اصلی را بازی می‌کند.تشخیص پل‌های ارتباطی(Bridges) - :نقطه تمایز اصلی در گره‌هایی مانند گره ۹ یا گره ۲۰ ظاهر می‌شود. این گره‌ها ممکن است درجه بالایی نداشته باشند، اما نقش حیاتی در اتصال دو گروه دارند.شکست PageRank: پیج‌رنک ممکن است به این گره‌ها امتیاز متوسطی بدهد، چون جریان احتمالاتی در داخل کلاسترهای متراکم حبس می‌شود.موفقیت DRMC: در مدل پیشنهادی ما، این گره‌ها دارای نفوذ جهانی یعنی  بالایی هستند. فرمول بازگشتی ما، وزن همسایگان قدرتمند آن‌ها را در ضریب  ضرب می‌کند. بنابراین، گره‌ای که پلی میان دو رهبر قدرتمند باشد، جهش رتبه قابل توجهی در DRMC خواهد داشت که در روش‌های دیگر دیده نمی‌شود. 5-4- تحلیل نتایج حاصل از اجرابه منظور سنجش کارایی و اثربخشی چارچوب پیشنهادی مرکزیت ماژولار بازگشتی پویا و مقایسه آن با روش‌های کلاسیک، یک سناریوی آزمایشی بر روی مجموعه داده استاندارد باشگاه کاراته زاخاری طراحی شده است.در این آزمایش، ۱۰ گره برتر شبکه بر اساس سه معیار مرکزیت درجه، PageRank و DRMC با پارامتر 0.5 = α برای ایجاد تعادل رتبه‌بندی شده‌اند.نتایج کمی حاصل از این مقایسه در جدول زیر ارائه شده است:      جدول 5-1: مقایسه امتیازدهی روش‌های نامبرده شدهرتبهشناسه گرهمرکزیت درجهPageRankDRMCنفوذ محلینفوذ جهانی100.480.0880.0830.850.592330.510.0960.0800.870.30310.270.0570.0690.750.494320.360.0750.0620.680.15520.300.0620.0580.620.58630.180.0370.0560.620.27750.120.0330.0500.570.00860.120.0310.0500.570.009100.090.0200.0380.420.001040.090.0200.0380.420.00 همان‌طور که در جدول بالا مشاهده می‌شود، اگرچه همپوشانی کلی میان گره‌های برتر در سه روش وجود دارد، اما جابجایی‌های معناداری در رتبه‌بندی رخ داده است که برتری مدل DRMC را در شناسایی موقعیت‌های استراتژیک اثبات می‌کند.الف) تقابل کمیت و کیفیت (تحلیل گره ۳۳ در برابر گره ۰):مهم‌ترین یافته این آزمایش در دو ردیف اول جدول نهفته است.در دیدگاه کلاسیک معیارهای درجه و پیج‌رنک، گره ۳۳ (مدیر) را به عنوان مهم‌ترین گره شناسایی کرده‌اند (با درجه ۰.۵۱). دلیل این امر، تعداد بالای اتصالات مستقیم اوست. اما با نگاهی به ستون نفوذ جهانی درمی‌یابیم که نفوذ جهانی این گره تنها ۰.۳۰ است؛ به این معنا که اکثر اتصالات او محدود به انجمن خودش است و او نقش یک هاب محلی را بازی می‌کند.در دیدگاه پیشنهادی یعنی DRMC در مقابل، گره ۰ (مربی) اگرچه درجه کمتری دارد (۰.۴۸)، اما دارای نفوذ جهانی بسیار بالاتری ۰.۵۹ است. این یعنی اتصالات او بین انجمن‌های مختلف توزیع شده است. مدل پیشنهادی ما با تشخیص این ویژگی و اعمال اثر بازگشتی، گره ۰ را به رتبه نخست ارتقا داده است. این نتیجه نشان می‌دهد که DRMC برای گره‌هایی که نقش پل ارتباطی را دارند و جریان اطلاعات را بین گروه‌ها ممکن می‌سازند، ارزش بیشتری قائل است.  ب) شناسایی ظرفیت‌های پنهان (گره ۲):گره ۲ مثال بارز دیگری از دقت مدل است. این گره درجه نسبتاً پایینی دارد (۰.۳۰) و در پیج‌رنک نیز امتیاز متوسطی گرفته است. اما به دلیل اینکه نفوذ جهانی آن بسیار بالاست ۰.۵۸، مدل DRMC جایگاه آن را تثبیت کرده است. این نشان می‌دهد گره‌هایی که شاید مشهور نباشند (درجه پایین) اما بانفوذ هستند (اتصال‌دهنده گروه‌ها)، در مدل ما بهتر دیده می‌شوند.بنابراینآزمایش فوق نشان می‌دهد که چارچوب DRMC با موفقیت توانسته است بر ضعف اصلی پیج‌رنک یعنی گیر افتادن در تله‌های رتبه داخل انجمن‌ها غلبه کند و معیاری ترکیبی ارائه دهد که هم رهبران محلی و هم میانجی‌های جهانی را با دقت بالا شناسایی می‌کند. 5-5- تحلیل حساسیت پارامتر αیکی از ویژگی‌های برجسته مدل ما، قابلیت تنظیم‌پذیری با پارامتر α استدر کاربردهایی که هدف حفظ انسجام داخلی است مثل تیم‌سازی، مقدار α به 0 میل داده می‌شود تا وزن پارامتر CL بالا رود.در کاربردهایی که هدف انتشار سریع اطلاعات یا «یروس‌شناسی است، مقدار α به 1 میل داده می‌شود تا گره‌هایی با CG بالا که توانایی پخش بین گروه‌ها را دارند، در صدر لیست قرار گیرند.  فصل ششمروش نتیجه‌گیری و پیشنهادات6-1- مقدمهمسئله شناسایی گره‌های مرکزی در شبکه‌های پیچیده، همواره با چالش تعریف اهمیت روبرو بوده است. در این پژوهش، ما سیر تکاملی این مفهوم را از معیارهای ایستا و ساختار کور فریمن به سوی مدل‌های بازگشتی بوناسیچ و پیج‌رنک مرور کردیم. استدلال اصلی ما این بود که رویکردهای موجود، یا ساختار مزوسکوپیک انجمن‌ها را نادیده می‌گیرند و یا مانند کارهای اولیه در مرکزیت ماژولار از دینامیک بازگشتی جریان غافل‌اند.مقاله حاضر با معرفی چارچوب مرکزیت ماژولار بازگشتی پویا، یک راهکار ترکیبی ارائه داد. این مدل با تفکیک نفوذ گره به دو مؤلفه متعامد محلی و جهانی و تزریق آن‌ها در یک فرآیند تکراری مشابه PageRank، توانست:1.     ماهیت همپوشان انجمن‌ها را در فرمولاسیون ریاضی لحاظ کند.2.     گره‌هایی را شناسایی کند که شاید درجه بالایی نداشته باشند، اما به دلیل اتصال استراتژیک به انجمن‌های متنوع، شاه‌راه‌های جریان اطلاعات محسوب می‌شوند. 6-2- محدودیت‌ها و مسیرهای پژوهشی آیندهاگرچه مدل پیشنهادی گامی رو به جلو محسوب می‌شود، اما مسیرهای نویی را برای پژوهش‌های آینده می‌گشاید که با توجه به فایل موضوعات پیشنهادی، می‌توانند شامل موارد زیر باشند:یادگیری پارامتر α با هوش مصنوعی: در مدل فعلی، α یک عدد ثابت دستی است. در کارهای آتی می‌توان با استفاده از شبکه‌های عصبی گراف (GNN)، مقدار بهینه α را برای هر شبکه به صورت خودکار و بر اساس ویژگی‌های توپولوژیک یاد گرفت.شبکه‌های زمانی: فرمول فعلی برای شبکه‌های ایستا (یا اسنپ‌شات‌های ثابت) طراحی شده است. تعمیم این فرمول برای شبکه‌هایی که یال‌های آن دارای برچسب زمانی (t) هستند، می‌تواند پروژه‌ای چالش‌برانگیز و نوآورانه باشد.پیاده‌سازی مقیاس‌پذیر: برای گراف‌های میلیاردی (مثل وب یا توییتر)، محاسبه ضریب مشارکت می‌تواند پرهزینه باشد. استفاده از الگوریتم‌های تقریبی یا پردازش توزیع‌شده Spark GraphX برای پیاده‌سازی این مدل پیشنهاد می‌شود.                       فصل هفتممنابع[1] L. C. Freeman, "Centrality in social networks: Conceptual clarification," Social Networks, vol. 1, no. 3, pp. 215-239, 1979.[2] P. Bonacich, "Power and Centrality: A Family of Measures," American Journal of Sociology, vol. 92, no. 5, pp. 1170-1182, 1987.[3] L. Page, S. Brin, R. Motwani, and T. Winograd, "The PageRank Citation Ranking: Bringing Order to the Web," Technical Report, Stanford InfoLab, 1998.[4] Z. Ghalmane, C. Cherifi, H. Cherifi, and M. El Hassouni, "Centrality in Complex Networks with Overlapping Community Structure," Scientific Reports, vol. 9, no. 1, p. 10133, 2019.   سید علی سادات خراسانیسید علی سادات خراسانیMon, 09 Feb 2026 22:36:00 +0330