نوشته های سید محمد مهدی حسینی

مطالعه شبکه وابستگی در اقتصاد و چگونگی تاثیر آن بر اقتصاد کلان

سید محمد مهدی حسینی — Fri, 13 Feb 2026 21:10:24 +0330

چکیده:اقتصاد پدیده‌ای پویا، چندلایه و غیرخطی است که تبیین دقیق رفتار آن فراتر از متغیرهای کلان سنتی، نیازمند واکاوی ساختار شبکه‌ای و روابط پیچیده میان صنایع است. این پژوهش با هدف بررسی نقش پیوندهای ورودی–خروجی در انتشار متغیرهای اقتصادی مثل تورم، نشان می‌دهد که شوک‌های اقتصادی بسته به موقعیت توپولوژیک و نوع اتصالات هر بخش در شبکه، به‌صورت ناهمسان، تقویت‌شونده یا با تأخیر زمانی منتقل می‌شوند. اگرچه ریشه‌های این تحلیل در مدل‌های کلاسیک داده–ستانده لئونتیف نهفته است، اما محدودیت‌هایی نظیر فرض خطی‌بودن روابط و نادیده‌گرفتن پویایی رفتاری عوامل اقتصادی، ضرورت گذار به سمت تحلیل‌های پیشرفته شبکه‌ای را آشکار می‌سازد. یافته‌های حاصل از بررسی مدل‌های مدرن تایید می‌کند که شناسایی «صنایع گلوگاهی» و «هاب‌های استراتژیک» از طریق شاخص‌هایی نظیر مرکزیت بوناچیچ و آزمون‌های تنش، ابزاری حیاتی برای پیش‌بینی مسیرهای سرایت بحران و مدیریت تاب‌آوری اقتصادی فراهم می‌آورد. در نهایت، این مطالعه بر اهمیت بومی‌سازی ابزارهای تحلیل شبکه جهت درک عمیق پویایی‌های تورمی در ساختار اقتصادی کشور تأکید می‌کند.واژگان کلیدی: تورم، تحلیل شبکه‌های پیچیده، مدل داده–ستانده، تاب‌آوری اقتصادی، انتشار شوکمقدمه افزایش قیمت کالاها و خدمات یکی از چالش‌های اساسی اقتصادی در سال‌های اخیر بوده است. وقتی قیمت یک کالا تغییر می‌کند، این تغییر در میان سایر کالاها و بازارها «انتشار» می‌یابد و سرانجام به تورم کلی (شاخص قیمت مصرف‌کننده) یا شاخص قیمت کالاها منجر می‌شود. سوالی که این تحقیق به دنبال آن است که آِیا ارتباطی بین پدیده تورم و رفتار شبکه‌ای عوامل شکل‌دهنده آن وجود دارد و چگونه از طریق مفاهیم مربوط به شبکه‌های پیچیده می‌توان آن را تحلیل و ارزیابی نمود و در داخل کشور استفاده نمود. در این راستا و به منظور انجام این پژوهش ریزسوالات زیر مطرح گردید:1. آیا برای تحلیل تورم نیازمند تحلیل از طریق شبکه‌های پیچیده هستیم؟2. تاریخچه استفاده از شبکه‌های پیچیده در اقتصاد چیست؟3. شبکه های استفاده شده برای تحلیل تورم از چه ساختاری برخوردار هستند و چه مواردی را توضیح می‌دهند و چه مواردی را نمی‌توانند هنوز توضیح دهند؟4. چه مقالاتی در این زمینه منتشر شده‌اند و چه دستاوردهایی داشته‌اند؟اهمیت و ضرورت تحقیقبسیاری از متغیرهای اقتصادی در قالب فرمولها با متغیرهای ساده قابل تحلیل نیستند. در بسیاری از اقتصادها، «تورم را نمی‌توان صرفاً با چند متغیر کلان ساده مانند نقدینگی، نرخ ارز، کسری بودجه یا انتظارات تورمی توضیح داد»؛ بخش مهمی از رفتار تورم، محصولِ «ساختار شبکه‌ای و پویای اقتصاد» یعنی همان روابط چندلایه، غیرخطی و زمان‌مند بین صنایع، بنگاه‌ها و زنجیره‌های تأمین است. در چنین اقتصادی، تغییر قیمت یک نهاده یا یک شوک عرضه به‌صورت یکنواخت و خطی پخش نمی‌شود؛ بلکه بر اساس مسیرهای خاصی در شبکه تولید حرکت می‌کند و ممکن است در برخی نقاط تقویت، در برخی بخشها تضعیف شود و در برخی جاها با تأخیر زمانی ظاهر گردد. (Leijonhufvud, 1997). برای مثال افزایش قیمت در یک صنعت، به‌ندرت به همان بخش محدود می‌ماند. افزایش هزینه تولید فولاد تنها به صنعت فولاد محدود نمی‌شود؛ بلکه زنجیروار به تولید قطعات خودرو، سپس به قیمت خودرو و در ادامه به هزینه حمل‌ونقل سرایت می‌کند و نهایتاً قیمت کالاهای مصرفی وابسته به حمل‑ونقل نیز افزایش می‌یابد. این الگوی انتشار پیچیده و مسیرمند است و هیچ مدل خطی ساده‌ای قادر به بازنمایی آن نیست.در بسیاری موارد، شدت واکنش بخش‌ها نسبت به شوک‌ها غیرخطی است. گاهی یک افزایش کوچک در قیمت یک نهاده حیاتی، جهشی بزرگ در هزینه نهایی ایجاد می‌کند که بیش از اثر مستقیم افزایش قیمت آن نهاده است. (Leijonhufvud, 1997) از سوی دیگر اقتصاد واقعی پویاست و بنگاه‌ها رفتار خود را در طول زمان تغییر می‌دهند. Goodwin (1947) نشان می‌دهد که بنگاه‌ها قادر نیستند ساختار تولید و ترکیب نهاده‌های خود را فوراً تغییر دهند؛ بلکه تعدیل تکنیک‌ها و جایگزینی نهاده‌ها فرآیندی تدریجی و زمان‌بر است. بنابراین فرض «ضرایب فنی ثابت» در تحلیل‌های استاتیک، با واقعیت پویای رفتار تولید سازگار نیست. جایگزینی نهاده‌ها، تغییر در تأمین‌کنندگان، صرفه‌جویی در هزینه یا تغییر فناوری‌ها اموری هستند که به تدریج رخ می‌دهند. برای مثال، در پی افزایش نرخ چرم طبیعی، تولیدکنندگان محصولات چرمی ممکن است به‌تدریج استفاده از چرم طبیعی را کاهش دهند و چرم مصنوعی را جایگزین کنند. این انتقال ممکن است ماه‌ها زمان ببرد و نشان می‌دهد که ضرایب فنی تولید ثابت نیستند. تحلیل تورم بدون در نظر گرفتن این پویایی، تصویر نادرست و ناقصی از فرآیند تورم ارائه می‌دهد. همچنین تورم اغلب به شکل خوشه‌ای ظاهر می‌شود. بخش انرژی، غذا، حمل‌ونقل یا مسکن ممکن است رفتارهای تورمی مشترکی داشته باشند، زیرا در یک خوشه شبکه‌ای قرار دارند. این هم‌حرکتی را نمی‌توان با یک یا دو متغیر کلان توضیح داد، اما از طریق الگوریتم‌های تشخیص خوشه در شبکه‌های ورودی–خروجی می‌توان آن را شناسایی کرد. مثال روشن آن افزایش قیمت گاز طبیعی است که به‌سرعت بر پتروشیمی، پلاستیک، بسته‌بندی و نهایتاً مواد غذایی اثر می‌گذارد؛ اما ممکن است به بخش خدمات مالی تقریباً بی‌اثر باشد و یا افزایش قیمت گوشت قرمز باعث می‌شود فشار تقاضا بر گوشت سفید افزایش یابد و قیمت آن را افزایش دهد حال آنکه بر سایر محصولات غذایی غیرمرتبط ممکن است تأثیر چندانی نداشته باشد . عامل دیگر رفتار تورم به‌ وسیله حلقه‌های بازخوردی است. مثلاً افزایش قیمت سوخت باعث افزایش هزینه حمل و نقل می‌گردد که خود یکی از موارد تعیین‌کننده برای قیمت سوخت به جهت حمل از محل تولید تا مصرف است. در چنین چرخه‌هایی، افزایش قیمت در یک بخش می‌تواند چند مرحله بعد دوباره به نقطه شروع بازگردد و تورم را تشدید کند. این الگوهای بازگشتی فقط در مدل‌های شبکه‌ای قابل شناسایی‌اند (Bilgin, 2025). همچنین، شوک‌های قیمتی در بخش‌های مختلف با تأخیر زمانی متفاوت منتقل می‌شوند. افزایش قیمت انرژی ممکن است در همان ماه نخست بر صنایع فولاد و سیمان اثر بگذارد، اما اثر آن بر قیمت خدمات آموزشی یا درمانی ممکن است با فاصله چندین ماه بروز کند. این ناهمگنی زمانی، بخشی بنیادین از پویایی تورم است (Afrouzi & Bhattarai, 2023).به‌طور خلاصه، تورم پدیده‌ای چندلایه، شبکه‌ای و پویاست و مدل‌های ساده کلان قادر به توضیح کامل آن نیستند. برای فهم دقیق انتقال، شدت، مسیر و زمان‌بندی تورم، ناگزیر باید به تحلیل شبکه‌های پویا در ساختار اقتصادی روی آورد؛ جایی که روابط واقعی اقتصاد نه به‌صورت خطی و ساده، بلکه همچون یک سیستم پیچیده با مسیرهای سرایت، حلقه‌های بازخورد و گلوگاه‌های ساختاری عمل می‌کنند (Afrouzi & Bhattarai, 2023).نظریات کلاسیک مرتبط با شبکه در علم اقتصاد : اقتصاددانان در تبیین بسیاری از پدیده‌ها به آثار شبکه‌ای در علم اقتصاد اشاره می‌کنند. استفاده از شبکه‌های پیچیده پویا از ابزارهای مهم در تحلیل و پیش‌بینی‌های اقتصادی است. روساریو مانتگنا[1] در سال ۱۹۹۹ اولین مطالعه مهم که در مورد بازارهای سهام بود در مورد استفاده از شبکه‌ها برای تحلیل سیستم‌های اقتصادی پیچیده را انجام داد. از آن زمان تاکنون، تعداد زیادی مطالعه در اقتصاد کلان و اقتصاد مالی از شبکه‌های پیچیده استفاده کرده‌اند. این روش به محققان امکان می‌دهد تا بررسی کنند که شبکه‌ها، چگونه بر نقدینگی بازار و تورم اثر می‌گذارند. برای مثال عجم اوغلو[2] با تحلیل شبکه‌های داده ستانده نشان داد بر خلاف نظرات اقتصاد کلاسیک که معتقد بود طبق قانون اعداد بزرگ شوک‌های بنگاه‌های منفرد اهمیتی برای کل اقتصاد ندارند؛ چون با هم میانگین می‌شوند و اثرشان خنثی می‌شود اگر شبکه ارتباطات بین صنایع نامتوازن باشد، شوک‌های کوچک هم می‌توانند جمع نشوند و حتی تقویت شوند. (2016)به رغم ماهیت شبکه‌ای اقتصاد، گریز به آن تنها زمانی معمول است که بکارگیری روشهای ساده‌تر جوابگو نباشد. چرا که حمله به سمت آن بسیار دشوار است. لئونتیف[3] می‌نویسد: «پژوهشگر از تجربه‌های سخت خواهد آموخت که باید نقطه مقاومتِ سخت را تنها هنگامی مورد حمله قرار داد که تمام قلمروهای همجوارِ آسان‌تر، از پیش به‌طور کامل فتح و بررسی شده باشند.» (1951) جدای از پیچیدگیهای مربوط به تحلیل شبکه‌های پویا مشکل مهم دیگری در بررسی متغیرهای اقتصادی از طریق شبکه‌ها وجود دارد و آن ترسیم و یا تعریف خود شبکه است. بر خلاف شبکه‌های پیچیده دیگر نظیر شبکه دنبال‌کنندگان در شبکه‌های اجتماعی و یا شبکه ارجاعات به مقاله‌ها و ..... که ارتباط بین گره‌ها به وضوح مشخص است و تنها به واسطه گستردگی و پویایی گره‌ها و نقاط در تحلیل آنها ممکن است دچار مشکل شویم در شبکه‌های مالی و پولی علاوه بر گستردگی عوامل درهم تنیده، ارتباطات آنها نیز به لحاظ شدت، زمان اثرگذاری و شکل اثرگذاری بسیار پویا، مبهم و غیرشفاف است و ناگزیر از بکار بردن انتزاع در تعریف شبکه‌ها و فرضیاتی برای ساده‌سازی مساله هستیم. گودوین در ابتدای مقاله خود که در مورد ارتباطات دینامیک در اقتصاد است می‌نویسد:«در واقع، پیشرفت در درک هر موضوعی از طریق انتزاع موفق حاصل می‌شود، یعنی تشخیص اینکه چه چیزهایی را می‌توان نادیده گرفت و چه چیزهایی را نمی‌توان نادیده گرفت.» (Goodwin, 1947) اولین تلاش در زمینه ایجاد یک شبکه تحلیلی در علم اقتصاد را باید احتمالا به لئونتیف نسبت داد. هرچند در زمان وی نظریه شبکه‌های پیچیده وجود نداشت و گراف‌ها فقط در ریاضیات نظری استفاده می‌شدند. اما کاری که لئونتیف کرد این بود که ساختار اقتصاد را در قالب یک ماتریس وابستگی متقابل نشان داد. وی در دهه 1930 برای تحلیل اقتصاد آمریکا جدولی ابداع نمود که آن را جدول روابط داده ستانده[4] نامگذاری نموده بود و در کتاب خود که بعدها نوشت آن را چنین توضیح می‌دهد: «از دیدگاه طرح داده- ستانده، هر اقتصاد ملی را می‌توان به‌عنوان یک سیستم صنایع مرتبط متقابل یا فعالیت‌های اقتصادی وابسته به یکدیگر توصیف کرد. این روابط در واقع به شکل جریان‌های نسبتاً پایدار کالا و خدمات است که به‌صورت مستقیم یا غیرمستقیم، تمام بخش‌های اقتصاد را به یکدیگر پیوند می‌دهد. این جریان‌ها را می‌توان به‌صورت کمی مشاهده و توصیف کرد.» (Leontief,1951)شکلتصویری از جدول داده ستانده توسط لئونتیفدر جدولی که وی ابداع نمود اقتصاد کشور به 50 بخش مثل بخش کشاورزی، فولاد، صنایع غذایی و .. بخش‌بندی شده بود. صنایع خارجی نیز به صورت یک بخش مجزا درنظر گرفته شده بود. همچنین دو بخش خانوار و دولت نیز به عنوان مصرف‌کننده نهایی در جدول لحاظ شده بود که البته هیچ محصولی تولید نمی‌نمودند. ابن بخش‌ها به صورت متقارن در داخل 50 ردیف و 50 ستون قرار می‌گرفتند . هر سطر نشان‌دهنده تولید یک صنعت و هر ستون نشان‌دهنده مصرف یک صنعت از تولید سایر صنایع بود. مقدار در خانه i,j نشان می‌داد که صنعت i چقدر از تولید صنعت j بر حسب ارزش پولی استفاده کرده است.البته زمان لئونتیف روش استانداردی برای درج اعداد در این جدول وجود نداشت و او با استفاده از گزارشهای پراکنده و سرشماریهای آماری خانه‌های این جدول را تکمیل نمود. اما امروز صنایع بسیار پیچیده‌تر شده‌اند. یک صنعت چند محصول تولید می‌کند و یک محصول توسط چند صنعت تولید می‌شود و خدمات واسطه رشد کرده است. مالیات‌ها، یارانه‌ها، حمل‌ونقل و تجارت خارجی نیز جداگانه تعریف می‌شوند. بنابراین دیگر نمی‌توان مثل زمان لئونتیف از «داده‌های هزینه» مستقیماً جدول متقارن ساخت. هم‌اکنون این جدول در قالب استاندارد بین‌المللی SNA که توسط پنج سازمان شامل سازمان ملل، صندوق بین‎المللی پول، بانک جهانی، OECD و ٍٍEurostat تدوین می‌شود تهیه و به‌روزرسانی می‌گردد.در ایران جدول داده ستانده برای اولین بار توسط وزارت اقتصاد در سال 1344 تهیه گشت. جدیدترین آن نیز در سال 1395 توسط مرکز آمار برای 82 رشته فعالیت با 155 محصول منتشر گردیده است. (مرکز آمار ایران، 1395)جداول متقارنی که مرکز آمار تهیه نموده است هرچند صریحا در گزارش قید نگردیده است ولی باید آن را تقریباً منطبق بر استاندارد تدوین شده توسط SNA دانست که بر اساس عرضه و تقاضا[5] محاسبه شده است. در این جدول ابتدا هزینه مصرفی هر بخش از خریداری هر محصول در دو جدول که یکی بر حسب قیمت تولیدکننده و دیگری قیمت مصرف‌کننده است محاسبه می‌گردد. سپس میزان عرضه هر یک از آن 155محصول توسط 82 شرکت بر حسب قیمت تولیدکننده در جدول دیگر تهیه گردیده است. این سه جدول اطلاعات پایه را برای محاسبه ورودی و خروجیهای هر بخش محاسبه می‌نمایند و جداول متقارن که نشان‌دهنده ارزش ریالی مورد استفاده هر بخش از بخش دیگر است از آن مستقیما به واسطه فرمولهای محاسبه که از ضرب ماتریسها و ماتریس وارون بهره می‌برند محاسبه می‌گردد.اما جدول داده ستانده به رغم کاربردهای فراوانی که دارد در مدلهای پایه آن هنوز برای تحلیل بسیاری از پدیده‌های اقتصادی کافی نیست. برای مثال دو محدودیتی که خود لئونتیف نیز از ابتدا اشاره کرده بود آن بود که این جدول اثرات روانی و رفتار مصرف‌کنندگان را لحاظ نمی‌کند و تنها روابط مالی و مادی صنایع را دنبال می‌کند. همچنین دینامیک اقتصادی یا تغیرات تکنولوژیک و تفاوتهای زمانی را نیز در اثرگذاری لحاظ نمی‌کند و فرض می‌کند همه روابط در یک زمان واحد رخ می‌دهد.گودوین تلاش نمود روابط دینامیک را در اقتصاد چندبخشی به مدل لئونتیف اضافه نماید. اما برای این کار راه‌حل او خلاص شدن از آثار شبکه‌ای اقتصاد بود. او بیان نمود شرط بررسی روابط دینامیک خارج از شبکه و به صورت ساده غیر متقارن بودن آن است. برای مثال صنعت خودرو و فولاد ارتباط دینامیک غیرمتقارن با یکدیگر دارند. چون در زمانی که عرضه فولاد با یک شوک مواجه می‌گردد صنعت خودرو چون با آلترناتیو دیگری مواجه نیست با مشکل مواجه می‌گردد و آن هم دچار شوک می‌گردد. ولی اگر در تقاضای مصرفی از سوی بخش خودرو مشکلی پیش‌بیاید اگر بخش فولاد با صنایع متعدد دیگری درگیر باشد این وابستکی نمی‌تواند تاثیر زیادی بر روی بخش فولاد بگذارد. لذا در این حالت می‌توان سمت ضعیف‌تر ارتباط را حذف نمود تا مسائل را بتوان ساده‌تر حل نمود.(Goodwin, 1947) هرچند این ساده‌سازی همانطور که خود او می‌گوید همیشه جواب نمی‌دهد و ما را نمی‌تواند از رویکرد شبکه‌ای فارغ نماید‌. نقد وارد دیگر بر مدل لئونتیف فرض او بر خطی بودن روابط بین بخشی است. در مدل‌های ساده، ممکن است اثرات مستقیم یک نهاده یا محصول دیده شود، اما اثر تجمعی و تقویت‌شده از مسیرهای چندمرحله‌ای و هم‌افزایی‌های داخل شبکه دیده نمی‌شود. وقتی یک محصول چندین صنعت را تحت تأثیر قرار می‌دهد و صنایع دیگر هم با هم مکمل هستند، شوک چند برابر و غیرخطی روی کل اقتصاد ظاهر می‌شود این همان چیزی است که مدل‌های سنتی لئونتیف و تحلیل‌های خطی ساده نمی‌توانند کاملاً نشان دهند.مدلهای مدرن تحلیل شبکه در علم اقتصادیکی از عواملی که شروع تحلیل‌های شبکه‌ای مدرن را در اقتصاد به تاخیر انداخت نظریه لوکاس بود.. لوکاس بیان داشت اثرات خرد درون شبکه طبق قانون اعداد بزرگ همدیگر را خنثی می‌نمایند و شوکهای خرد نمی‌توانند اثرات بزرگی ایجاد نمایند. لذا مطالعه آنها بی‌ثمر است. پذیرش نظریه لوکاس بدین معنا بود که مطالعه ساختارهای شبکه‌ای مثل لئونتیف امر بیهوده‌ای است و متغیرهای اقتصادی فارع از ساختار شبکه به صورت خطی بر روی اقتصاد کلان اثر می‌کنند. اما مشاهده بسیاری از تجارب اقتصادی و تحلیل آن که از طریق روشهای معمول امکان‌پذیر نبود بالاخره اقتصاددانها را وادار به تحلیل شبکه و شناخت ساختارهای شبکه‌ای نمود. امری که با یک تاخیر از ابتدای قرن جاری شروع شد و هنوز به نظر می‌رسد با پختگی کامل فاصله زیادی دارد و در اینجا به برخی از نمونه‌های شاخص آن اشاره می‌کنیم.پژوهش اول: تحلیل ساختاری شبکه‌های صنعتی و ارتباط آن با تاب‌آوری اقتصادی منطقه‌ای (Qiao & Ji, 2021)پژوهش حاضر با عنوان تمرکز بر نابرابری‌های منطقه‌ای در چین، به واکاوی علل تفاوت در سطح تاب‌آوری استان‌ها در مواجهه با شوک‌های اقتصادی، به‌ویژه بحران مالی ۲۰۰۸، می‌پردازد. مسئله بنیادین در این راستا، تمرکز نامتقارن منابع و صنایع پیشرفته در قطب‌های خاص است که منجر به شکل‌گیری ساختارهای توسعه‌ای نامتوازن گشته است؛ پدیده‌ای که علاوه بر چین، در بسیاری از کشورهای عضو OECD نیز مشهود است. اگرچه افزایش پیوندهای اقتصادی میان مناطق می‌تواند کارایی سیستم را ارتقا بخشد، اما هم‌زمان پتانسیل آسیب‌پذیری در برابر شوک‌های بیرونی را نیز تشدید می‌کند. بر این اساس، مفهوم «تاب‌آوری اقتصادی منطقه‌ای» به معنای توانمندی یک سیستم برای مقاومت، بازیابی، بازآرایی و تجدید مسیر رشد، چارچوب اصلی این تحلیل را تشکیل می‌دهد (Qiao & Ji, 2021).نوآوری محوری این مطالعه، به‌کارگیری نقشه‌نگاری ساختارهای شبکه‌ای در حوزه اقتصاد منطقه‌ای است. در این مدل‌سازی، اقتصاد هر استان به مثابه یک شبکه پیچیده صنعتی در نظر گرفته می‌شود که در آن صنایع در نقش گره‌ها و روابط داده-ستانده، وابستگی‌های تولیدی-مصرفی و همبستگی‌های صنعتی در نقش پیوندها عمل می‌کنند. وزن این پیوندها که نشان‌دهنده شدت وابستگی متقابل است، از طریق ترکیب ضرایب عرضه و تقاضا و بر اساس جداول داده-ستانده استانی استخراج شده است. این رویکرد اجازه می‌دهد تا «معماری درونی اقتصاد منطقه» با دقت بالایی ترسیم شود (Qiao & Ji, 2021).از منظر نظریه شبکه‌ها، اقتصاد منطقه‌ای یک سیستم پیچیده با آستانه‌های بحرانی مشخص تلقی می‌شود. یافته‌های حاصل از اجرای آزمون تنش نشان می‌دهد که حذف صنایع به صورت تصادفی یا هدفمند (حذف هاب‌های با درجه اتصال بالا) می‌تواند به فروپاشی ساختاری منجر شود. در شبکه‌هایی که حول چند هاب مرکزی سازمان‌یافته‌اند، نوعی پارادوکس مشاهده می‌شود: این سیستم‌ها در برابر شوک‌های تصادفی مقاوم، اما در برابر حذف هدفمند گره‌های کلیدی به‌شدت آسیب‌پذیرند. بنابراین، ویژگی‌های توپولوژیک شبکه و نحوه توزیع پیوندها، تعیین‌کننده نهایی سطح تاب‌آوری منطقه‌ای است (Qiao & Ji, 2021).نتایج تجربی این پژوهش تایید می‌کند که استان‌های دارای شبکه‌های صنعتی منسجم‌تر و مستحکم‌تر، در طول بحران ۲۰۰۸ افت کمتری را در نرخ اشتغال تجربه کرده‌اند. نکته حائز اهمیت این است که صرفِ «تنوع صنعتی» برای تضمین ثبات کافی نیست، بلکه نحوه اتصال و معماری پیوندها اهمیت بیشتری دارد. در این میان، مفهوم «تنوع مرتبط[6] به عنوان یک تیغ دو لبه عمل می‌کند؛ چرا که پیوند میان صنایع هم‌خانواده می‌تواند از سویی نوآوری را تقویت کرده و از سوی دیگر به کانالی برای انتشار سریع زنجیره‌ای بحران تبدیل شود (Qiao & Ji, 2021).در نهایت، این مطالعه پیشنهاد می‌دهد که برای درک عمیق تاب‌آوری باید از الگوهای تعادلی سنتی عبور کرد و به سمت تحلیل نقشه‌ای وابستگی‌های صنعتی حرکت نمود. ویژگی‌هایی نظیر درجه اتصال گره‌ها، وجود هاب‌های استراتژیک و آستانه فروپاشی شبکه، شاخص‌های کلیدی برای ارزیابی ثبات اقتصادی هستند. از منظر سیاست‌گذاری، این رویکرد که تلفیقی از جغرافیای اقتصادی تکاملی و علم شبکه است، ایجاب می‌کند که برنامه‌های توسعه منطقه‌ای نه تنها بر تنوع‌بخشی، بلکه بر تقویت و بهینه‌سازی ساختار شبکه‌ای برای جلوگیری از سرایت شوک‌ها متمرکز شوند.مقایسه دو شهر شانگهای و گوانجونگ در تاب آوری اقتصادی که خط قرمز نشانگر حذف تصادفی و خط چین آبی نشانگر حذف هدفمند گره‌های شبکه است.پژوهش دوم: تحلیل ساختاری شبکه تأمین و عملکرد مالی بنگاه‌ها در شرایط بحران (Orenstein & Zhang, 2023)این پژوهش با اتخاذ رویکردی نوآورانه در تلاقی «علم شبکه‌ها» و «اقتصاد مالی»، به بررسی چگونگی تأثیر هندسه و ساختار روابط یک شرکت با تأمین‌کنندگان بر ارزش بازار آن در دوران بحران (مانند پاندمی کووید-۱۹) می‌پردازد. محققان با تمرکز بر داده‌های بازه زمانی ۲۰۱۸ تا ۲۰۲۲ دو شرکت پیشرو در صنعت خودرو، فورد و جنرال موتورز، و با بهره‌گیری از تکنیک‌های داده‌کاوی، شبکه‌های تأمین این شرکت‌ها را به گونه‌ای پالایش کردند که تنها گره‌های حیاتی در جریان واقعی ارزش محصول باقی بمانند. دستاورد محوری این مطالعه اثبات آماری این نکته است که شاخص‌های ساختاری شبکه، از جمله «متوسط درجه» و «ضریب خوشه‌بندی» ، تأثیر مستقیم و معناداری بر شاخص Tobin’s Q به عنوان نماد ارزش بازار شرکت دارند.یکی از یافته‌های کلیدی و چالش‌برانگیز این مطالعه، شناسایی رابطه معکوس میان «متوسط درجه» (تعداد اتصالات) و عملکرد مالی است. برخلاف دیدگاه‌های سنتی که کثرت تأمین‌کنندگان را نشانه قدرت و توزیع ریسک می‌دانستند، این پژوهش نشان می‌دهد که افزایش بی‌رویه لبه‌ها و اتصالات در شبکه، به دلیل ایجاد پیچیدگی‌های مدیریتی و تحمیل هزینه‌های نظارتی سنگین، در نهایت منجر به کاهش ارزش بازار شرکت می‌شود. در مقابل، پژوهش بر اهمیت «کیفیت و فشردگی روابط» تأکید می‌ورزد؛ به طوری که بالا بودن ضریب خوشه‌بندی و تراکم شبکه به عنوان سیگنالی مثبت برای بازار عمل می‌کند. این ویژگی‌ها نشان‌دهنده توانمندی شرکت در انتقال سریع اطلاعات و منابع در زمان بحران است، چرا که در شبکه‌هایی با خوشه‌بندی بالا، تأمین‌کنندگان خود نیز با یکدیگر در ارتباط بوده و تاب‌آوری سیستماتیک بیشتری ایجاد می‌کنند.در نهایت، تحلیل تطبیقی میان فورد و جنرال موتورز نشان می‌دهد که پویایی ساختار شبکه چگونه به یک مزیت رقابتی تبدیل می‌شود. یافته‌ها حاکی از آن است که شبکه جنرال موتورز به دلیل اتکای مفرط به گره‌های مرکزی و بزرگ، در برابر شوک کووید-۱۹ آسیب‌پذیری بیشتری نشان داد؛ در حالی که شرکت فورد با بهره‌گیری از شبکه‌ای منعطف‌تر و ساختاری که وابستگی کمتری به گره‌های خاص داشت، توانست ارزش بازار خود را به شکل بهتری حفظ نماید. دستاورد بزرگ این تحقیق، تبدیل مفهوم انتزاعی «تاب‌آوری» به معیارهای ریاضی دقیق است که امکان ارزیابی پایداری مالی بنگاه‌ها را بر اساس توپولوژی شبکه فراهم می‌سازد. بر این اساس، ثابت می‌شود که در اقتصاد مدرن، «تناسب ساختاری» شبکه تأمین، از «وسعت» آن حیاتی‌تر است.پژوهش سوم: شبکه‌ها، شوک‌ها و ریسک سیستمیک (Acemoglu et al., 2015)عجم‌اوغلو و همکاران در این پژوهش بنیادین، به تحلیل توپولوژی شبکه‌های اقتصادی و سازوکارهای انتشار نوسانات در بستر این شبکه‌ها می‌پردازند. هدف اصلی این مطالعه، تبیین این مسئله است که چگونه ساختار اتصالات میان گره‌ها می‌تواند شوک‌های خردِ محلی را میرا کرده و یا برعکس، آن‌ها را به بحران‌های سیستمیک در کل گراف شبکه تبدیل کند. این پژوهش چون همراستایی بیشتری با اهداف این پژوهش دارد با جزییات بیشتری توضیح داده می‌شود.آنها بدین منظور از مدل‌های شکل-کاهش یافته در شبکه استفاده می‌کنند. مدل شکل-کاهش‌یافته بدین معنا است که فقط به روابط نهایی پس از متعادل شدن سیستم پس از یک شوک نگاه می‌شود. برای مثال ما کاری نداریم در ذهن مدیر کارخانه چه می‌گذرد؛ فقط رصد می‌کنیم که وقتی قیمت برق بالا رفت، او قیمت محصولش را چقدر بالا می‌برد. بدین ترتیب تمام جزئیاتِ روان‌شناختی و انگیزشی که مدل را پیچیده می‌نماید حذف می‌گردد. این مدل از اجزای زیر تشکیل شده است:۱. تابع تعامل نسبتاً عمومی که وابستگی وضعیت هر عامل را به عوامل دیگر نشان می‌دهد.۲. شبکه تعاملات که مشخص می‌کند این معیارهای خلاصه، چگونه به‌عنوان تابعی از وضعیت سایر عامل‌ها تعیین می‌شوند.۳. تابع تجمیع که توصیف می‌کند چگونه وضعیت‌های سطحِ عامل، در کنار هم متغیرِ کلانِ مورد نظر را شکل می‌دهند.در مدل داده ستانده، مصرف‌کننده نهایی «ایستگاه آخر» است و منطقاً همه‌چیز باید همان‌جا تمام شود. اما در مدل شبکه‌ای عجم‌اوغلو، ماجرا متفاوت است. مصرف‌کننده نهایی خودش یک گره در شبکه است، نه یک نقطه خارج از آن.عجم اوغلو و همکاران برای مدل‌سازی انتشار شوک در یال‌ها، از یک تابع انتقال به نام f استفاده می‌کنند که طبق رابطه زیر تعریف می‌شود:در اینجا wij وزن یال بین عامل i و j در ماتریس مجاورت شبکه W است. ϵi شوک مستقل و ناشی از خودِ عامل i است.آنچه در اینجا از اهمیت کلیدی برخوردار است، وضعیت هر عامل i است که با xi نشان داده می‌شود؛ این متغیر، انتخابِ عملِ آن عامل مانند میزان تولید یا سرمایه‌گذاری یا هر متغیر اقتصادی مورد نظر دیگر (مانند توانایی پرداخت بدهی یک نهاد مالی) را نشان می‌دهد. وی در توضیح این مطلب می‌نویسد:«فرقی نمی‌کند مدل درباره تولید باشد یا بازارهای مالی؛ اصل ماجرا این است که گره‌ها بر هم اثر می‌گذارند و این یعنی راه برای «سرایتِ» شوکِ یک گره به کل اقتصاد باز است.»مقدار ثابت wij در رابطه فوق، میزان تعامل بین عامل‌های i و j را نشان می‌دهد. به طور مشخص، wij بزرگتر به این معناست که وضعیت عامل i نسبت به وضعیت عامل j حساس‌تر است؛ در حالی که wij=0 به این معنی است که عامل j تأثیر مستقیمی بر وضعیت عامل i ندارد. بدون آنکه از کلیت موضوع کاسته شود، فرض می‌کنیم مجموع وزن‌ها برای هر عامل برابر با یک است. این امر تضمین می‌کند که میزان وابستگی هر عامل به مجموع سایر عامل‌ها، مقداری ثابت است.با شناخت تابع f، تعاملات بین عامل‌ها را می‌توان به‌وسیله یک گراف وزن‌دار و جهت‌دار با n رأس نیز به دست آورد که آن را می‌توان شبکه تعاملات اقتصاد نامید. هر رأس در این شبکه متناظر با یک عامل است و یک یال جهت‌دار از رأسj به رأس i وجود دارد. اگر wij > 0 باشد؛ به این معنا است که وضعیتِ عامل i مستقیماً تحت تأثیر وضعیتِ عامل j قرار دارد.در نهایت وضعیتِ کلانِ اقتصاد به صورت زیر تعریف می‌گردد.y = g(h(x1) +h(x2)+…. + h(xn))که در آن g و h توابعی از مجموعه اعداد حقیقی به اعداد حقیقی و y نشان‌دهنده یک خروجی اقتصاد کلانِ مورد نظر است که از تجمیع وضعیت‌های فردیِ تمامی عامل‌ها به دست می‌آید. g نیز تابع تجمیعِ اقتصاد است که وضعیت کلان را نشان می‌دهد. این فرمول مثل یک ماشین عمل می‌کند. ابتدا اقدامات تک‌تک افراد xi را می‌گیرد، آن‌ها را از فیلتر تابع h رد می‌کند، با هم جمع می‌زند و در نهایت کلِ حاصل را از فیلتر تابع g عبور می‌دهد. با در نظر گرفتن وقوع شوک‌های، تعادلِ اقتصاد مجموعه‌ای از وضعیت‌های است به‌طوری که معادله اول آنهابرای تمامی عامل‌های i به طور هم‌زمان برقرار باشد. بدین معنا که اول شوک‌هااتفاق می‌افتند (مثلاً قیمت دلار ناگهان جهش می‌کند یا جنگی رخ می‌دهد.) سپس، گره‌ها با هم تعامل می‌کنندتا به یک وضعیت پایدار برسند، به گونه‌ای که تابع f برای همه وضعیت‌ها در شرایط بعد از شوک دوباره صدق نماید.از نظر آنها خروجی نهایی سیستم نه تنها به وزن یال‌ها، بلکه به ویژگی‌های مشتق‌پذیری این تابع بستگی دارد که تعیین‌کننده رفتار سیستم در گذر از حالت عادی به بحران است. برای شناخت مرز دو حالت عادی و بحران دو سناریوی زیر با توجه به تابع تعامل تعریف می‌گردد.آنها در مفروضات مساله می‌نویسند ما بر اقتصادی تمرکز می‌کنیم که در آن شوک‌های سطحِ عامل کوچک هستند. این فرض آنها را قادر ‌ساخت تا وضعیت تعادلیِ هر عامل و وضعیت اقتصاد کلان را که از اثرات چرخش چندباره یک شوک در داخل شبکه حاصل می‌گردد به‌ وسیله چند جمله اولِ بسط تیلورِ آن‌ها تقریب بزنند. حال آنکه در تورم‌های بالا، رفتارهای دفاعیِ عامل‌ها (مثل احتکار، انتظارات تورمی و پیش‌خور کردن گرانی) فعال می‌شود. این رفتارها عواملی هستند که در اعداد کوچک (۲ و ۳ درصد) خواب بوده‌اند، اما در اعداد بزرگ بیدار می‌شوند و رفتار تابع را پیش‌بینی ناپذیر می‌نمایند.آنها اولین نتیجه این مدلسازی را چنین بیان می‌نمایند:«در یک دنیای خطی، عملکرد کلان اقتصاد در حالت میانگین، به جزئیات پیچیده شبکه تعاملات زیربنایی آن بستگی ندارد.»در اقتصاد خطی اگر قیمت بنزین ده درصد گران شود و اثرش بر حمل‌ونقل پنج درصد باشد، وقتی بنزین بیست درصد گران شود، اثرش بر حمل‌ونقل حتماً باید ده درصد باشد. در این حالت اقتصاد خطی و کاملاً پیش‌بینی پذیر می‌گردد. امری که آن را معادل اطمینان[7] می‌نامند. اگر فرض کنیم همه چیز خطی است، شبکه بی‌اهمیت می‌شود. هرچند به تجربه چنین رفتار منظمی را معمولاً مشاهده نمی‌کنیم و می‌توان نتیجه گرفت که اقتصاد امری غیرخطی است. یعنی اگر مجموعه‌ای از شوک‌های کوچک مثبت و منفی به اقتصاد وارد شود، این‌ها دیگر همدیگر را خنثی نمی‌کنند. به دلیل غیرخطی بودن، ممکن است برآیندِ چند شوک کوچک که قاعدتاً باید صفر می‌شد، ناگهان به یک تورم بزرگ تبدیل شود.توصیف نظریه بازی ها طبق مدل شبکه پیشنهادی عجم اوغلو:یک بازی با n بازیکن و با اطلاعات کامل را در نظر بگیرید[8] که در آن تابع مطلوبیت (سود) عامل i به صورت زیر داده شده است:در اینجا xi اقدامی است که بازیکنi انجام می‌دهد (مثلاً میزان تلاش یا سرمایه‌گذاری). wij وزن شبکه است که نشان‌دهنده قدرت و نوع اثرگذاری بازیکن j روی بازیکن i است. F تابع تعامل است که قبلا توضیح داده شد و نشان می‌دهد که اقدامات دیگران چگونه بر مطلوبیت فرد اثر می‌گذارد و ϵi اثر مستقل از عوامل همسایه است که بر پاداش فرد اثر می‌گذارد.این تابع حاصل‌جمع دو عبارت است که بخش اول که منفی است هزینه‌ایست که بابت بیشینه‌سازی سود پرداخته می‌شود و بخش دوم نتایج حاصل از تلاش مذکور است و به صورت فرمول فوق فرض شده است. در شبکه‌ای که الگوی فوق برقرار باشد چون مشتق دوم منفی است، بیشترین سود برای هر بازیکن زمانی به دست می‌آید که مشتق اول تابع فوق صفر گردد و این همان معادله اول است که در ان تعادل نش برقرار می‌شود؛ یعنی وضعیتی که در آن، هیچ بازیکنی نمی‌تواند با تغییرِ «تنهاییِ» استراتژی خود، وضعیتش را بهتر کند؛ به شرطی که بقیه بازیکنان استراتژی‌شان را تغییر ندهند. اگر تابع f صعودی باشد معنای آن این است که هرچه اطرافیان ما بیشتر تلاش کنند، سود ما از تلاش بیشتر، افزایش می‌یابد (مثل یادگیری یک زبان جدید یا استفاده از یک پیام‌رسان) که این حالت مکمل استراتژیک نامیده می‌شود و وقتی تابع f نزولی است معنای آن این است که با افزایش تلاش دیگران، نیاز به تلاش کمتری برای ما هست و یا xi بهینه کمتری نسبت به زمان قبلی که همسایه ما تلاش ننموده بود داریم. این حالت را جایگزین استراتژیک می‌نامند.یک زیرگروه ساده شده از تابع f آن است که نتیجه آن برابر ضریب ثابت α که یک مقدار مابین صفر و یک است ضربدر ورودی تابع باشد. در این حالت رابطه قبلی به شکل زیر درخواهد آمد.اگر مثل قابل حالت بهینه را حساب نماییم خواهیم داشت:حال اگر معادله اول را برای هر n گره بنویسیم، n معادله خطی با n مجهول خواهیم داشت که به طریق جبر ساده خطی حل خواهد شد. برای تعیین سطح کلان جامعه نیز دو راه داریم. یکی آنکه مجموع تلاش جامعه را حساب کنیم. در این حالت فعالیت مجموع جمع کل اقدامات همه بازیکنان خواهد شد. یعنی برای متغیر کلان g(z) = h(z) = z و دیگر آنکه رفاه کل جامعه را حساب کنیم.همچنین اگر معادله بالا را در تابع سود جایگزاری نماییم خواهیم داشتو این یعنی رفاه کل جامعه برابر است بادر این متغیر کلان توابع g و h به صورت g(z) = z و h(z) = z2/2 هستند.حال اقتصادی شامل n بنگاه (یا بخش) رقابتی را در نظر بگیرید که با {1, 2,……, n} نشان داده می‌شوند و هر یک کالای متمایزی تولید می‌کنند. هر محصول می‌تواند یا توسط توده‌ی مصرف‌کنندگان مصرف شود و یا به عنوان نهاده (کالای واسطه‌ای) برای تولید کالاهای دیگر به کار رود. تمام بنگاه‌ها از فناوری تولید کاب-داگلاس[9] با بازدهی ثابت نسبت به مقیاس[10] استفاده می‌کنند که نیروی کار و کالاهای واسطه‌ای را به محصول نهایی تبدیل می‌کند و تولید در معرض نوعی شوک فناوری خاص (ایدیوسینکراتیک) قرار دارد. به طور مشخص‌تر، خروجی بنگاه i که آن را با Xi نشان می‌دهیم، برابر است با:که در آن Ai شوک بهره‌وری مربوطه؛ li مقدار نیروی کار استخدام شده توسط بنگاه i ؛ xij مقدار کالای j که برای تولید کالای i استفاده شده است؛ bi یک مقدار ثابت و α که عددی بین صفر و یک است؛ بیانگر سهم کالاهای واسطه‌ای در تولید است. توان wij در معادله بالا، سهم کالای j در فناوری تولید کالای i را نشان می‌دهد. wij بالاتر به معنای آن است که کالای j در تولید i اهمیت بیشتری دارد، در حالی که wij = 0 به این معنی است که کالای j نهاده‌ی مورد نیاز برای فناوری تولید i نیست. فرض بازدهی ثابت نسبت به مقیاس نیز ایجاب می‌کند که برای تمام بنگاه‌ها، مجموع سهم‌ها (مقدار w) برابر با یک باشد.اقتصاد همچنین شامل توده‌ی واحدی از مصرف‌کنندگان یکسان (همسان) است. هر مصرف‌کننده صاحب یک واحد نیروی کار است که می‌تواند توسط بنگاه‌ها برای اهداف تولیدی استخدام شود. ما فرض می‌کنیم که مصرف‌کننده‌ی نماینده، دارای ترجیحات متقارن کاب-داگلاس نسبت به n کالای تولید شده در اقتصاد است. یعنی همیشه درصد ثابتی از درآمدش را به صورت مساوی (برای ساده‌سازی مساله) خرج هر نوع کالا می‌کند، فارغ از اینکه آن کالا چقدر گران یا ارزان شود. برای مثال اگر قیمت کالایی دو برابر شود، او دقیقاً مصرفش را نصف می‌کند تا همان هزینه سابق را حفظ کند. در این حالت مطلوبیت کلان به صورت زیر حساب می‌گردد.که در آنci مقدار مصرف کالای i و b یک ثابت مثبت است.با توجه به این مساله هر بنگاه برای اینکه سودش را بهینه کند از قاعده زیر تبعیت می‌کند.که ω دستمزد نیروی کار و pi قیمت کالای i است. بدین ترتیب مدیر به اندازه از درامدش را صرف خرید کالای j می‌کند و به اندازه از درامدش را صرف نیروی کار و پرداخت حقوق می‌کند. توضیح شهودی این مطلب بدین صورت است که که در تابع کاب-داگلاس، توانِ هر بخش نشان‌دهنده میزانِ اهمیت و بهره‌وریِ حاشیه‌ایِآن ماده است و بهینه‌ترین حالت آن است که هر چیز دقیقاً به اندازه اهمیتِ آن هزینه شود و یا به عبارت دیگر هزینه اضافه بابت بک نهاده تا زمانی مطلوب است که به درآمد بیشتری از هزینه‌ای که بابت آن داده‌ایم منتهی شود.بدین ترتیب درآمد هر شرکت از دو بخش مصرف‌کننده نهایی که برابر سهم خرید آن بخش از دستمزد نیروی کار است[11] و سایر بخش‌ها که به صورت زیر نشان می‌دهیم.که si برابر درآمد شرکت و برابر قیمت کالا ضربدر مقدار فروش آن است.[12] انها حالا یک متغیر جدید به نام ضریب نفوذ و با علامت ζ تعریف می‌کنند که برابر است با سهمی که هر بخش از جریان پولی در جامعه صرف خرید آن می‌شود به طوری که si = piXi = ζiω . پس Xij = α*wij*ζi*Xj/ζj و li = (1 − α)ζi با جایگذاری این دو فرمول در معادله‌ای که میزان خروجی هر بنگاه را مشخص می‌کرد داریم:بدین طریق ما متغیر قیمت را حذف می‌کنیم. چرا که معمولا قیمت‌ها متغیر هستند ولی تناسب مصرف آنها برای هر بخش ثابت است.حال اگر از طرفین معادله لگاریتم بگیریم و xi برابر log(Xi) باشد به معادله زیر می‌رسیم.البته در فرمول فوق با توجه به اینکه bi یک ضریب ثابت و تنها برای همتراز کردن دو طرف معادله است آن را به گونه‌ای فرض می‌کنیم که مجموعش با مقادیر ثابت خنثی گردد و آنها را حذف نماید. راز این ساده‌سازی در این است که در اقتصاد کلان و تحلیل شبکه، ما به دنبال این هستیم که اگر متغیر A یک درصد تغییر کرد، متغیر B چند درصد تغییر می‌کند. این «درصد تغییرات» تحت تأثیر ضرایب ثابت (مثل bi) قرار نمی‌گیرد. بنابراین حذف آن‌ها با استفاده از انتخاب مقدار مناسب برای bi، پاسخ‌های نهایی مدل درباره اثرات شبکه را تغییر نمی‌دهد. بدین ترتیب می‌توان دریافت مدل داب-داگلاس حالت دیگری نیز از همان شبکه ماتریسی است که در قبل بیان شد.عجم‌اوغلو و همکاران در سومین گام، چارچوب خود را بر مدل‌های سرایت مالی تطبیق می‌دهند. در این مدل، گره‌ها «بانک‌ها» هستند و یال‌ها نشان‌دهنده «بدهی‌های بین‌بانکی» می‌باشند.در این اقتصاد، n مؤسسه مالی داریم که از طریق قراردادهای بدهی به هم متصل‌اند. هر بانک i مطالباتی از بانک j دارد. علاوه بر این مطالبات، هر بانک دارای یک دارایی خارجی (مانند سرمایه‌گذاری در بازار مسکن یا بورس) و یک شوک نقدینگی ϵi است.منطق بازپرداخت و غیرخطی بودن:تفاوت اساسی این مدل با مدل‌های قبلی در نحوه رفتار بانک هنگام مواجهه با بحران است. جریان وجوه نقد یک بانک(ci) حاصل‌جمع دارایی‌های خارجی، شوک‌های وارده و مبالغی است که از سایر بانک‌ها دریافت می‌کند. در اینجا سه سناریو رخ می‌دهد:۱. وضعیت عادی: اگر جریان نقد بانک کافی باشد، تمام بدهی خود را به دیگران می‌پردازد.۲. وضعیت نکول: اگر جریان نقد کمتر از بدهی باشد، بانک ورشکست شده و دارایی باقی‌مانده را به نسبت طلب بین طلبکاران تقسیم می‌کند .۳. ورشکستگی کامل: اگر دارایی منفی شود، طلبکاران هیچ‌چیزی دریافت نمی‌کنند.این رفتار باعث می‌شود تابع تعامل f در اینجا به یک تابع پله‌ای یا غیرخطی تبدیل شود:این معادله نشان می‌دهد که در سیستم‌های مالی، تعاملات فقط یک انتقال ساده نیست؛ بلکه یک آستانه وجود دارد. تا زمانی که شوک‌ها کوچک هستند، شبکه پایدار می‌ماند، اما به محض اینکه شوک از آستانه تحمل بانک عبور کند، «نکول» رخ می‌دهد و این ناتوانی در پرداخت، مانند یک دومینو به گره‌های بعدی منتقل می‌شود. آیا در چنین شبکه‌های پیچیده‌ای، همیشه به یک نقطه تعادل می‌رسیم؟آن‌ها نشان می‌دهند که تحت فرضیات منطقی (مانند انقباضی بودن تابع تعامل)، همیشه یک تعادل وجود دارد و به طور کلی این تعادل یکتا است.نکته ظریف اینجاست که در مدل‌های مالی (به دلیل غیرخطی بودن)، ممکن است چندین تعادل وجود داشته باشد، اما نویسندگان اثبات می‌کنند که حتی در آنجا هم تعادل در اکثر مواقع (Generically) یکتاست؛ یعنی احتمال بروز چندین تعادل پایدار در دنیای واقعی بسیار کم است.حالا که مدل ساخته شد، نویسندگان به سراغ تحلیل حساسیت می‌روند: اگر به عاملr شوک وارد شود، وضعیت کل اقتصاد چقدر تغییر می‌کند؟در اقتصادهای «نرم» (که توابع در آن‌ها مشتق‌پذیر هستند)، برای تحلیل اثر شوک‌های کوچک، از تقریب مرتبه اول (بسط تیلور) استفاده می‌شود. نتیجه این تحلیل، ما را به مفهوم کلیدی ماتریس لئونتیف L می‌رساند: L = (I - α W) ^ -1این ماتریس، قلب تپنده تحلیل شبکه است. در اینجا α نشان‌دهنده قدرت تعاملات است. ماتریس لئونتیف به ما می‌گوید که اثر یک شوک بر عامل i فقط ناشی از همسایگان مستقیمش نیست، بلکه از تمام مسیرهای موجود در شبکه عبور می‌کند:L = I + α *W + α^2*W^2 + α^3*W^3 + ………در این رابطه: I اثر مستقیم شوک بر خود عامل است.W*α اثر شوک بر همسایگان مستقیم و α^2*W^2 اثر شوک بر همسایگانِ همسایگان و این زنجیره تا بی‌نهایت ادامه می‌یابد. مرکزیت بوناچیچ: چه کسی در اقتصاد «مهم‌تر» است؟در نهایت، عجم‌اوغلو از مفهوم مرکزیت بوناچیچ[7] برای شناسایی گره‌های استراتژیک استفاده می‌کند. وی ثابت می‌کند که در سیستم‌های خطی، درجه گره شاخص ناقصی برای نقاط پر اهمیت است. به جای آن، مرکزیت بوناچیچ که نوعی مرکزیت بردار ویژه است، اهمیت گره را تعیین می‌کند. این شاخص نشان می‌دهد که یک گره نه فقط به خاطر تعداد یال‌های مستقیم، بلکه به خاطر قرارگیری در مجاورت سایر گره‌های مهم، دارای اهمیت است. از این رو مشابه page rank گوگل می‌باشد با این تفاوت که یشتر بر «انباشت» و «انعکاس» اثرات حاصل از شوک تمرکز دارد.تعریف: مرکزیت بوناچیچِ عامل i که با vi نشان داده می‌شود، مجموع اثراتی است که این عامل بر تمام اعضای دیگر شبکه (مستقیم و غیرمستقیم) می‌گذارد.طبق قضیه ۲ مدل، اگر شوک‌های وارده کوچک باشند، تغییر در خروجی کل اقتصاد (y) دقیقاً با میانگین وزنی شوک‌ها برابر است، که وزن هر شوک همان مرکزیت بوناچیچ آن گره است:این فرمول به ما می‌گوید برای پیش‌بینی بحران‌های بزرگ، نباید فقط به میانگین شوک‌ها نگاه کرد. اگر یک شوک منفی کوچک به گره‌ای وارد شود که مرکزیت بوناچیچ بالایی دارد (یعنی در شبکه بسیار مرکزی است)، اثر آن بر اقتصاد کلان بسیار ویرانگرتر از شوک بزرگی است که به یک گره حاشیه‌ای وارد می‌شود.اقتصادهای غیرنرم: مرز میان پایداری و فروپاشیدر دنیای واقعی، بسیاری از پدیده‌های اقتصادی دارای آستانه هستند. در یک اقتصاد غیرنرم، تابع تعامل f در برخی نقاط مشتق‌ناپذیر است. این یعنی سیستم تا یک نقطه خاص در برابر فشار مقاومت می‌کند، اما به محض عبور از آن نقطه، رفتار سیستم به طور ناگهانی و جهشی تغییر می‌کند. مدل سرایت مالی که پیش‌تر ذکر شد، بهترین مثال برای اقتصاد غیرنرم است. یک بانک را در نظر بگیرید. تا زمانی که دارایی بانک مثبت است، او تمام تعهداتش را ایفا می‌کند (تغییرات خطی). اما به محض اینکه دارایی به صفر می‌رسد، بانک «نکول» می‌کند. در این لحظه، تابع بازپرداخت دچار یک شکستگی می‌شود.این شکستگی به این معناست که یک شوک بسیار کوچک (مثلاً کاهش ۱ دلاری دارایی که منجر به منفی شدن تراز شود) می‌تواند ناگهان جریانی از بدهی‌های پرداخت‌نشده به ابعاد میلیون‌ها دلار را در شبکه به راه اندازد. در اینجا دیگر «تقریب تیلور» (که بر پایه مشتق است) کارایی ندارد، زیرا در نقطه شکست، مشتق تعریف نشده یا به بی‌نهایت میل می‌کند. برای ساده‌سازی ریاضی، می‌توان این توابع شکسته را با توابع نرمِ بسیار نزدیک به آن‌ها (Smooth Approximation) جایگزین کرد. او توضیح می‌دهد که اگر این تقریب را به درستی انجام دهیم، بینش‌های اقتصادی مدل (مانند نقش شبکه در انتشار بحران) تغییر نمی‌کند. این کار به ما اجازه می‌دهد هنوز از ابزارهایی مثل ماتریس لئونتیف استفاده کنیم، با این تفاوت که باید نسبت به «نقاط بحرانی» حساس باشیم.در اقتصادهای غیرنرم، شبکه دیگر فقط یک «منتقل‌کننده» نیست، بلکه یک تقویت‌کننده است. ویژگی‌های کلیدی این وضعیت عبارتند از:عدم تناسب: شوک‌های کوچک خرد می‌توانند منجر به نوسانات بزرگ کلان شوند.شکنندگی سیستمیک: سیستم ممکن است در ظاهر پایدار به نظر برسد، اما در نزدیکی یک نقطه غیرنرم (مانند آستانه ورشکستگی بانک‌های بزرگ)، به شدت شکننده باشد.تحلیل اقتصادهای غیرنرم به ما می‌گوید که چرا سیاست‌گذاران نباید صرفاً به میانگین‌ها و روندهای خطی دلخوش باشند. در شبکه‌های مالی، آنچه اهمیت دارد «فاصله تا آستانه نکول» در گره‌های مرکزی است. اگر شبکه غیرنرم باشد، یک جرقه کوچک در یک گره کلیدی می‌تواند کل گراف را به آتش بکشد، پدیده‌ای که در فیزیک به آن «تغییر فاز» و در اقتصاد به آن «بحران سیستمیک» می‌گوییم. تا اینجا مشخص شد شوک‌های کوچک چگونه در شبکه پخش می‌شوند. اما سوال بعدی که اینجا مطرح می‌شود این است که قبل از اینکه بدانیم شوک به کدام گره وارد می‌شود، کدام ساختار شبکه برای کل جامعه امن‌تر است؟او برای پاسخ به این سوال، «عملکرد کلان» را به صورت امید ریاضیِ وضعیت کلان تعریف می‌کند.حالت الف -تقریب خطی (مرتبه اول: اولین نتیجه (نتیجه ۱) کمی نا امیدکننده است. در تقریب مرتبه اول (خطی)، مقدار انتظاری خروجی کل همیشه صفر است)(E[y1st]] = 0). این یعنی در یک دنیای کاملاً خطی، مهم نیست شبکه چه شکلی باشد؛ چون فرض بر این است که شوک‌های مثبت و منفی همدیگر را خنثی می‌کنن و این همان چیزی بود که لوکاس فرض کرده بود. پس برای فهمیدن تفاوت شبکه‌ها، حتماً باید به سراغ تقریب مرتبه دوم (توابع غیرخطی) برویم. جایی که نظر لوکاس صدق نمی‌کند. حال اگر تابع کلان غیر خطی باشد دو حالت وجود دارد. بر حسب مشتق دوم تابع کلان که مثبت یا منفی است با دو حالت محدب و مقعر مواجه می‌شویم.اگر تابع مقعر باشد: یعنی جامعه از نوسانات و ریسک بیزار است. در این حالت، تلاطم زیاد، عملکرد اقتصاد را کاهش می‌دهد.اگر تابع کلان محدب باشد: یعنی تلاطم باعث بهبود عملکرد می‌شود (که در اقتصاد کمتر رایج است).وی ثابت می‌کند که عملکرد اقتصاد به توزیع مرکزیت بوناچیچ بین گره‌ها بستگی دارد و مجموع مجذور مرکزیت‌ها با واریانس مرکزیت‌ها رابطه مستقیم دارد. یعنی هرچه توزیع قدرت (مرکزیت) در یک شبکه نابرابرتر باشد (واریانس بالا)، اقتصاد در برابر شوک‌ها آسیب‌پذیرتر و عملکرد آن کمتر خواهد بود. بدین ترتیب دو نوع ساختار کلی ستاره‌ای شکل و یا شبکه منظم برای گرافها تعریف می‌گردد که هرکدام به صورت زیر تحلیل می‌گردد.شبکه ستاره‌ای: در این شبکه نابرابری در اوج است. یک گره (مرکز) بسیار قدرتمند و بقیه ضعیف هستند. واریانس مرکزیت در اینجا بیشینه است. بنابراین، در یک اقتصاد با تابع تجمیع مقعر، شبکه ستاره‌ای بدترین عملکرد و بیشترین تلاطم را دارد. یک شوک به مرکز، کل سیستم را تکان می‌دهد و گره‌های دیگر نمی‌توانند آن را خنثی کنند.شبکه منظم: شبکه‌هایی مانند «حلقوی» یا «کامل» که در آن هر گره تعداد یال‌های یکسانی دارد در این شبکه‌ها، همه گره‌ها مرکزیت بوناچیچ یکسانی دارند و واریانس مرکزیت صفر است. شبکه‌های منظم بهترین عملکرد را دارند. چون شوک‌ها به طور مساوی تقسیم می‌شوند و احتمال اینکه شوک‌های مثبت و منفی همدیگر را در کل شبکه خنثی کنند، در بالاترین حد خود است.شبکه‌های با ساختار منظمتعاملات غیرخطی: معمای پیوستگی شبکهدر بخش‌های قبلی، g که تابع کلان بود غیرخطی بود. حالا فرض می‌کنیم g خطی است اما f یعنی تابع تعامل بین گره‌ها غیرخطی باشد. این یعنی «نحوه اثرگذاری گره‌ها بر یکدیگر» دارای تقعر یا تحدب است. عجم‌اوغلو نشان می‌دهد که انحنای تابع f نشان‌دهنده بیزاری از ریسک در سطح خرد است. یعنی اگر مشتق دوم تابع تعامل منفی باشد سیستم تمایل دارد شوک‌ها را جذب و پخش کند (نیروهای تعدیل‌کننده) و اگر مثبت باشد یعنی سیستم تمایل دارد شوک‌ها را تقویت کند (نیروهای بحران‌زا).سوال: در یک شبکه کامل، همه بانک‌ها یا بنگاه‌ها به طور مساوی به یکدیگر متصل هستند. آیا این همه اتصال خوب است؟ پاسخ عجم‌اوغلو شگفت‌انگیز است: بستگی دارد که کجای نمودار باشید!۱. دنیای مقعر (امنیت در اتصال): وقتی تابع تعامل در اطراف نقطه تعادل، مقعر است. در این حالت، «شبکه کامل» بهترین عملکرد را دارد. چون شوک‌های وارده به یک گره، بین تمام گره‌های دیگر تقسیم و میرا می‌شود و هیچ‌کس آسیب جدی نمی‌بیند. (ایده Allen & Gale, 2000).۲. دنیای محدب (خطر در اتصال): ولی وقتی تابع تعامل تغییر شکل داده و در اطراف نقطه تعادل، محدب می‌شود. (مثل زمان رکود) در این حالت، «شبکه کامل» ناگهان به بدترین ساختار تبدیل می‌شود. چون حالا اتصالات زیاد مانند کانال‌هایی برای انتقال آتش عمل می‌کنند. یک جرقه کوچک در یک بانک، به جای پخش شدن، در بقیه بانک‌ها تقویت شده و منجر به «نکول زنجیره‌ای» می‌شود.او با این مدل، تناقض بین دو دیدگاه معروف را حل می‌کند:دیدگاه اول (Allen & Gale, 2000): اتصالات بیشتر مساوی ثبات بیشتر. (این در حالت مقعر درست است.)دیدگاه دوم (بحران‌های آبشاری): اتصالات بیشتر مساوی سرایت سریع‌تر بحران. (این در حالت محدب درست است.)جمع‌بندی:این پژوهش نشان داد که بسیاری از متغیرهای اقتصادی محصول ساختار شبکه‌ای اقتصاد هستند. برخلاف مدل‌های سنتی، شوک‌های قیمتی به‌صورت خطی پخش نمی‌شوند؛ بلکه از مسیرهای خاصی در زنجیره تأمین عبور کرده و در «هاب‌های صنعتی» تقویت یا تضعیف می‌شوند. بر اساس مدل عجم‌اوغلو و همکاران (2015)، در شبکه‌های نامتوازن، حتی شوک‌های خرد محلی نیز می‌توانند به دلیل روابط غیرخطی و حلقه‌های بازخورد، به بحران‌های سیستمیک و تورم کلان تبدیل شوند.یافته‌های محوری تحقیق به شرح زیر است:اهمیت توپولوژی شبکه: تاب‌آوری اقتصاد در برابر تورم بیش از آنکه به تنوع صنایع وابسته باشد، به نحوه اتصال آن‌ها بستگی دارد. شبکه‌هایی با ضریب خوشه‌بندی بالا، در انتقال منابع و اطلاعات سریع‌تر عمل می‌کنند، اما هم‌زمان می‌توانند کانالی برای سرایت سریع بحران باشند (Qiao & Ji, 2021).پارادوکس پیچیدگی: در سطح بنگاه، افزایش بی‌رویه تعداد تأمین‌کنندگان (متوسط درجه بالا) لزوماً به معنای امنیت نیست، بلکه می‌تواند با افزایش هزینه‌های نظارتی، ارزش بازار شرکت را کاهش دهد؛ در حالی که «تناسب ساختاری» و فشردگی روابط، کلید حفظ ثبات مالی است(Orenstein & Zhang, 2023).ناهمگنی زمانی و پویایی: فرآیند جایگزینی نهاده‌ها در صنایع زمان‌بر است (Goodwin, 1947). این تأخیرهای زمانی باعث می‌شود تورم به صورت «خوشه‌ای» و با رفتارهای غیرخطی ظاهر شود که تنها با ابزارهایی نظیر مرکزیت بوناچیچ قابل شناسایی است.در نهایت، برای بومی‌سازی این رویکرد در ایران، انتقال از تحلیل‌های استاتیک لئونتیف به سمت مدل‌های شبکه‌ای داینامیک ضروری است. شناسایی صنایع گلوگاهی که شوک‌های قیمتی را به سایر بخش‌ها پمپاژ می‌کنند، مستلزم به‌روزرسانی جداول داده-ستانده و استفاده از آزمون‌های تنش برای پیش‌بینی مسیرهای سرایت تورم در ساختار اقتصادی کشور است. مراجع انگلیسی:1. Acemoglu, D., Akcigit, U., & Kerr, W. (2016). Networks and the Macroeconomy: An Empirical Exploration. In M. Eichenbaum & J. Parker (Eds.), NBER Macroeconomics Annual 2015, Volume 30 (pp. 273-335). University of Chicago Press2. Acemoglu, D., Ozdaglar, A., & Tahbaz-Salehi, A. (2015). Networks, shocks, and systemic risk. The Oxford Handbook of the Economics of Networks, 457-486. Oxford University Press.3. Afrouzi, H., & Bhattarai, S. (2023). Inflation and GDP dynamics in production networks: A sufficient statistics approach (NBER Working Paper No. 31218). National Bureau of Economic Research. https://doi.org/10.3386/w31218 (NBER)4. Allen, F., & Gale, D. (2000). Financial contagion. Journal of Political Economy, 108(1), 1-33. https://doi.org/10.1086/2621095. Bilgin, N. M. (2025). Inflation diffusion through production networks. ScienceDirect.Duong, T. H., & Liu, W. (2025). The trade‑inflation nexus: The role of production networks [Manuscript]. SSRN.6. Bilgin, N. M. (2025). Inflation diffusion through supply chains. International Economics, 184, Article 100627. https://doi.org/10.1016/j.inteco.2025.100627 (OUCI)7. Goodwin, R. M. (1947). Dynamical coupling with especial reference to markets having production lags. Econometrica, 15(3), 181–204.8. Hirose, Y., Katayama, M., Ueda, K., & Watanabe, K. (2025). Inflation dynamics in production networks (CAMA Working Paper No. 22/2025). Centre for Applied Macroeconomic Analysis, Crawford School of Public Policy, The Australian National University. (IDEAS/RePEc)9. Leijonhufvud, A. (1997). Macroeconomics and complexity: Inflation theory. In B. Arthur, S. Durlauf, & D. Lane (Eds.), The economy as an evolving complex system II (Vol. 27). Addison-Wesley.10. Leontief, W. W. (1951). The structure of American economy, 1919–1939: An empirical application of equilibrium analysis (2nd ed.). Oxford University Press.11. Mantegna, R. N. (1999). Hierarchical structure in financial markets. The European Physical Journal B, 11(1), 193–197.12. Orenstein, P., & Zhang, R. (2023). How does supply network structure influence firms’ financial performance during disruption?. Entropy, 25(3), 430. https://doi.org/10.3390/e2503043013. Qiao, N., & Ji, C. (2021). Industry network structure determines regional economic resilience: An empirical study using stress testing. Sustainability, 13(3), 1146. مراجع فارسیمرکز آمار ایران.(۱۳۹۵). جدول داده–ستانده سال ۱۳۹۵. تهران: مرکز آمار ایران. [1] Mantegna[2] Acemoglu[3] Leontief[4] Input-output linkage[5] Supply and use[6] Related Variety[7] certainty equivalence[8] یعنی همه بازیکنان از توابع سود یکدیگر و ساختار شبکه باخبرند.[9] یعنی عوامل تولید دقیقا به شکل ضرب توانی باشند[10] یعنی با دوبرابر شدن همه نهاده‌ها تولید هم دو برابر می‌شود[11]توجه کنید فرض کردیم مصرف‌کننده «متقارن» است و بودجه‌اش را مساوی تقسیم می‌کند[12] فرض گردیده است همه کالا فروش می‌رود و چیزی در انبار نمی‌ماند[13] Bonacich Centrality

معرفی و بررسی معماری سه نرم‌افزار فروشگاهی «متن‌باز» SockShop، OpenCart و Saleor

سید محمد مهدی حسینی — Sun, 17 Aug 2025 17:25:49 +0330

در این نوشتار تلاش می‌گردد تا از روی مطالعه و تحلیل کد مشخصات معماری در سه نرم‌افزار فروشگاهی اوپن سورس به نامهای sockshop و opencart و saleor شناسایی و در صورت امکان با هم مقایسه گردند. هرچند در ابتدا باید اشاره کرد همانطور که سیمون براون می‌گوید:«کد به تنهایی نمی‌تواند تمام داستان را تعریف نماید..»در این پروژه اصلی‌ترین منبع اطلاعاتی ما برای بررسی دو نرم‌افزار قطعه کدهای داخل دو نرم‌افزار است .البته در لابلای مباحث نیز از مستندات مربوط به نرم‌افزارهای فوق نیز استفاده شده است.اهداف :در این پژوهش تلاش گردیده است معماری نرم‌افزارها از نظر ویژگیهای زیر بررسی گردند.1- رویکرد و الگوی طراحی معماری نرم‌افزار2- معماری داده نرم‌افزار3- معماری ارتباطات و پیام‌رسانی بین مدولهای مختلف نرم افزار4- سایر ویژگیهای معماری نرم‌افزارها و مقایسه تطبیقی آنها با یکدیگرنرم افزار sockhopنرم افزار sockshop یک فروشگاه انلاین غیرحرفه‌ای برای فروش جوراب هست که با هدف نمایش و آزمایش معماری میکروسرویس طراحی شده است. نرم افزار دارای 15 نود است. ولی میکروسرویسهای اصلی آن به شرح زیر هستند.میکروسرویسهای نرم افزار sockshop (مرجع: مستندات رسمی نرم افزار)مشخصات میکروسرویسهای نرم افزار sockshopنصب و استقرار نرم‌افزار Sockshop:نرم افزار sockshop یک نرم افزار اوپن سورس هست که بر روی گیتهاب نسخه‌های مختلفی از آن موجود است. برای استقرار نرم‌افزار فعلی از گیتهاب به آدرس ocp-power-demos/sock-shop-demo: A multiarchitecture port of the Sock Shop Microservices application شاخه master بر روی سیستم کلون گردید. سپس در پوشه deploy از نرم افزار که فایل docker.compose.yml موجود بود ابتدا دستور docker compose build و سپس دستور docker compose up اجرا شد تا نرم افزار نصب گردد. در همان پوشه نیز یک فایل docker.compose.monitoring.yml هست که از طریق آن سیستم مونیتورینگ نرم افزار با دستور docker compose -f docker-compose.monitoring.yml up -d اجرا گردید.تصویری از رابط کاربری نرم افزار sockshopچالشهای نصب نرم‌افزار sockshop:برای نصب نرم‌افزار باید پورتهای 80 و 8080 آزادسازی گردد. برای اینکار می‌توان با دستور netstat -ano در ترمینال برنامه‌هایی که آن پورت را اشغال نموده‌اند جستجو و سپس با استفاده از دستور taskkill در ترمینال در حالت administrator پورت مذکور را آزاد نمود. همچنین برخی وابستگیهای موردنیاز پروژه از سایتهایی تامین می‌گردند که برای IPهای ایران تحریم هستند و با استفاده از dns های سایتهایی نظیر شکن در حالت غیررایگان تنها امکان دانلود آنها فراهم می‌گردد. برخی خطاها و تنظیمات جزئی نیز با وبرایش فایل docker.compose.yml برطرف گردید.اجرای نرم‌افزار sockshop:بپس از اجرای کانینر برنامه بر روی داکر نرم افزار از طریق مرورگر و از آدرس a.localhost رابط کاربری نرم‌افزار در دسترس خواهد بود. البته به جای کلمه a هر کلمه دیگری می‌تواند جایگزین گردد؛ ولی عبارت localhost خالی ما را به صفحه‌ای که مربوط به راهنمای داکر هست می‌برد. در صورت نصب مونیتورینگ هم آدرس localhost:9090 صفحه Prometheus و آدرس localhost:3000 صفحه Grafana را باز می‌کند. آدرس localhost:8080 نیز صفحه traefik را باز می‌کند. به منظور مشاهده چگونگی عملکرد نرم‌افزار در برابر بارهای ناشی از ترافیک شبکه‌ای بارهای ترافیکی به صورت مصنوعی با locust ایجاد گردید.ویژگیهای معماری نرم‌افزار sockshop:استفاده از یک Reverse Proxy به عنوان سرور واسطه‌ای بین کاربران و سرورهای اصلی که درخواستهای کاربران را به سرویسهای مناسب هدایت می‌کند و ضمن افزایش امنیت، مدیریت بار و کنترل ترافیک بین سرویس‌ها را بر عهده دارد.استفاده از CI travis به عنوان سرویس یکپارچه‌سازی مداوموجود پوشه‌های مربوط به تست نرم‌‌افزار در کنار هر میکروسرویساستفاده از دیتابیسهای جداگانه برای هر میکروسرویسنمایش مدلهای ارتباطی و پایگاه داده برای هر میکروسرویس (مرجع: صفحه رسمی نرم‌افزار در گیتهاب)مدلهای ارتباطی بین سرویس‌ها در نرم افزار Sock Shopدر معماری میکروسرویس‌ها، هر سرویس به طور مجزا و مستقل عمل می‌کند، اما برای انجام وظایف پیچیده باید با سایر سرویس‌ها ارتباط داشته باشد. Sock Shop از سه روش اصلی برای ارتباط بین سرویس‌ها استفاده می‌کند: 1- ارتباط هم‌زمان به طریق RESTful API مبتنی بر HTTP : در این روش نرم‌افزار وقتی بدان می‌رسد منتظر می‌ماند تا پاسخ را دریافت نماید و خطهای بعدی برنامه را پردازش نمی‌نماید. در برنامه sockshop کلیه درخواست‌ها ابتدا با استفاده از future غیرهمزمان ارسال می‌گردند. ولی وقنی نرم‌افزار به پاسخ آن نیاز پیدا می‌کند با دستور get درخواست‌ها همزمان می‌گردد. برای مثال به بخشی از کد فایل orderscontroller.java از میکروسرویس orders به شرح زیر اشاره می‌گردد.در خطوط 65 تا 73 از تصویر بالا که بخشی از فایل مذکور است ابتدا سه درخواست غیرهم‌زمان (Asynchronous) برای دریافت اطلاعات مشتری، کارت و محصول از یک سرویس خارجی ارسال می‌کند. Item.customer آدرس سرویس مشتری است و getResource() یک درخواست HTTP GET است. به علت استفاده از Future پردازش ابتدا منتظر دریافت پاسخ نمی‌ماند. اما وقتی به خط 76 می‌رسد چون متغیر amount باید مقداردهی شود و به جواب آن نیاز دارد برنامه متوقف می‌گردد و منتظر پاسخ می‌ماند. لذا درخواست همزمان می‌گردد و درخواستهای زیاد می‌تواند بار سنگینی روی سرویسهای مقصد ایجاد کند.چرا نیاز به ارتباط همزمان داریم: به طور مثال برای پردازش سفارش تا زمانی که مبلغ آن مشخص نگردد نمی‌تواند وارد مرحله پرداخت شود. برنامه باید متوقف شود تا وارد مرحله بعدی که shipment است گردد.2- ارتباط غیر همزمان HTTP بین سرویس‌ها: در این حالت درخواست‌ها به سرویس مقصد ارسال می‌شوند اما پردازش منتظر دریافت پاسخ فوری نمی‌ماند. برای این منظور از Future و @Async در جاوا استفاده شده است. برای مثال می‌توان به قطعه کد زیر از همان فایل قبلی اشاره کرد:زمانی که سرویس Orders یک سفارش جدید ثبت می‌کند، به جای تماس مستقیم و انتظار برای پاسخ از سرویس Shipping، یک درخواست غیرهمزمان HTTP در خطوط 100 تا 103 قطعه کد فوق ارسال می‌شود. درخواست به سرویس Shipping ارسال می‌شود، اما تا زمان دریافت پاسخ، پردازش متوقف نمی‌شود. پس از پردازش، سرویس Shipping نتیجه را برمی‌گرداند و پاسخ دریافت می‌شود. در این حالت پردازش‌های دیگر در سیستم متوقف نمی‌شوند و ادامه پیدا می‌کنند. اما برای مدیریت خطاهای شبکه نیاز به مدیریت زمان انتظار و خطاهای مربوط به تاخیر در پاسخگویی سرویس‌ها وجود دارد. این کار در خطوط 108 تا 113 قطعه کد فوق با درنظر گرفتن یک مقدار زمانی برای انقضای دستور پیش‌بینی شده است.3. ارتباط غیر همزمان با RabbitMQ: در سرویس shipment درخواستهای حمل و نقل به صورت کاملاً غیر همزمان و با RabbitMQ انجام می‌شود، به این معنی که پردازش منتظر پاسخ از سرویس نمی‌ماند و درخواست‌ها به صف پیام‌محور ارسال می‌شوند تا پردازش در زمان مناسب انجام گیرد. این کار از طریق RabbitTemplate انجام می‌شود که یک کلاس در SPRING AMQP است که ارتباط با RabbitMQ را ساده می‌کند. در این شیوه هیچ Future یا get(timeout, TimeUnit.SECONDS) وجود ندارد که باعث توقف پردازش می‌شد، اینجا هیچ توقفی وجود ندارد و درخواست‌ها کاملاً غیرهم‌زمان باقی می‌مانند. قطعه کد زیر بخشی از فایل shippingcontroller.java در میکروسرویس shipping است.در قطعه کد فوق درخواست را به یک صف مشخص، مانند shipping-task، اضافه می‌کند. در لحظه‌ی ارسال پیام، پردازش ادامه می‌یابد بدون اینکه منتظر تأیید یا پاسخ باشد. در نتیجه، این مدل باعث افزایش مقیاس‌پذیری و عملکرد بهینه سیستم می‌شود. برای بررسی وضعیت RabbitMQ، این نرم‌افزار از یک مکانیسم Health Check استفاده می‌کند که با اجرای rabbitTemplate.execute(ChannelCallback) اطلاعات سرور RabbitMQ را دریافت می‌کند تا اطمینان حاصل شود که پیام‌ها به درستی پردازش خواهند شد. همچنین، اگر صف پیام در دسترس نباشد، سیستم به‌طور خودکار وضعیت را مدیریت می‌کند و خطای AmqpException را کنترل می‌کند. این معماری باعث می‌شود که فرآیند حمل‌ونقل بدون توقف پردازش و به‌صورت کاملاً غیرهم‌زمان انجام شود، به طوری که پیام‌ها ارسال می‌شوند و در زمان مناسب توسط مصرف‌کنندگان RabbitMQ پردازش خواهند شد. این مدل به‌خصوص در معماری میکروسرویس بسیار کارآمد است، زیرا مانع از ایجاد وابستگی‌های هم‌زمان بین سرویس‌های مختلف می‌شود و اجازه می‌دهدRabbitMQ به عنوان واسطه‌ای برای مدیریت صف‌های پردازش سفارشات عمل می‌کند.Queue-Master مسئول مدیریت صف‌ها در RabbitMQ است. این سرویس نظارت می‌کند که پیام‌ها پردازش شوند و از ازدحام در صف‌ها جلوگیری شود. همچنین، زمانی که بار پردازشی بالا باشد، می‌تواند پیام‌ها را مدیریت کند تا سرویس Shipping با فشار زیاد مواجه نشود.معماری داده‌های برنامه:با توجه به طراحی نرم‌افزار بر مبنای میکروسرویس هر سرویس دارای یک دیتابیس جداگانه هست. برای سرویس کاربر، سبد خرید و سفارشات از دیتابیس MongoDB استفاده شده و برای سرویس کاتالوگ که سرویس نمایش کالاهای موجود در فروشگاه است از دیتابیس MySQL استفاده شده است.دیتابیسهای انتخاب شده چه ویژگیهایی دارند؟علت انتخاب نوع دیتابیسهای فعلی برای فروشگاه چیست؟نحوه فراخوانی اطلاعات از دبتابیس چگونه است؟معرفی سیستم مدیریت پایگاه داده MONGODB برای میکروسرویسهای سفارشات، کاربران و سبد خرید: برای مشاهده ساختار دیتابیس در این میکروسرویس‌ها با توجه به نگارش استفاده شده از پایگاه داده که یک نگارش نسبتاً قدیمی بود از نرم‌افزار MongoDB Compass نگارش 1.18 استفاده گردید. در تصویر زیر دیتابیسهای موجود برای میکروسرویس کاربران و جداول آن که توسط MongoDb Compass کاوش شده است نشان داده شده است.در تصویر زیر نیز محتویات جدول آدرس ها نشان داده شده است که همانطور که مشاهده می‌شود ساختار آن مشابه فایلهای JSON است که در این معماری BSON نامیده می‌شود.نحوه ذخیره سازی آدرس در جدول آدرس هابرای ارتباط با پایگاه داده یک فایل اینترفیس تهیه شده است. در این اینترفیس که db.go نام دارد متدهای دسترسی به پایگاه داده تعریف شده است. مثلا برای میکروسرویس user متدهای ایجاد یک کاربر جدید، خواندن یک کاربر با نام، ایجاد آدرس، خواندن آدرس و ...... تعریف شده است. همچنین یک فایل دیگر با نام mongodb.go وظیفه مقداردهی اولیه و مشخصات پایگاه داده مانند hostname و password و همچنین اسکیمای دیتابیس و مدیریت خطاها تعریف شده است.در فراخوانی دیتابیس انتزاع رعایت گردیده است؛ ولی در تعریف عملیات CRUD و پرس‌وجوها این انتزاع رعایت نشده است. برای مثال برای فراخوانی کاربر از پایگاه داده قطعه کد زیر نوشته شده استدر خط 206 دستور قید شده وابسته به نوع پایگاه داده است که MongoDB است.استفاده از این نوع معماری که یک نوع پایگاه داده NoSQL است سرعت خواندن و نوشتن را بالا می‌برد. ضمن آنکه مقیاس‌پذیری افقی را ممکن می‌سازد و در بارهای کاری سنگین به خوبی مقیاس‌پذیر است. اما در صورتی که جداول بخواهند به یکدیگر JOIN گردند با پیچیدگیهای بیشتری روبرو است و امکان استفاده از کلید خارجی مشابه پایگاه داده‌های پشتیبانی‌کننده از دستورهای SQL وجود ندارد.استفاده از سیستم مدیریت پایگاه داده MySQL برای میکروسرویس catalogue: در این میکروسرویس از سه جدول استفاده شده است. جدول اول مشخصات کالا است. جدول دوم مشخصات برچسب کالا است و جدول سوم حاصل join شدن دو جدول مذکور است. برای مشاهده جداول مذکور از طریق CMD وارد کانتینر مربوط به دیتابیس مذکور شده و از طریق دستور show databases و show tables جداول این کانتینر طبق تصویر زیر استخراج شده است.در معماری این دیتابیس با توجه به آنکه نیازمند اتصال دو جدول به یکدیگر و استفاده از کلید خارجی بوده است از معماری MySQL استفاده شده است تا امکان مذکور فراهم گردد. این ساختار ضمن خفظ سازگاری و پشتیبانی از ویژگیهای ACID امکان ایجاد کوئریهای پیچیده‌تر با دستورات SQL را فراهم می‌سازد. اما سرعت خواندن و نوشتن پایین‌تری دارد و فاقد مقیاس‌پذیری افقی است.با توجه به نوع معماری نرم‌افزار که بر مبنای میکروسرویس است امکان join شدن جداول صفحه خرید به سفارشات و همین‌طور مشخصات محصول وجود ندارد. پس در هر بار که یک محصول برای سبد خرید انتخاب می‌شود باید مشخصات کاربر و محصول و قیمت آن برای میکروسرویس سبد خرید ارسال می‌گردد و این باعث افزونگی داده می‌شود که از تلعات انتخاب معماری میکروسرویس است. یعنی اطلاعاتی که در یک جدول دیگر است مجددا باید در جدول دیگری ذخیره شود. حال آنکه در صورتی که جداول به یکدیگر join می‌گردیدند کافی بود که تنها شناسه کاربر و محصول ارسال گردد. اما چون سرویس سبد خرید مستقل از سرویس سفارش و سرویس کاتالوگ محصول است چنین امری ممکن نیست. لذا حجم اطلاعات ارسالی بین مدولهای برنامه افزایش می‌یابد و نیازمند پایگاه داده‌ای هستیم که سرعت خواندن و نوشتن بالایی دارد. ویژگیی که پایگاه داده Mongo از آن برخوردار است.معماری نرم افزار opencart:این نرم افزار بر خلاف نرم افزار sockshop یک نرم افزار حرفه‌ای است که به صورت مونولیت البته در دو بخش فرانت و بکند به زبان php طراحی شده است. در بخش رابط کاربری از زبان جاوا اسکریپت نیز استفاده شده است و دارای دو رابط کاربری برای ادمین و کاربری عادی می‌باشد. به منظور نصب آن نرم‌افزار از روی گیتهاب بر روی هارد دستگاه کلون گردید و سپس با داکر طبق دستورالعمل داده شده نصب گردید. اطلاعات کاربری نظیر نام کاربری و رمز عبور برای دسترسی به پایگاه داده و ادمین نرم‌افزار نیز از طریق فایل ‌docker.compose.yml در دسترس است. در نهایت پس از اجرای کانتینرها نرم‌افزار بر روی 6 کانتینر و سه پورت 80، 8080 و 3306 از طریق آدرس a.localhost برای کاربر عادی و localhost/admin برای ادمین برنامه در دسترس است. در ادمین نرم‌افزار ضمن مونیتورینگ برنامه و رصد مشاهدات و معاملات کاربران امکان تعریف کالاها و ویرایش رابط کاربری نرم افزار مهیاست.صفحه واسط کاربری نرم‌افزار opencartتصویری از صفحه داشبورد مدیریتی فروشگاه opencartمعماری نرم‌افزار:فایلهای اصلی مربوط به نرم‌افزار در مسیر upload/catalog و در داخل چهار پوشه language، model، view و control قرار گرفته است که نشان دهنده بهره‌گیری آن از الگوی طراحی معماری MVC است.1. مدل (model): مسئول ارتباط با پایگاه داده است. داده‌ها را پردازش و بازیابی می‌کند. اطلاعاتی مانند محصولات، دسته‌بندی‌ها، کاربران و سفارش‌ها را از دیتابیس دریافت می‌کند. 2. کنترل (controller): درخواست‌های کاربر را دریافت کرده و پردازش می‌کند. داده‌ها را از مدل (model) می‌گیرد و به view (template) ارسال می‌کند. 3. دید (view): اطلاعات پردازش‌شده را در قالبی که توسط فایلهای با پسوند twig تعریف شده است به صورت HTML نمایش می‌دهد. برای مثال زمانی که کاربر روی محصولی کلیک می‌کند :⬅ controller/product.phpاجرا می‌شود ⬅ model/catalog/product.php` اطلاعات محصول را دریافت می‌کند⬅ view/template/product.twig قالب داده‌ها را نمایش می‌دهد. یا برای مثال زمانی که کاربر یک سفارش ایجاد می‌نماید مراحل زیر طی می‌شود: لایه کنترلر: دریافت داده‌های مورد نیاز سفارش از سبد خرید و آدرس و ... و ارسال به مدل برای ذخیره از طریق قطعه کد زیر در فایل catalog/controller/checkout/confirm.phpلایه مدل: ذخیره‌سازی کامل اطلاعات سفارش در پایگاه داده از طریق قطعه کد زیر در فایل catalog/model/checkout/order.phpلایه ویو: نمایش خلاصه‌ی سفارش به کاربر برای تایید نهایی از طریق فایل catalog/view/template/checkout/confirm.twigبررسی پایگاه داده برنامه opencartواکاوی پایگاه داده برنامه نشان میدهد بر خلاف برنامه sockshop که دارای دیتابیسهای متعدد بود دارای تنها یک مرکز پایگاه داده است که در کانتینر mySQL-1 گردآوری شده است. بررسی داخل آن نشان می‌دهد که دارای 149 جدول در دیتابیس opencart است که اتصالات و روابط بسیار پیچیده‌ای دارند که تصویر شمای آنها در پیوست آمده است. دیتابیسهای داخل این پایگاه داده و برخی از مهمترین جداول آن به شرح زیر است:یکی از مکانیسمهای به کار برده شده در این برنامه برای کاهش بار روی پایگاه داده و افزایش سرعت پاسخ‌دهی کش‌کردن (cashing) است. برای مثال در تعریف تابع getProducts که شامل یک کوئری برای اخذ اطلاعات از پایگاه داده است بدین ترتیب از کش کردن دیتا استفاده شده است.در تابع getProducts از فایل product.php در مسیر opencart\upload\catalog\model\catalog نوشته شده است:ابتدا در خط 243 از کل متن SQL یک تابع از نوع هش (Hash) انجام می‌شود تا کلیدی یکتا برای ذخیره یا بازیابی کش ساخته شود. این کار تضمین می‌کند که هر کوئری متفاوت، کلید منحصر به‌فردی در کش داشته باشد. سپس در خط 245 تلاش می‌شود داده محصولات با این کلید از کش خوانده شود. اگر قبلاً کوئری مشابهی اجرا شده باشد، نتیجه آن در کش ذخیره شده و این خط آن را بازیابی می‌کند. شرط if بررسی می‌کند که آیا داده‌ای از کش گرفته شده است یا خیر. اگر کش وجود نداشته باشد یعنی $product_data تهی باشد، نشان می‌دهد یا کش پاک شده است یا اولین بار است که این کوئری اجرا می‌شود. در این صورت، کوئری SQL اجرا می‌شود و نتیجه‌اش از پایگاه داده گرفته می‌شود.بررسی تکنیک به کار گرفته شده برای کش: کش بر اساس یک کلید یکتا ساخته می‌شود. این کلید از ترکیب شناسه فروشگاه، زبان، دسته‌بندی و هش پارامترهای ورودی ساخته می‌شود. سپس داده با کلید product.{key} ذخیره یا بازیابی می‌شود. کش در مسیر system/storage/cache/ به صورت فایل‌هایی با قالب cache.product.{hash}. ذخیره می‌شود. محتوای این فایل‌ها معمولاً داده‌ی serialize شده یا json از آرایه‌های PHP هستند. هیچ مکانیزم invalidation (بی‌اعتبار کردن کش) در این کد مشاهده نمی‌شود. یعنی اگر محصول جدید اضافه شود یا یکی ویرایش شود، ممکن است کش قدیمی باشد. به‌صورت معمول، این invalidate باید هنگام تغییر داده (مثل ویرایش محصول یا موجودی) انجام شود.مثلاً در تابع editQuantity هیچ پاک‌سازی کش انجام نشده است. بهتر است پس از تغییر داده، کش مرتبط با آن محصول یا لیست محصولات پاک شود. لذا اگر فایل کش وجود داشته باشد، از آن استفاده می‌شود حتی اگر قدیمی باشد.نرم‌افزار SaleorSaleor یک پلتفرم تجارت الکترونیک متن‌باز است که برای ساخت فروشگاه‌های آنلاین طراحی شده است. این پلتفرم به صورت بدون واسط کاربری (Headless) عمل می‌کند، به این معنی که بخش بک‌اند (backend) و بخش فرانت‌اند (frontend) آن از یکدیگر جدا هستند. این جداسازی به توسعه‌دهندگان امکان می‌دهد تا از هر فناوری دلخواهی برای ساخت رابط کاربری فروشگاه (وب‌سایت، اپلیکیشن موبایل، و غیره) استفاده کنند، زیرا تمام داده‌ها و عملکردهای اصلی از طریق یک رابط برنامه‌نویسی کاربردی (API) در دسترس هستند.Saleor تمامی عملکردهای مورد نیاز یک فروشگاه آنلاین، از جمله مدیریت محصولات، سفارشات، پرداخت‌ها و موجودی انبار را فراهم می‌آورد.فحه رابط کاربری نرم افزار Saleorصفحه پنل مدیریتی فروشگاه Saleorنظام Saleor در بخش‌های اصلی مدیریت فروشگاه مثل سفارش، سبد خرید، کاربران و ..... بر خلاف دو نرم افزار قبلی که در قالب سرویسهای متفاوتی تهیه شده بودند یه صورت یکپارچه (monolithic) است. هرچند تمام آنها در قالب مدولهای جداگانه و به صورت یک مولفه تعریف شده‌اند. ولی ارتباط آنها بر خلاف موارد قبلی که از طریق روشهای متنی مثل http تعریف می‌شد با import سایر بخشها و دسترسی به متغیرهای آنها انجام می‌گردد. این امر امکان آنکه مدولهای مختلف برنامه در زبانهای مختلف نوشته شود را از نرم‌افزار سلب نموده است. لذا تمام بخش ‌بک‌اند برنامه با زبان پایتون نوشته شده است. البته saleor همچنان در بخش ارتباط بین فرانت و بک‌اند نرم‌افزار و همچنین افزونه‌هایی نظیر مکانیسمهای پرداخت از طریق API و به روش GraphQL ارتباط برقرار می‌کند.هسته اصلی Saleor یک برنامه واحد است که تمام منطق کسب‌وکار را در خود جای داده است. این بخش شامل موارد زیر است:مدل‌های داده‌ای (Data Models): تمام داده‌های مربوط به محصولات، سفارشات، مشتریان، و انبارداری در یک پایگاه داده (PostgreSQL) ذخیره می‌شوند. این مدل‌ها به صورت یکپارچه با چارچوب جنگو (Django) مدیریت می‌شوند.منطق کسب‌وکار (Business Logic): فرآیندهای اصلی مانند ثبت سفارش، مدیریت پرداخت، محاسبه قیمت و موجودی، همگی در یک کدبیس واحد قرار دارند.هسته API: GraphQL API که به عنوان تنها نقطه ورودی برای ارتباط با هسته نرم‌افزار است.نصب و استقراربرای نصب فروشگاه saleor دو برنامه باید نصب شود. برنامه اول بخش داشبورد مدیریتی پروژه است که از طریق داکر و طبق راهنمایی که در سایت رسمی پروژه به آدرس http://docs.saleor.io/quickstart/running-locally نیز آمده است نصب گردید. برنامه دوم بخش فرانت نرم‌افزار است که پیچیدگی بیشتری دارد. چون وقتی برنامه‌ای بر روی داکر نصب می‌گردد در یک حالت انزوا قرار گرفته و با دیگر برنامه‌های نصب شده بر روی همان دستگاه از طریق localhost ارتباط برقرار نمی‌کند. در نهایت داشبورد مدیریتی از آدرس localhost:9000 و نرم‌افزار فروشگاهی از آدرس http://172.19.0.1:3000 قابل دسترس گشت.معماری نرم‌افزار Saleorپلتفرم تجارت الکترونیک Saleor یک سیستم API-محور و Headless است که بر پایه معماری GraphQL و با استفاده از زبان برنامه‌نویسی پایتون و فریم‌ورک جنگو (Django) توسعه یافته است. این پلتفرم از پایگاه داده PostgreSQL برای ذخیره‌سازی اطلاعات استفاده می‌کند و از Redis و Celery برای مدیریت عملیات ناهمگام بهره می‌برد. معماری آن به صورت ماژولار طراحی شده و از طریق سیستم پلاگین و وب‌هوک، قابلیت‌ ادغام با سایر سرویس‌ها را فراهم می‌آورد. Saleor از قابلیت‌های چندکاناله (Multi-channel) پشتیبانی می‌کند که امکان مدیریت چندین کانال فروش مستقل را در یک سامانه فراهم می‌سازد. در ادامه این بخش موارد فوق شرح داده می‌شود.نمایش مدول‌بندی و مولفه های نرم افزار saleor (مرجع: deepwiki.com/saleor/saleor/1-overview)رویکردهای معماری نرم‌افزار SaleorSaleor از یک رویکرد ترکیبی در معماری خود بهره می‌برد که شامل هر مدلهای API-first Architecture و Event‑driven Architecture و معماری پلاگین است.در معماری API-first، تمامی قابلیت‌های Saleor، از مدیریت محصولات و سفارشات گرفته تا قیمت‌گذاری و مشتریان، در وهله اول از طریق یک رابط برنامه‌نویسی کاربردی (API) در دسترس قرار می‌گیرند. Saleor به طور خاص از GraphQL API استفاده می‌کند که به توسعه‌دهندگان امکان دریافت دقیق داده‌های مورد نیاز خود را می‌دهد. این رویکرد، مفهوم «تجارت الکترونیک بدون رابط کاربری گرافیکی» (Headless Commerce) را پیاده‌سازی می‌کند و به توسعه‌دهندگان اجازه می‌دهد تا بخش فرانت‌اند (نمایشی) را از بخش بک‌اند (منطقی) جدا کرده و با استفاده از هر فناوری دلخواهی، فروشگاه آنلاین خود را بسازند. این امر، انعطاف‌پذیری را در یکپارچه‌سازی با سرویس‌های خارجی نظیر سیستم‌های مدیریت محتوا (CMS)، سیستم‌های برنامه‌ریزی منابع سازمانی (ERP) و ابزارهای بازاریابی فراهم می‌آورد.علاوه بر این، Saleor یک معماری Event-driven نیز دارد.در معماری Event-driven هنگامی که یک رویداد مهم در سیستم رخ می‌دهد (مانند ایجاد یک سفارش جدید یا به‌روزرسانی موجودی انبار)، یک رویداد منتشر می‌شود. سرویس‌های خارجی می‌توانند به این رویدادها گوش فرا دهند و به آن‌ها واکنش نشان دهند.به عنوان مثال، به جای اینکه یک سرویس خارجی به طور مداوم از طریق API وضعیت سفارشات را بررسی کند، Saleor با انتشار یک رویداد به نام order_created، آن سرویس را به صورت لحظه‌ای از وقوع رویداد مطلع می‌سازد. Saleor این فرآیند را از طریق وب‌هوک‌ها (webhooks) پیاده‌سازی می‌کند؛ وب‌هوک‌ها URLهایی هستند که Saleor هنگام وقوع یک رویداد خاص، داده‌های مربوط به آن را به صورت خودکار به آن‌ها ارسال می‌کند. تفاوت وب هوک با صفهای پیام‌رسان در مکانیسم آنهاست. وب‌هوک به عنوان یک مکانیسم "فشاری" (Push) عمل می‌کند. در این روش، سرور فرستنده بلافاصله پس از وقوع یک رویداد مشخص (مانند ثبت یک سفارش جدید)، اطلاعات مربوط به آن رویداد را به صورت خودکار و لحظه‌ای به یک آدرس اینترنتی (URL) از پیش تعریف‌شده ارسال می‌کند. این فرآیند شبیه به یک تماس تلفنی است؛ با وقوع یک اتفاق، سیستم به صورت خودکار و بدون نیاز به درخواست از سوی گیرنده، آن را مطلع می‌سازد. صف پیام‌رسان (Message Queue) در مقابل، صف پیام‌رسان به عنوان یک مکانیسم "کششی" (Pull) عمل می‌کند. در این روش، سرویس دریافت‌کننده (گیرنده) باید به صورت مداوم یا در فواصل زمانی مشخص، به صف پیام مراجعه کرده و وجود پیام جدید را بررسی کند. این فرآیند شبیه به بررسی صندوق پستی است؛ گیرنده به صورت دوره‌ای برای دریافت پیام‌های احتمالی مراجعه می‌کند.به عبارت ساده‌تر مکانیسم فشاری مثل خبردادن از طریق زنگ زدن با تلفن است و مکانیسم کششی مثل یک صندوق پستی است که نامه‌ها را داخل آ ن می‌گذاریم.معماری پلاگین، یک الگوی طراحی است که به یک سیستم مرکزی اجازه می‌دهد تا به صورت ماژولار و بدون تغییر در کد اصلی، توسعه یابد. در Saleor، این معماری به عنوان یک ستون فقرات برای انعطاف‌پذیری سیستم عمل می‌کند. هسته‌ی Saleor یک پلتفرم تجارت الکترونیک جامع است که وظایف اصلی مانند مدیریت محصولات و سفارشات را انجام می‌دهد. پلاگین‌ها، در نقش ماژول‌های جداگانه، مسئول پیاده‌سازی قابلیت‌های تخصصی و خاص هستند.برای مثال، یک پلتفرم تجارت الکترونیک نیاز به چندین روش پرداخت (مانند کارت اعتباری، PayPal و...) دارد. به جای کدنویسی تمام این روش‌ها در هسته اصلی برنامه، هر کدام به عنوان یک پلاگین مجزا توسعه داده می‌شوند. این رویکرد دو مزیت کلیدی دارد:تفکیک مسئولیت‌ها: هر پلاگین مسئول یک وظیفه مشخص است (مثلاً یک پلاگین فقط پرداخت را مدیریت می‌کند و دیگری فقط مالیات را). این امر کد را تمیز، قابل نگهداری و آسان برای عیب‌یابی می‌کند.قابلیت اتصال و جدا شدن: پلاگین‌ها می‌توانند به راحتی به سیستم اضافه یا از آن حذف شوند. این قابلیت به توسعه‌دهندگان اجازه می‌دهد تا با توجه به نیازهای خود، پلاگین‌های دلخواه را فعال یا غیرفعال کنند، بدون اینکه به عملکرد کل سیستم آسیبی وارد شود.کلاس PluginsManager نقش مدیر این سیستم را بر عهده دارد. این کلاس به عنوان یک واسط بین هسته و پلاگین‌ها عمل کرده و هماهنگی بین آن‌ها را تضمین می‌کند. PluginsManager خودش منطق پرداخت یا مالیات را انجام نمی‌دهد، بلکه فقط می‌داند که کدام پلاگین‌ها فعال هستند و چگونه باید متدهای آن‌ها را در زمان مناسب فراخوانی کند. این الگو به Saleor امکان می‌دهد که به آسانی با سرویس‌ها و ابزارهای خارجی ادغام شود و به سرعت به نیازهای جدید بازار واکنش نشان دهد.معماری سیستم های مدیریت داده‌ای در نرم‌افزار Saleor: Saleor برای سازماندهی اطلاعات، از یک طراحی مبتنی بر حوزه‌های اصلی (Core Domain Areas) استفاده می‌کند. این حوزه‌ها هر کدام بخش مهمی از عملکرد تجارت الکترونیک را پوشش می‌دهند، مانند:مدل‌های محصولات (Product Models): شامل اطلاعاتی درباره محصولات، قیمت‌ها، تصاویر و ویژگی‌ها.مدل‌های سفارشات (Order Models): مربوط به داده‌های سفارش مشتریان، وضعیت پرداخت و جزئیات ارسال.مدل‌های پرداخت (Checkout Models): شامل اطلاعات مربوط به فرآیند پرداخت و سبد خرید.مدل‌های تخفیف و پیشبرد خرید (Discount and Promotion Models): برای مدیریت تخفیف‌ها، کدهای تخفیف و کمپین‌های تبلیغاتی.در تمام این داده‌ها برای ذخیره سازی به صورت پیش‌فرض از postgresql استفاده شده است اما یک تفاوت اساسی نسبت به موارد معمول نرم‌افزارهای دیگر دارد و آن اینکه به جای استفاده از SQL برای ارتباط با پایگاه داده از قراردادهای Django ORM استفاده می‌کند.ORM ابزاری است که به توسعه‌دهندگان اجازه می‌دهد با استفاده از کدهای پایتون با پایگاه داده ارتباط برقرار کنند، بدون اینکه نیاز به نوشتن مستقیم دستورات SQL داشته باشند. این کار توسعه را ساده‌تر و سریع‌تر می‌کند.یکی از نکات کلیدی در معماری Saleor، پیاده‌سازی یک معماری چندمستاجری (Multi-tenant Architecture) است که از طریق طراحی مبتنی بر کانال (Channel-aware design) انجام می‌شود.در یک معماری چندمستاجری، یک نمونه (instance) از نرم‌افزار به چندین سازمان یا "مستاجر" خدمت‌رسانی می‌کند. به عبارت دیگر، یک پایگاه کد و یک دیتابیس مشترک، به چندین فروشگاه یا کانال فروش خدمات می‌دهد.Saleor این مفهوم را با ایده کانال‌ها پیاده‌سازی می‌کند. یک کانال می‌تواند یک فروشگاه آنلاین، یک اپلیکیشن موبایل، یک فروشگاه فیزیکی یا حتی یک بازارچه(marketplace) باشد. هر کانال می‌تواند:قیمت‌های مخصوص به خود را داشته باشد: یک محصول می‌تواند در کانال A با قیمت متفاوت از کانال B فروخته شود.موجودی انبار متفاوتی داشته باشد: برای هر کانال می‌توان موجودی انبار خاصی تعریف کرد.واحد پول متفاوتی را پشتیبانی کند: کانال‌ها می‌توانند برای کشورهای مختلف و با ارزهای متفاوت تنظیم شوند.این طراحی کانال‌محور، به کسب‌وکارها امکان می‌دهد تا چندین فروشگاه یا برند را از طریق یک پلتفرم و یک پنل مدیریت کنند، که باعث کاهش هزینه‌ها و پیچیدگی‌های مدیریتی می‌شود.معماری تست در نرم افزار Saleorمعماری تست در نرم‌افزار Saleor بر پایه‌ی یک ساختار مدولار و سلسله‌مراتبی بنا شده است. هر اپلیکیشن جنگو در این پروژه (مانند account، product و checkout) دارای یک پوشه اختصاصی به نام tests است که به صورت مستقل قابل تست هستند. این رویکرد، تفکیک‌پذیری تست‌ها را تضمین می‌کند و به توسعه‌دهندگان اجازه می‌دهد تا هر بخش را به صورت جداگانه ارزیابی کنند. این معماری از سطوح مختلفی از تست، شامل تست‌های واحد (Unit Tests) برای بررسی کوچک‌ترین واحدهای کد، تست‌های یکپارچه‌سازی (Integration Tests) برای ارزیابی تعامل بین ماژول‌های مختلف و تست‌های سرتاسری (E2E Tests) برای شبیه‌سازی کامل فرآیندهای کاربری، بهره می‌برد. برای ایزوله کردن تست‌ها از وابستگی‌های خارجی، از ابزارهایی مانند fixtures (داده‌های نمونه) و cassettes (برای ضبط و پخش مجدد درخواست‌های شبکه) استفاده می‌شود. این روش، اجرای سریع‌تر تست‌ها را امکان‌پذیر می‌سازد و نیاز به اتصال به سرویس‌های واقعی خارجی را از بین می‌برد. در مجموع، این معماری تست جامع و دقیق، Saleor را به یک پروژه بسیار قابل اعتماد و پایدار تبدیل کرده است.GraphQL چیست و در نرم‌افزار Saleor چطور پیاده سازی شده است؟GraphQL یک زبان پرس‌وجو برای API است. برخلاف REST که در آن سرور تصمیم می‌گیرد چه داده‌هایی را برگرداند، در GraphQL کلاینت (مرورگر) کنترل کامل دارد که دقیقاً چه داده‌هایی را می‌خواهد. این امکان باعث می‌شود داده‌های اضافی (over-fetching) دریافت نشود و ارتباط بین بخش‌های مختلف داده به آسانی برقرار شود.مزایای GraphQLکنترل دقیق بر روی واکشی داده‌ها: GraphQSaleor با استفاده از GraphQL، امکان دسترسی به داده‌ها را با انعطاف‌پذیری و کارایی بالا فراهم می‌کند. این فناوری به توسعه‌دهندگان اجازه می‌دهد تا با یک درخواست واحد به هر تعداد فیلد مورد نیاز خود دسترسی پیدا کنند و با ترکیب چندین درخواست، تمامی داده‌ها را به صورت یکجا واکشی کنند. این رویکرد به ویژه در پلتفرم‌های تجارت الکترونیک که مدل‌های داده‌ای پیچیده‌ای دارند، بسیار سودمند است.واکشی بیش از حد (Over-fetching): در این حالت، سرور داده‌های بیشتری از آنچه نیاز است، ارسال می‌کند. برای مثال برای نمایش نام و قیمت یک محصول، سرور تمام نظرات کاربران، اطلاعات انبار و تاریخچه‌ی فروش آن محصول را هم می‌فرستد. این اطلاعات اضافی باعث اتلاف پهنای باند و کاهش سرعت می‌شود.واکشی ناقص (Under-fetching): در این حالت، سرور داده‌های کافی را در یک درخواست ارسال نمی‌کند و شما مجبور می‌شوید چندین درخواست جداگانه به سرور بفرستید. برای مثال برای نمایش اطلاعات یک محصول، ابتدا یک درخواست برای دریافت نام و قیمت فرستاده شود. سپس یک درخواست دیگر برای دریافت تصاویر، و یک درخواست سوم برای نظرات. این کار باعث افزایش تعداد تبادلات با سرور و تأخیر در بارگذاری صفحه می‌شود.GraphQL مشکلاتی مانند "واکشی بیش از حد" (over-fetching) و "واکشی ناقص" (under-fetching) را برطرف می‌کند. Saleor تمامی APIهای خود، از جمله ارتباطات وب‌هوک، را بر پایه GraphQL بنا نهاده است، تا یکپارچه‌سازی‌های خارجی نیز از همان سطح کنترل و انعطاف‌پذیری بهره‌مند شوند.گویا بودن پیام و تسهیل در تولید خودکار کد: طرح GraphQL به صورت خودتوضیح عمل می‌کند و تشخیص عملیات‌ها را برای توسعه‌دهنده ساده‌تر می‌سازد. سیستم نوع قوی در GraphQL یک قرارداد محکم بین کلاینت و سرور برقرار می‌کند که به توسعه‌دهندگان امکان استفاده از ابزارهایی مانند تولید خودکار کد و بررسی نوع ایستا را می‌دهد. این قابلیت به ویژه برای توسعه‌دهندگان TypeScript امنیت نوعی (type safety) را فراهم می‌آورد.نگهداری و تکامل: یکی از مزایای کلیدی GraphQL سهولت نگهداری آن است. از آنجایی که پرس‌وجوها صراحتاً فیلدهای مورد نیاز خود را مشخص می‌کنند، افزودن فیلدهای جدید به API یک تغییر غیرمخرب محسوب می‌شود. همچنین، امکان منسوخ کردن فیلدها با استفاده از علامت‌گذاری، به ابزارها اجازه می‌دهد که به توسعه‌دهندگان درباره نیاز به به‌روزرسانی کد هشدار دهند. این ویژگی‌ها تکامل API را بدون تأثیر منفی بر کلاینت‌های موجود ممکن می‌سازد و نیاز به نسخه‌بندی صریح API را از بین می‌برد.تغییر غیرمخرب (Non-breaking Change): در REST API های سنتی، افزودن یک فیلد جدید به پاسخ سرور می‌تواند برای کلاینت‌های قدیمی که انتظار ساختار داده‌ای متفاوتی دارند، مشکل‌ساز باشد. اما در GraphQL، از آنجایی که هر کلاینت تنها فیلدهایی را که صریحاً درخواست کرده دریافت می‌کند، افزودن فیلدهای جدید بر عملکرد کلاینت‌های موجود هیچ تأثیری نمی‌گذارد.منسوخ کردن فیلدها (Deprecation): اگر نیاز به حذف یک فیلد قدیمی وجود داشته باشد، می‌توان آن را با علامت‌گذاری به عنوان "منسوخ" (deprecated) در اسکیمای آن، به تدریج مدیریت کرد. با این کار، ابزارهای توسعه به توسعه‌دهندگان هشدار می‌دهند که استفاده از این فیلد توصیه نمی‌شود، اما فیلد منسوخ تا زمان به‌روزرسانی همه کلاینت‌ها به کار خود ادامه می‌دهد. این روند تدریجی به تیم‌ها اجازه می‌دهد فیلدهای قدیمی را بدون ایجاد اختلال ناگهانی حذف کنند.حذف نیاز به نسخه‌بندی صریح (Versioning): این ویژگی‌ها باعث می‌شوند که GraphQL نیاز به نسخه‌بندی صریح API را از بین ببرد. در REST، توسعه‌دهندگان اغلب مجبورند برای هر تغییر عمده‌ای، یک نسخه‌ی جدید از API (مانند api.com/v1 به api.com/v2) ایجاد کنند که این کار نگهداری API را بسیار پیچیده می‌کند. GraphQL با روش‌های خود، این پیچیدگی را به شدت کاهش می‌دهد و به تیم‌ها اجازه می‌دهد تا API را به صورت روان و مداوم تکامل دهند.نمونه ای از یک پیام ارسالی از بخش فرانت به بک اند در قالب GraphQL که توسط ابزار developer tools در مرورگر هنگام اجرای نرم‌افزار رصد شده است.نرم‌افزار Saleor یک رابط کاربری هم برای اجرای دستورات GraphQL ارائه داده است که برای محیط توسعه نرم‌افزار مناسب است. تصویر زیر گویای یک درخواست و پاسخی است که در همین محیط انجام شده است.در تصویر بالا سمت چپ یک پرس‌وجو به نام MyQuery است که به شرح زیر توضیح داده می‌شودproducts: یعنی لیست products را بگیرد.(first: 4, channel: "default-channel"): فقط ۴ محصول اول را از کانالی به نام "default-channel" درخواست کرده است.edges و node: در ساختار GraphQL، داده‌های لیست‌ها معمولاً درون edges و node قرار می‌گیرند. این یک الگوی رایج برای صفحه‌بندی (pagination) و مدیریت ارتباطات است.name: از هر محصول، فقط نام آن را درخواست کرده است.پاسخ سمت راست نیز داده‌هایی است که سرور GraphQL پس از اجرای پرس‌وجوی برگردانده است:"data": این بخش شامل تمام داده‌های درخواستی است."products": این همان لیست محصولاتی است که در پرس‌وجو درخواست شده بود."edges": یک آرایه (array) شامل ۴ شیء است که هر کدام نماینده یک محصول هستند."node": در هر شیء از edges، یک node وجود دارد که اطلاعات واقعی محصول را نگه می‌دارد."name": نام هر محصول (مثل "Apple Juice", "Monospace Tee" و...). این دقیقاً همان فیلدی است که در پرس‌وجو درخواست کرده‌اید.این مثال به خوبی نشان می‌دهد که چگونه GraphQL اجازه می‌دهد تا دقیقاً همان داده‌ای که نیاز است دریافت گردد. وقتی فقط نام محصولات درخواست می‌شود، پاسخ هم فقط شامل نام محصولات است، نه اطلاعات اضافی مثل قیمت، توضیحات یا تصاویر. این کار باعث می‌شود تا حجم داده‌های منتقل شده کمتر و سرعت برنامه شما بالاتر باشد. بخش extensions هم اطلاعاتی درباره هزینه اجرای پرس‌وجو ارائه می‌دهد. "requestedQueryCost": 4 به این معنی است که اجرای این پرس‌وجو ۴ واحد هزینه داشته است.خلاصه ارزیابی سه نرم‌افزار و مقایسه آنها با یکدیگرمقایسه تطبیقی هر سه نرم‌افزارمنابع و مراجعhttps://github.com/ocp-power-demos/sock-shop-demo, Accessed May 2025https://github.com/opencart/opencart, Accessed May 2025https://github.com/saleor/saleor, Accessed May 2025https://deepwiki.com/saleor/saleor, Accessed August 2025برای تحلیل قطعات کد نرم‌افزاری از ابزارهای هوش مصنوعی Chatgpt و Gemini استفاده شده است.

سند معماری نرم‌افزار، شرحی بر اهمیت و قالبهای رایج آن

سید محمد مهدی حسینی — Sat, 17 May 2025 11:03:21 +0330

سند معماری نرم افزار سندی موجز و سطح بالا و فارغ از جزئیات پیاد‌سازی از تصمیمات نرم‌افزاری است که در حیطه طراحی یک نرم‌افزار باید گرفته شود که در یک قالب استاندارد باید تهیه شود. محتوای این سند به دو بخش فضای مسأله و راه‌حل تقسیم می‌گردد. این سند در صورتی که به درستی و با دقت تنظیم گردد و به طور مداوم به روزرسانی گردد مرجعی پر استفاده برای تیم طراحی در طول زمان طراحی خواهد بود که همه ذی‌نفعان نرم‌افزار اعم از مدیران فنی تیم، تیم برنامه‌نویسی و بهره‌بردار نهایی از نرم‌افزار می‌توانند به آن مراجعه و استناد نمایند. همچنین کلید تداوم مسیر پروژه در ریل اصلی آن در صورت تغییر تیم طراحی خواهد بود و وابستگی نرم‌افزار به افراد را کاهش می‌دهد. ضمن آنکه می‌تواند مبنایی برای ارزیابی تولید محصول نهایی باشد.مدل 4+1یکی از مدلهای رایج برای طراحی سند معماری مدل 4+1 می‌باشد که مدلی رایج و شامل یک بخش مرکزی نمای موارد کاربری از بخش فضای مساله و 4 نمای منطقی، استقرار، پردازه و پیاده‌سازی از بخش فضای راه‌حل است. البته غالب مراجعی که در رابطه با این مدل وجود دارند قدیمی هستند و احتمالاً برای طراحی سند نرم‌افزار مناسب نیستند و اگر بخواهیم بر پایه این مدل سند را طراحی نماییم ناگزیر از اضافه نمودن بخشهای تکمیلی بدان هستیم. لذا علاوه بر نمای برشمرده نیازمند نماهای تکمیلی دیگری نیز هستیم.نمای موارد کاربری شامل نیازمندیهای کلان و اصلی عملکردی سیستم نرم افزاری است و توضیح مختصری از هر نیازمندی در آن ذکر می‌شود. این بخش به همراه مقدمه و بخش ویژگیهای کیفی، بخش فضای مساله سند معماری را شکل می‌دهد. در بخش مقدمه ضمن توضیح مختصری درباره نرم‌افزار و محدوده کاری آن، محدودیتهایی را که در زمینه تولید نرم‌افزار با آن مواجه هستیم و ناگزیر از آن هستیم بیان می‌کنیم. در بخش ویژگیهای کیفی نیز نیازهای کیفی سیستم را در قالب سه ستونی شامل ویژگی کیفی، معیار اندازه‌گیری و نتیجه موردانتظار بر حسب معیار مورد اشاره ذکر می‌نماییم.در نمای منطقی اجزاء اصلی نرم‌افزار و روابط بین آنها را مشخص می‌نماییم. برای نمایش اجزاء نباید وارد جزئیات پیاده‌سازی نظیر کلاسهای برنامه نرم‌افزاری گردیم. بلکه جزئیات باید در سطح بالا و حداقل مؤلفه‌های نرم‌افزار باشند. در نمای استقرار زیرساختهای فیزیکی مثل تعداد سرورها و حافظه و تعداد هسته‌های پردازشی را که برای استقرار نرم‌افزار بدان نیاز داریم ذکر می‌نماییم. در نمای پردازه در قالب یک جدول برنامه‌های اجرایی سیستم نهایی مورد انتظار را مشخص می‌نماییم و توضیح مختصری درباره در هریک از آنها می‌دهیم. سپس نوع فناوری ارتباطی بین پردازه‌ها را نیز در یک جدول دیگر ممکن است مشخص نماییم. در نمای پیاده‌سازی ماژولهای اصلی نرم‌افزار در سطح معماری و کلان نرم‌افزار ذکر می‌شود و ممکن است لایه‌بندی هر ماژول در نرم‌افزار نیز ذکر شود. در معرفی هر ماژول باید فناوری مورد استفاده برای آن و همچنین وابستگیهای آن نیز ذکر شود.باید توجه داشت بعضی اوقات ممکن است چند نمای سند معماری شبیه یکدیگر شوند. به خصوص در نرم‌افزارهای میکروسرویس که این امر اشکالی ندارد. همچنین نماهای مختلف ممکن است متقاطع باشند. مثل آنکه در نمای پردازه ممکن است زیرساختهای فیزیکی برای هر پردازه را که مختص نمای استقرار است ذکر نماییم.یک بخش اختیاری که می‌توان در سند نرم‌افزار گنجاند این است که نحوه تحقق چند مورد محدود (حدود دو تا سه عدد) از موارد کاربری کلیدی و مهم را مشخص نماییم. بدین منظور باید بیان نماییم مولفه‌های اصلی برای تحقق این امر چگونه تعامل می‌نمایند. یک روش رایج برای این امر استفاده از نمودارهای تعاملی در UML نظیر sequence diagram است.در نمای تست تصمیمات و رویکردهای کلان درزمینه معماری نرم‌افزار را بیان می‌نماییم و نوع و رویکرد اتخاذ شده برای سطوح مختلف تست نظیر تست واحد، تست یکپارچه سازی و ... به همراه ابزارهای مورد استفاد را بیان می‌نماییم. به خصوص اگر رویکرد مورد استفاده نیازمند به کارگیری تمهیداتی در نرم‌افزار باشد. البته باز نباید وارد جزئیات پیاده‌سازی گردیم. بلکه باید رویکردها و تصمیمات سطح بالا را ذکر نماییم.لاگها رویدادهای مهم در زمان اجرای نرم‌افزار را ثبت می‌نمایند. در نمای لاگ نوع لاگهایی که باید تولید شوند به همراه فرمت و ساختار آن را شرح می‌دهیم.در نمای پایش معماری مونیتورینگ اجرای نرم‌افزار که مواردی چون سلامتی سرورها و دسترس‌پذیری آنها، میزان مصرف منابع سخت‌افزاری سیستم مثل حافظه و CPU، یا تعداد کاربران فعال و یا تعداد درخواستهای وارده به سیستم را رصد می‌نماید، شرح می‌دهیم. بدین منظور باید ابزار مورد استفاده برای پایش مثل نام نرم‌افزار مورد استفاده به همراه معیارهایی که باید پایش گردد و همین‌طور هشدارهایی که باید داده شود و نحوه گزارش‌دهی آن را مطرح می‌نماییم.در نمای داده معماری پایگاه اطلاعاتی شامل نوع پایگاه داده انتخابی، تکنیکهای مورد استفاده در زمینه دیتا نظیر استفاده از کش و یا CQRS و یا انبار داده را شرح می‌دهیم. همچنین ممکن است مقداری راجع به ساختار داده و موجودیتهای کلیدی آن توضیح دهیم. البته ضروری نیست به خصوص اگر اثری بر روی معماری ما نگذارد. همچنین تمهیدات اتخاذ شده برای امنیت داده و پشتیبان‌گیری از دیتا را می‌توانیم در این بخش شرح دهیم.در نمای الگوها و تکنیک‌ها، تکنیکهای مورد استفاده در نرم‌افزار نظیر load balancer یا Kubernetes یا .... را برای هر ویژگی کیفی در قالب یک جدول مرور می‎نماییم و هر کدام را به نمایی که در آن توضیح داده شده است ارجاع می‌دهیم. بنابراین این بخش یک خلاصه از الگوهای مورد استفاده در نرم‌افزار است که در بخشهای دیگر توضیح داده شده است و در اینجا فقط تجمیع و گردآوری می‌گردد.در نمای ابزارها و فناوریها، ابزارهای مورد استفاده را که احتمالا در بخش قبلی نیز شرح داده‌ایم در قالب نام و نسخه نرم‌افزاری مورد استفاده و جایگاه آن در سیستم ذکر می‌نماییم.در بخش تصمیمات معماری، تصمیمات مهم نرم‌افزار که گرفته شده است را شرح می‌دهیم. در این بخش می‌توانیم مواردی چون تصمیماتی که تغییر آنها هزینه‌بردار و مشکل هست، تصمیماتی که بدیهی نبوده‌اند و یا تاریخچه‌ای که طی شده است تا آن تصمیم گرفته شود شرح دهیم. همچنین گزینه‌های دیگری نیز که با آنها مواجه بودیم و می‌توانستیم انتخاب کنیم را نیز می‌توانیم بیان نماییم.در بخش ریسک‌ها و بدهی های فنی نیز موارد مطروحه در نرم‌افزار را شرح می‌دهیم. بدهیهای فنی در نرم‌افزار تصمیماتی هستند که با مشکلات و مخاطرات آن آشنا هستیم ولی به دلیل مواردی چون ضیق وقت و یا محدودیتهای فنی و ... آن را انتخاب می‌نماییم. مثل انتخاب یک ابزار به رغم آگاهی از وجود برخی باگهای نرم‌افزار در داخل آن. در این بخش توضیحی از هر کدام می‌دهیم و ضمن برشمردن اولویت آن احتمال وقوع آن وتأثیر آن را در صورت وقوع شرح می‌دهیم.علاوه بر موارد فوق ممکن است بخشهایی دیگر به دلخواه به این سند اضافه نماییم. برای مثال اکثر نرم‌افزارها دارای امکاناتی برای گزارش‌گیری توسط کاربران و یا مدیران سیستم هستند. از اینرو می‌توانیم بخشی به نام گزارشگیری به سند اضافه نماییم که انواع گزارشهای تولیدی و تکنیک مورد استفاده برای آن را شرح دهد. همجنین می‌توانیم در یک فصل برای آینده معماری نرم‌افزار و سمتی که میتوانیم بدان سوق داده شویم صحبت نماییم. چون سند معماری نرم‌افزار سند وضع موجود نرم‌افزار است و می‌توانیم برای آن در این فصل چگونگی پیشرفت معماری وضع موجود و حرکت رو به جلو را نیز طراحی نماییم.مدل C4یک مدل دیگر برای نمایش سند معماری نرم‌افزار مدل c4 است که البته یک مدل موجز و مختصر است که به توصیف معماری می‌پردازد. در این مدل 4 سطح‌بندی داریم. سطح اول سطح Context است که مرز سیستم و ارتباط آن با محیط بیرونی را نشان می‌دهد. سطح دوم Container است که واحدهای درون سیستم را که به صورت مستقل اجرا می‌شود نشان می‌دهد. کانتیتر در اینجا با کانتیتر که در داکر هست متفاوت هست؛ هرچند هر کانتینر داکر می‌تواند یک کانتینر در این بخش باشد. سطح سوم هم Component هست که مولفه‌های درون کانتینرها را نشان می‌دهد. سطح چهارم نیز سطح Code می‌باشد که کلاسهای داخل هر مؤلفه را نشان می‌دهد و یا موجودیتهای داخل دیتابیس را نشان می‌دهد و می‌تواند مستند نگردد. چون در سطح پیاده‌سازی است.

معرفی پانزده مفهوم در معماری نرم‌افزار

سید محمد مهدی حسینی — Fri, 09 May 2025 07:56:28 +0330

مفهوم اول- Infrastructure as Code اصطلاح IAC به معنای اجرای تنظیمات زیرساختهای IT در موارد تکرارپذیر از طریق کدهای نرم‌افزاری است تا ضمن اتوماسیون و تسریع کار اشتباهات انسانی به حداقل برسد. این امر با کمک نرم‌افزارهایی چون Terraform، Ansible، Puppet و Chefو به دو شیوه صورت می‌پذیرد. رویکرد اول imperative است که به نرم‌افزار گفته می‌شود دقیقا چه اقداماتی باید انجام شود. مثل دستور آشپزی برای پختن یک غذا. رویکرد دوم declarative هست که تنها حالت نهایی که باید ایجاد شود به نرم‌افزار داده می‌شود و نرم‌افزار اقدامات لازم به منظور رسیدن به آن حالت را طراحی می‌نماید. مثل اینکه در آشپزی تنها بگوییم که چه غذایی می‌خواهیم.مفهوم دوم- API Gateway & Service Mesh هر دو ابزاری برای مدیریت سرویسها هستند که بیشتر در معماری میکروسرویس استفاده می‌شوند. با این تفاوت که API Gateway برای مدیریت سرویسها با کلاینت و یا مدیریت ارتباط بخش front نرم‌افزار اعم از اپلیکیشنهای موبایلی و یا صفحات وب با بخش backend آن است. API Gateway درخواستهای کلاینت را مدیریت کرده و به سمت سرویس مناسب هدایت می‌کند. بار ترافیکی را از طریق Cashing و یا در صورت وجود هسته‌های مختلف، با تعادل بخشی در توزیع بار بین هسته‌های مختلف کنترل می‌کند. Service Meshبرای مدیریت ارتباطات داخلی بین سرویس‌ها است و وظایفی چون احراز هویت داخلی، مانیتورینگ و امنیت ارتباطات را فراهم می‌کند.مفهوم سوم- CQRS روشی در مدیریت و ذخیره‌سازی داده ها است که داده ها به دو طریق که یکی برای خواندن از طریق کوئری بهینه‌سازی شده و دیگری برای نوشتن از طریق insert و یا update و یا دستورات مشابه بهینه‌سازی شده است، ذخیره می‌گردد. دلیل این امر نیز آن است که پایگاه‌های داده برای خواندن و نوشتن نیازهای متفاوتی دارند و این امر به تسریع در ورود اطلاعات و خواندن آن کمک می‌کند. هرچند به جهت تاخیر در بروزرسانی پایگاه داده مربوط به خواندن، می‌تواند منجر به ارائه پاسخ قدیمی گردد که این امر را Eventual consistency می‌نامند.مفهوم چهارم- Event-Driven Architecture در شیوه معماری معمول نرم‌افزار که به صورت درخواست – پاسخ می‌باشد سرویسها به طور متوالی فراخوانی و اجرا می‌شوند و هر سرویس تنها زمانی خوانده و اجرا می‌شود که پاسخ در مرحله قبلی دریافت شده باشد. بنابراین در صورت وقوع مشکل در یک نقطه از این فرایند کار متوقف می‌ماند و مابقی سرویسها فراخوانی نمی‌گردند؛ ولی در معماری رویدادمحور (EDA) همه سرویس ها خوانده می‌شوند و صفی از پیامها برای آنها درست می‌شود. در صورت وقوع رویداد موردنظر برای هر سرویس آن سرویس وظیفه خود را انجام می‌دهد و مستقل از سرویسهای دیگر عمل می‌کند. بدین معنا که برای فراخوانی و اجرا منتظر به نتیجه رسیدن کار سرویس قبلی نمی‌ماند؛ بلکه از همان ابتدا اجرا شده و تنها منتظر وقوع رویداد موردنظر برای پردازش پیام است.مفهوم پنجم: Serverless Architecture معماری بدون سرور بدان معنا است که به جای راه‌اندازی و یا اجاره یک فضا بر روی سرور که همیشه منتظر دریافت تقاضا از سمت فرانت اند نرم‌افزار است تنها زمان فراخوانی از سوی کاربر سمت سرور نرم‌افزار فعال گردد و هزینه‌ها نیز بر حسب میزان زمان پردازش از سوی شرکتهای خدمات‌دهنده محاسبه گردد. برای مثال در معماری معمول در جانب سرور معمولاً یک خط کد به صورت زیر داریم:2. app.listen( 3000, () => { console.log("Server running on port 3000"); });اما در معماری بدون سرور نیازی به اجرای دائمی برنامه نیست. در عوض، یک تابع فقط هنگام دریافت درخواست اجرا می‌شود و بعد از انجام کار خاموش می‌شود.مفهوم ششم- API-first Approach رویکرد API اول بدین معناست که شروع کدنویسی برای نرم‌افزار از API شروع شود. از اینرو API اهمیت بسیاری در این نوع معماری پیدا می‌کند و در مرکز کار قرار می‌گیرد. همچنین رعایت استانداردهای مخصوص برای نوشتن آن نظیر OPENAPI، اهمیت بیشتری پیدا می‌کند تا به صورت reuseable و منعطف طراحی گردد و زمان بیشتری برای تفکر درباره‌ی طراحی یک API نیاز است. چون هر بخشی از نرم‌افزار که زودتر نوشته ‌شود احتمالاً تغییرات بیشتری در طول حیات خود خواهد داشت. این رویکرد نیازمند توسعه‌ی APIهایی است که یکپارچه و قابل استفاده‌ی مجدد باشند و این امر با استفاده از یک زبان توصیف API میسر می‌شود تا قراردادی برای نحوه‌ی عملکرد API تعیین شود.مفهوم هفتم- Domain Driven Design به معنای طراحی دامنه محور است. در این رویکرد به جای آنکه طراحی از نیازهای فنی شروع شود از شناخت نیازهای تجاری و مشکلات واقعی کسب و کار و طراحی دقیق دامنه کسب و کار شروع می‌شود. شناخت دامنه کسب و کار به دو طریق در شکل‌گیری ساختار نرم‌افزار نقش دارد. یک تعریف زمینه‌های محدود (bounded context). بدین معنا که نرم‌افزار به چه بخشهایی تقسیم گردد و چه ماژولهایی داشته باشد. مثل تقسیم یک نرم‌افزار فروش انلاین به بخشهای مدیریت محصولات، مدیریت سفارش، پرداخت و ارتباط با مشتری دوم تعریف نقشه‌ برداری زمینه (context mapping) بدین معنا که روابط حاکم بر بخشهای مختلف را تعریف می‌کند. مثل آنکه بگوییم برای آنکه یک سفارش تایید شود باید پرداخت انجام شده باشد.مفهوم هشتم- Hexagonal architecture هدف این معماری این است که هسته‌ی نرم‌افزار از جزئیات فنی کاملاً مستقل باشد و از طریق پورت‌ها و آداپتورها با دنیای بیرون ارتباط برقرار کند. پورت مانند آن است که یک تابع آبسترکت از پرداخت تعریف نماییم. ولی آداپتر یک پیاده‌سازی از آن پرداخت است. مثل پیاده‌سازی پرداخت از طریق یک درگاه بانکی. حال هروقت که در هسته بخواهیم به پرداخت اشاره کنیم از پورت استفاده می‌کنیم و به پیاده‌سازی آن کاری نداریم. لذا هر موقع که بخواهیم فناوری پرداخت را عوض نماییم این کار به راحتی انجام می‌شود و هیچ خللی در عملکرد هسته ایجاد نمی‌شود و این امر نرم‌افزار را منعطف‌تر و تغییرات در آن را ساده‌تر می‌نماید.مفهوم نهم- Event sourcing به معنای رویداد محور بودن بدین معناست که به جای ذخیره وضعیت فعلی، مجموعه‌ رویدادهایی که منجر به تغییر داده می‌شوند ذخیره گردد. بدین ترتیب وضعیت فعلی را می‌توان از طریق دنباله رویدادها محاسبه نمود، بدون آنکه مقدار فعلی آن را ذخیره نماییم. بدین ترتیب تاریخچه تمام تغییرات ثبت می‌گردد و تراکنش‌ها بر روی داده قابل مشاهده و بررسی خواهد بود. اگر شرط انجام تراکنش مستقل از مقدار متغیر باشد و بدان وابستگی نداشته باشد با این روش مشکل به روزرسانی متغیر در پردازشهای موازی که قفل‌گذاری داده را در پایگاه داده الزامی می‌ساخت برطرف می‌گردد و تراکنش‌ها سریعتر انجام می‌شوند.مفهوم دهم- Low-code/No-code platforms پلتفرمهایی هستند که رابطهای گرافیکی مانند مؤلفه‌های کشیدنی و رهاکردنی فراهم می‌آورند تا امکان تهیه نرم‌افزارهایی چون صفحات وب و یا اپلیکیشنهای موبایل با قابلیت تعامل با کاربر بدون نوشتن کد یا با حداقل نیاز به نوشتن کد فراهم گردد. در حالت low-code امکان افزودن فیچرهای پیشرفته‌تر از طریق کد نویسی فراهم می‌گردد. ولی در حالت no-code ممکن است با محدودیتهایی در ایجاد حالتهای سفارشی مواجه گردیم. Webflow از پرکاربردترین نرم‌افزارهای no-code و Microsoft PowerApps از پرکاربردترین نرم‌افزارهای low code هست. بین این پلتفرمها با نرم‌افزارهایی چون wordpress که از طریق قالبهای آماده می‌توانند صفحات وب را به سرعت طراحی نمایند و در سیستم مدیریت محتوا قرار می‌گیرند باید تفکیک قائل شد.مفهوم یازدهم- Business Process Management Systems (BPMS) سیستم‌های مدیریت فرآیند کسب‌وکار مجموعه‌ای از ابزارها و فناوری‌ها هستند که به سازمان‌ها کمک می‌کنند تا فرآیندهای تجاری خود را مدل‌سازی، اجرا، نظارت و بهینه‌سازی کنند. سیستمهای مدیریت فرایند کسب و کار ذاتاً ارتباطی به نرم‌افزار ندارند و برای شناخت و طراحی روالهای کسب و کار در داخل یک سیستم یا سازمان هستند. اما زمانی که بخواهیم فرایندهای داخل یک سازمان را الکترونیکی نماییم و با سیستمهای نرم‌افزاری یکپارچه نماییم ناگزیر از آشنایی و بکارگیری آن هستیم. برای مثال اگر بخواهیم فرایند پرداخت وام توسط یک بانک را الکترونیکی نماییم ابتدا باید بدانیم فرایند پرداخت بانک در آن سازمان چه مراحل و روالی دارد و شرایط ورود به هر مرحله و اتمام آن چیست.مفهوم دوازدهم- Message Queue مکانیسمی برای امکان برقراری ارتباط غیرهمزمان بین دو سیستم است. بدین صورت که سیستم درخواست دهنده پس از ارسال تقاضا لازم نیست منتظر پاسخ بماند و می‌تواند کارهای دیگری را انجام دهد. در صورتی که داده‌های تبادل شده به صورت پیوسته و لحظه‌ای باشد مثل درخواستهای خرید ار سوی کاربران داده از نوع جریانی و ابزار kafka برای آن مناسب است. در صورتی که داده‎‌ها به صورت انبوه و در زمان مشخص جمع‌آوری و پردازش می‌شوند مثل گزارشگیری در پایان ساعت کاری داده از نوع دسته‌ای و باز از ابزار Kafka به کمک Spark یا Flink برای آن استفاده می‌شود. برای پردازش پیامهای فوری و کوتاه مدت نیز ارسال ایمیلهای تاییدیه نیز از RabbitMQ استفاده می‌شود.مفهوم سیزدهم- Container orchestration (such as Kubernetes)کوبرنتیز یک ابزار قدرتمند برای مدیریت کانتینرهاست که به‌طور خودکار کانتینرها را اجرا، مقیاس‌گذاری و هماهنگ می‌کند. این پلتفرم می‌تواند نسخه‌های متعددی از یک کانتینر را راه‌اندازی کرده و آن‌ها را روی هسته‌های مختلف سرورها توزیع نماید. در مواقعی مانند خرابی (Crash) یک کانتینر یا افزایش ترافیک، Kubernetes به ‌صورت خودکار نسخه‌های جدیدی را راه‌اندازی می‌کند تا بار کاری متعادل شود. همچنین این سیستم قابلیت بازیابی خودکار دارد و اطمینان حاصل می‌کند که کانتینرها به‌موقع اجرا شوند، با هم هماهنگ باشند و به‌راحتی همدیگر را شناسایی کنند و با هم ارتباط برقرار نمایند. مقیاس‌گذاری کانتینرها به دو روش انجام می‌شود. روش اول روش افقی است که تعداد کانتینرها افزایش می‌یابد. این قابلیت در Kubernetes وجود دارد. روش دوم به صورت عمودی است که منابع اختصاصی مانند CPU و RAM را افزایش می‌دهیم. این روش در Kubernetes به طور پیش‌فرض فعال نیست و از طریق تنظیمات و نصب یک افزونه قابل دستیابی است. هرچند ممکن است به ریستارت کردن دستگاه نیاز باشد و برای سیستمهای حساس که نمی‌توانند قطع گردند مناسب نیست.مفهوم چهاردهم- Multi-Tenancy Architecture معماری چند مستأجری مانند برنامه‌هایی چونGMail به این صورت عمل می‌کند که کاربران مختلف از یک زیرساخت نرم‌افزاری مشترک بهره می‌برند، اما داده‌های هر یک به‌صورت مجزا ذخیره می‌شود و هیچ کاربری به اطلاعات دیگران دسترسی ندارد. در این مدل این امکان وجود دارد این قابلیت را فراهم نمود هر کاربر می‌تواند تنظیمات خاص خود را اعمال کرده، ظاهر برنامه را شخصی‌سازی کند و تجربه کاربری منحصربه‌فردی داشته باشد. این معماری به دلیل استفاده بهینه از منابع سرور و زیرساخت، امکان پشتیبانی از تعداد زیادی کاربر را با هزینه کم فراهم می‌سازد. همچنین، نگهداری، به‌روزرسانی و مقیاس‌پذیری نرم‌افزار ساده‌تر شده و تیم توسعه می‌تواند تغییرات را به‌صورت یکپارچه پیاده‌سازی کند. در مدلهای رایج در این زمینه پایگاه داده و اسکیمای نرم‌افزار می‌تواند برای کاربران جداگانه و یا مشترک تعریف گردد.مفهوم پانزدهم- Enterprise Integration Patterns الگوهای یکپارچه‌سازی سازمانی الگوهایی هستند که در سطح معماری برای اتصال نرم‌افزارهای مختلف یک سازمان معرفی می‌گردند؛ مثل اتصال سیستم حسابداری یک فروشگاه با نرم‌افزار انبار و نرم‌افزار فروش آنلاین که در صورت عدم به کارگیری این الگوها باید به صورت دستی توسط کارکنان وارد شوند و امکان خطا وجود دارد. لذا به صورت مفاهیم مطرح می‌گردند و نه جزئیات فنی و می‌توانند روی هر الگوی نرم‌افزار اعم از JSON، SOAP، Kafka، RabbitMQ و ..... اعمال گردند. مثل الگوی Content Based Rout که بر اساس محتوای پیام باید تصمیم گرفت پیام به کدام سرویس هدایت گردد.