https://virgool.ir/feed/@m_98739531fa2026-11-11 03:32:20https://virgool.ir/images/default-avatar.jpghttps://virgool.ir/@m_98739531https://virgool.ir/@m_98739531/بررسی-الگو-های-معماری-در-سیستم-های-نرم-افزاری-فرانت-اند-و-تاثیر-آنها-بر-ویژگی-های-کیفی-cvyns6kolcavکیانوش آرین 404443009درس معماری نرم‌افزاردکتر علی‌اکبری 1. مقدمهاز زمان پیدایش وبسایت ها و ایجاد برنامه نویسی فرانت اند، تغییرات زیادی در ابزار ها، نحوه کد نویسی و معماری های مربوط به این حوزه پدید آمده است. امروزه سیستم های فرانت اند نه تنها مسئولیت ایجاد و مدیریت رابط کاربری (GUI) را بر عهده دارند، بلکه بخش قابل توجهی از منطق کسب و کار (Business Logic) را نیز در سمت مرورگر کاربر پیاده سازی می کنند. همچنین، این سیستم ها از نیازمندی های کیفی (Quality Attribute Requirements) خاصی برخوردارند که با دیگر سیستم های نرم‌افزاری متفاوت است. در این پژوهش، به بررسی معماری‌ها و الگوهای رایج مورد استفاده در سیستم‌های فرانت‌اند می‌پردازیم و می‌کوشیم تأثیر آنها بر ویژگی‌های کیفی مختلف را شرح دهیم. در این تحقیق معماری‌هایی از جملهMonolithic, Component Based, Micro front end, MVP, MVVM, SSR, Jamstack, Single Page Application, Static Site Generation,  را بررسی می‌کنیم.خروجی اصلی این پژوهش، ایجاد یک ماتریس از معماری های فرانت اند و ویژگی های کیفی است که در آن تاثیر هر معماری بر ویژگی های کیفی مورد بررسی قرار گرفته و مزایا، معایب هر کدام مشخص می‌شوند. علاوه بر این در ادامه، دو مورد از معماری های مورد استفاده در پروژه های واقعی در صنعت (نتفلیکس و فیسبوک) را شرح داده و معماری مورد استفاده در آنها به همراه ویژگی های کیفی مختص به آن پروژه را بررسی می‌کنیم. هدف نهایی این پژوهش، ارائه راهنمایی ساختاریافته برای مقایسه معماری‌های فرانت‌اند و کمک به انتخاب معماری مناسب با توجه به ویژگی‌های کیفی مورد نیاز سیستم است. 2. پیشینهدر روز های آغازین پیدایش وب، رابط های کاربری اغلب به طور Static و به شکل داکیومنت هایی ثابت به کاربران ارائه می‌شدند. این دوران را می‌توان دوران اپلیکیشن های چند صفحه ای (Multi Page Application) ها نام گذاری کرد. در این اپلیکیشن ها، در هر بار تعامل کاربر با اپلیکیشن، صفحه دوباره به طور کامل از سرور دریافت می‌شد که بازدهی بسیار پایینی داشت. با گذشت زمان، اپلیکیشن های تحت وب به سیستم های داینامیک و توزیع شده ای تبدیل شدند که قابلیت اجرای منطق های پیچیده را در سمت کاربر و داخل مرورگر دارند. سیستم های مدرن می‌توانند بدون نیاز به مراجعه به سرور و به طور زنده (Real-Time) به تعاملات کاربر پاسخ دهند، وضعیت های (State) پیچیده مورد نیاز برای اجرای سیستم را مدیریت کرده و منطق کسب و کار (Business Logic) را پیاده سازی کنند. بنابراین امروزه وظیفه سیستم های فرانت اند تنها ارائه رابط کاربری (GUI) به کاربران نیست، بلکه به یک لایه مهم در معماری سیستم تبدیل شده اند که نقش مهمی در عملکرد سیستم و تجربه کاربران دارند. 2.1 معماری نرم‌افزار در فرانت اندمعماری نرم‌افزار در سیستم های فرانت اند به مرز های سیستم (Boundries)، الگو های ارتباطی در سیستم، و حتی ساختار سازمانی که به توسعه نرم‌افزار می‌پردازد مرتبط است. در گذشته، معماری سیستم های فرانت اند بیشتر مشابه نرم‌افزار های یکپارچه (Monolithic) بوده که منطق رابط کاربری، مدیریت state، و چینش (styling) صفحه همه در داخل یک کدبیس با Coupling بالا انجام می‌شده. با وجود این که این نوع معماری شروع و راه اندازی ابتدایی پروژه را ساده تر و سریع تر می‌کند، اما با بزرگتر شدن پروژه و Scale شدن آن، مشکلات فراوانی از جمله پیچیدگی درک کد، زمان بیلد طولانی و Bottleneck به وجود می‌آورد.این مشکلات سبب شد تا معماری سیستم های فرانت اند به سمت معماری های Component-Based و تک صفحه ای (Single-Page Application) حرکت کند. این معماری ها به توسعه دهندگان کمک می‌کنند تا مولفه های رابط کاربری را به کامپوننت های قابل استفاده مجدد و ماژولار تبدیل کنند. در سال های اخیر، معماری میکرو-فرانت اند که از معماری Microservice الهام گرفته شده به عنوان معماری جدیدی برای مدیریت پروژه های بزرگ محبوبیت پیدا کرده. این معماری با تقسیم فرانت اند به تعدادی میکرو اپلیکیشن مستقل از هم، به تیم های مختلف این امکان را می‌دهد تا بدون ایجاد تداخل در کار یکدیگر به توسعه، تست و دیپلوی سیستم های فرانت اند بپردازند. 2.2 ویژگی های کیفیویژگی‌های کیفی (Quality Attributes) نیازمندی هایی در پروژه های ما هستند که معیار های غیر عملکردی (Non-Functional) سیستم را توصیف میکنند. این ویژگی ها تعیین می‌کنند که یک معماری فرانت‌اند وقتی در شرایط واقعی و تحت استفاده واقعی کاربران قرار می‌گیرد، تا چه حد خوب عمل می‌کند. در ادامه، برخی از این ویژگی های کیفی که در این تحقیق بررسی می‌کنیم را از دید فرانت اند بررسی می‌کنیم:امنیت (Security): این ویژگی کیفی معیار هایی از جمله میزان مقاومت سیستم فرانت‌اند در برابر آسیب‌پذیری‌ها و حملات سمت کاربر (مانند XSS، CSRF و Script Injection)، مدیریت امن توکن‌ها و داده‌های حساس در مرورگر، وSanitize  کردن ورودی‌ها را ارزیابی می‌کند.دسترسی پذیری (Availability): این ویژگی میزان توانایی سیستم در ارائه خدمات مداوم و بدون وقفه به کاربران را می‌سنجد. در سیستم های فرانت اند قابلیت‌های مربوط به برنامه‌های وب پیش‌رونده (PWA) اهمیت بالایی برای این معیار دارند. از دیگر موارد مهم برای این ویژگی کیفی می‌توان مکانیزم های Fallback هنگام قطعی یا اختلال در سرویس‌های بک اند را نام برد.نگداری پذیری (Maintainability): این ویژگی کیفی میزان قابل تغییر بودن پروژه، تلاش مورد نیاز برای بازآرایی (Refactor)، یا توسعه فیچر های جدید بدون ایجاد مشکل و عوارض جانبی غیرمنتظره یا بدهی فنی (Technical Debt) را ارزیابی می‌کند.عملکرد (Performance): توان سیستم در رندرینگ (Rendering Throughput)، راه‌اندازی اولیه باندل (Bundle Initialization)، چرخه‌های به‌روزرسانی State و معیارهای کلیدی عملکرد وب (مانند First Meaningful Paint / Web Vitals) را اندازه‌گیری می‌کند. این معیار ها تاثیر مهمی بر قابلیت سامانه در حفظ کاربران و افزایش تعامل آنها (User Retention and Engagement) می‌گذارند.تست‌پذیری (Testability): این معیار مقدار تلاش مورد نیاز برای تست کردن سیستم فرانت اند را اندازه می‌گیرد. برخی از عوامل مهم برای این معیار مقدار تلاش مورد نیاز برای ایزوله کردن مولفه های UI، کنترل بر روی State ها، و قابلیت مشاهده State های مخفی سیستم هستند.2.3 فریمورک های فرانت انددر این بخش به معرفی مختصر فریمورک های ایجاد شده برای توسعه سیستم های فرانت اند می‌پردازیم. این فریم ورک ها اغلب با هدف مدیریت وضعیت واکنش پذیر (State Reactivity) و همچنین مدیریت پیچیدگی‌های ساختاری در سیستم های فرانت اند ایجاد شده اند. تقریبا همه ی فریمورک های محبوب و مورد استفاده امروزی تاکید بالایی بر استفاده از کامپوننت در توسعه سیستم ها دارند. در ادامه سه فریمورک محبوب تر که به طور گسترده در صنعت مورد استفاده قرار می‌گیرند یعنی React, Vue, و Angular را معرفی می‌کنیم:React: یک کتابخانه Declarative برای ایجاد رابط های کاربری است که بجای استفاده سنتی از DOM (Document Object Model)، از Virtual DOM استفاده می‌کند تا رندر کردن رابط های کاربری را بهینه تر کند. React همچنین بر ترکیب کامپوننت‌ها (component Composition) و جریان یک‌طرفه داده‌ها (مسیر انتقال مستقیم داده ها فقط از والد به فرزند) تاکید دارد. این فریمورک توسط شرکت Meta یا همان Facebook سابق به صورت متن باز ایجاد شده و محبوب ترین کتابخانه برای توسعه سیستم های فرانت اند به شمار می‌رود.Angular: انگولار فریمورک جامعی است که چارچوب های مشخصی را برای توسعه دهندگان تعریف کرده و از معماری Component-Based پیروی می‌کند. این فریمورک قابلیت هایی همچون مدیریت State واکنش پذیر، Routing، Dependency Injection را به توسعه دهندگان ارائه می‌کند. Angular چارچوب های سختگیرانه تری از React را برای توسعه دهندگان تعریف کرده و در بسیاری موارد آنها را مجبور به رعایت قوانین از پیش نوشته خود در ساختار پروژه و معماری می‌کند. این فریمورک توسط گوگل و به صورت متن باز ایجاد شده است.Vue: یک فریمورک Progressive است بدین معنا که به توسعه دهندگان این قابلیت را می‌دهد تا آنرا به هر اندازه ای که می‌خواهند و در مکان های مورد نظر خود در پروژه شان استفاده کنند. Vue از معماری Component-Based پیروی کرده و قابلیت هایی از جمله مدیریت State، مدیریت Event، و Reactive Data Binding را به توسعه دهندگان ارائه می‌کند. Vue در مقایسه با Angular کمتر سختگیر است و به دلیل Progressive بوده، یادگیری و آغاز کار با آن ساده تر است. 3. معماری های سیستم های فرانت انددر این قسمت، به شرح برخی از پر استفاده ترین معماری های فرانت اند می‌پردازیم تا درک بهتری از آنها کسب کنیم. مطالعه این شرح به شما برای درک بهتر قسمت 4 و بررسی تاثیر هر معماری بر معیار های کیفی کمک بسیاری می‌کند. 3.1 معماری یکپارچه (Monolithic)این معماری قدیمی ترین نوع معماری در سیستم های فرانت اند است و در آن، تمام قسمت های سیستم از جمله رابط کاربری، منطق کسب و کار، استایلینگ و چینش صفحه، و State Management در یک کدبیس و باCoupling بالا قرار می‌گیرند و یکجا دیپلوی می‌شوند. با بزرگ شدن اندازه پروژه، یکپارچه بودن این معماری سبب ایجاد پیچیدگی و Coupling بسیار شده و توسعه آنرا سخت می‌کند. به همین دلیل، این معماری معمولا برای پروژه های با اندازه کوچک یا توسط افراد تازه کار استفاده می‌شود. 3.2 معماری Component-Basedاین نوع معماری بسیار رایج بوده و در React, Vue, Angular قابل استفاده است. در این معماری رابط کاربری به ماژول هایی تقسیم می‌شوند که قابل استفاده مجدد هستند و هر کامپوننت منطق و رابط کاربری مربوط به خود را مدیریت می‌کند. در واقع در معماری کامپوننت بیس با تقسیم بندی تصویر کلی پروژه به قسمت های کوچک تر، پروژه را قابل فهم تر و مدیریت آنرا آسان تر می‌کنیم. مزایای این روش امکان Reusability و بهبود Maintainability هستند. دو عیب کلی برای این روش گفته شده. اولین مشکل دشواری State Management در این روش است، زیرا مدیریت منطق و استیت در کامپوننت های مختلف پخش شده و سبب ایجاد پیچیدگی به ویژه برای سیستم های بزرگ می‌شود. دومین مشکل این روش پرفورمنس آن است که به دلیل استفاده از تعداد زیادی کامپوننت در ارتباط با هم، ممکن است سبب سنگین شده سیستم و ایجاد مشکل پرفورمنس شود. این معماری برای Single Page Application ها و اپلیکیشن هایی که رابط کاربری آنها باید ماژولار باشد (مثلا داشبورد ها و پنل ها) مناسب است. 3.3 معماری Micro Frontendsاین معماری مفهوم Micro Service را به سیستم های فرانت اند می‌آورد به طوری که در آن، سیستم کلی را به تعدادی زیر سیستم کوچک تر و مستقل از یکدیگر با امکان دیپلوی جداگانه تقسیم می‌کنیم. این معماری به ما توانایی Scalability بالایی می‌دهد زیرا تیم های مختلف می‌توانند بدون نگرانی روی قسمت های مختلف سیستم کار کنند و همینطور Release های مختلفی را مستقل از یکدیگر انجام دهند. مزیت دیگر این روش امکان تنوع در تکنولوژی های استفاده شده در هر میکرو سرویس است سبب انعطاف پذیری بیشتر می‌شود. یکی از مشکلات این معماری هماهنگ کردن میکروسرویس های مختلف با یکدیگر به ویژه هماهنگ کردن استیت ها یا داده های مشترک آنها است و دیگر مشکل آن، افزایش Network Overhead به دلیل نیاز میکرو سرویس های مختلف به برقراری ارتباط با یکدیگر است. این معماری برای اپلیکیشن های با مقیاس بزرگی است که فیچر های فراوانی دارند و توسط تیم های متفاوت و مستقل توسعه پیدا می‌کنند (مثلا فروشگاه های آنلاین و یا نرم‌افزار های سازمانی). 3.4 معماری MVP (Model-View-Presenter)در این معماری، سیستم به سه لایه تقسیم شده که Presenter به عنوان لایه میانی بین Model (داده ها) و View (رابط کاربری) عمل می‌کند. Presenter جریان داده ها میان دو لایه دیگر را کنترل کرده و با توجه به اقدامات کاربر، View را به روز رسانی می‌کند. با توجه به این که منطق کسب و کار در لایه Presenter و به صورت جدا قرار گرفته، Testability این معماری بالاتر است و می‌توان منطق را به راحتی در Presenter تست Unit کرد. همچنین جداسازی دغدغه ها در این سه لایه Maintainability سیستم را ساده تر می‌کند. مشکل این معماری Coupling زیاد میان Presenter و View است که می‌تواند ایجاد تغییر در یکی از این دو را به طور مستقل دشوار کند. 3.5 معماری MVVM (Model-View ViewModel)این معماری که مخفف Model-View-ViewModel است در فریم ورک هایی مانند Angular و Knockout.js استفاده می‌شود و در آن ViewModel به عنوان رابط میان Model و View قرار می‌گیرد. این معماری مشابه با MVP به جهت جداسازی دغدغه ها استفاده می‌شود اما تفاوت آن با MVP در Two-Way بودن Data Binding است، بدین معنا که در MVVM، هنگامی که داده ها تغییر می‌کنند به طور خودکار View نیز آپدیت شده در حالی که در MVP این کار باید به صورت جداگانه صورت بگیرد. این امر مشکل Coupling میان منطق کسب و کار و رابط کاربری را برطرف کرده و Maintainability و Testability را بهبود می‌دهد. مشکلات این روش بالا بودن هزینه Two-Way Data Binding در پرفورمنس است که ممکن است سبب ایجاد کندی شود. همچنین، با بزرگتر شدن اندازه سیستم، مدیریت ViewModel دشوار تر شده و سبب ایجاد پیچیدگی می‌شود. از این معماری در رابط های کاربری پیچیده که نیازمند به روزرسانی real-time داده ها در رابط کاربری هستند مانند داشبورد ها و یا ابزار های مدیریت سازمان استفاده می‌شود. 3.6 معماری SPA (Single-Page Application)در این معماری برخلاف وبسایت های سنتی، تنها یک صفحه HTML اصلی به کاربر ارسال شده و تغییر صفحات و محتویات آنها بدون ریلود کامل صفحه انجام می‌شود. در واقع، پس از اولین Load شدن صفحه، فرانت اند با استفاده از JavaScript و فراخوانی API ها، داده های مورد نیاز را دریافت کرده و قسمت های مختلف صفحه را به روز رسانی می‌کند. این روش سبب ایجاد تجربه کاربری روان تر و کاهش تعداد Reload های صفحه می‌شود و برای اپلیکیشن هایی که تعامل زیادی با کاربر دارند مانند پنل های مدیریتی و داشبورد ها مناسب است. یکی از مشکلات اصلی این معماری زمان اولیه Load شدن صفحه است، زیرا معمولا حجم زیادی از JavaScript باید در ابتدا دریافت و اجرا شود. مشکل دیگر SEO است، زیرا محتویات صفحه در ابتدا به صورت کامل در HTML وجود ندارند و ممکن است موتور های جستجو در پردازش آنها با مشکل مواجه شوند. همچنین، مدیریت State و Routing در SPA های بزرگ می‌تواند سبب افزایش پیچیدگی سیستم شود. 3.7 معماری SSR (Server-Side Rendering)در این معماری، صفحه HTML به طور کامل در سرور ساخته می‌شود و سپس به کاربر ارسال می‌شود. یعنی مرورگر کاربر پس از دریافت صفحه، دیگر نیاز به فراخوانی API برای گرفتن اطلاعات محتویات صفحه ندارد. این نوع معماری برای وبسایت هایی که به SEO اهمیت زیادی می‌دهند و همچنین زمان لود شدن صفحه در آنها پر اهمیت است بسیار مناسب است. مشکلات این معماری افزایش بار پردازشی در سرور و همچنین هماهنگ کردن تعاملات سمت کاربر با محتوای تولید شده در سمت سرور است. 3.8 معماری SSG (Static Site Generation)در این معماری، صفحات وب در زمان Build شدن پروژه ساخته شده و به صورت فایل های HTML ثابت  ذخیره می‌شوند. در نتیجه، برخلاف SSR که صفحه در زمان هر درخواست توسط سرور ساخته می‌شود، در SSG صفحه یک بار از قبل آماده شده و می‌تواند مستقیما از طریق CDN به کاربر ارائه شود. این روش سبب بهبود قابل توجه Load Time و Performance شده و به دلیل وجود محتوای HTML از قبل تولید شده، SEO نیز در این معماری مناسب است. همچنین، به دلیل عدم نیاز به پردازش هر Request در سرور، Scalability سیستم افزایش پیدا می‌کند. مشکل اصلی این روش، مناسب نبودن آن برای داده هایی است که دائما تغییر می‌کنند، زیرا برای اعمال تغییرات در محتویات باید مجددا Build انجام شود. همچنین، در پروژه های بزرگ تعداد زیاد صفحات می‌تواند سبب افزایش Build Time شود. این معماری برای وبسایت هایی مانند وبلاگ ها، مستندات، صفحات معرفی محصولات و سایت هایی که محتوای آنها به صورت مکرر تغییر نمی‌کند مناسب است. 3.9 معماریJamstackاین معماری جهت Decouple کردن فرانت اند و بک اند با ارائه فایل های استاتیک از طریق CDN ها، و گرفتن اطلاعات داینامیک از طریق API ها ایجاد شده است. در واقع در این معماری، بجای این که سرور هر بار صفحات را از ابتدا بسازد، فقط یک بار یک تمپلیت static از صفحه تولید کرده که از طریق CDN به کاربر ارائه می‌شود. سپس، با اجرای جاوااسکریپت داخل صفحه و فراخوانی API ها، اطلاعات داینامیک دریافت شده و در تمپلیت گذاشته می‌شوند. ارائه فایل های استاتیک از طریق CDN سبب بهبود قابل توجه در Load Time, Performance می‌شود. سیستم های Jamstack همچنین قابلیت Scalability بسیار بالایی دارند و از Security بیشتری برخوردارند. مشکلات این سیستم ها ایجاد محدودیت در تعاملات کاربر با صفحه و به روز رسانی Real-Time، و همچنین افزایش زمان Build هستند. 3.10 معماریSignal-Firstدر این معماری، Signal به عنوان مکانیزم اصلی برای مدیریت State و ارتباط میان قسمت های مختلف رابط کاربری استفاده می‌شود. Signal ها به سیستم اجازه می‌دهند تغییرات داده ها را به صورت Reactive دنبال کرده و تنها قسمت هایی از رابط کاربری که تحت تاثیر تغییر قرار گرفته‌اند را به روز رسانی کنند. در نتیجه، برخلاف روش هایی که ممکن است با تغییر یک State باعث Re-render شدن بخش بزرگی از رابط کاربری شوند، در این معماری Update ها به صورت دقیق تر و Granular انجام می‌شوند که می‌تواند سبب بهبود Performance شود. همچنین، مدیریت Reactive State در این روش ساده تر شده و وابستگی میان کامپوننت ها کاهش پیدا می‌کند. از مشکلات این معماری می‌توان به پیچیدگی درک نحوه Propagation شدن Signal ها و مدیریت State های مشترک در سیستم های بزرگ اشاره کرد. همچنین، استفاده از این معماری نیازمند آشنایی توسعه دهنده با مفاهیم Reactive Programming و Signal ها است. این معماری در فریم ورک هایی مانند Angular و SolidJS استفاده شده و برای سیستم هایی که دارای تعاملات زیاد و تغییرات مکرر در داده های رابط کاربری هستند مناسب است. 4. ارتباط معماری ها و ویژگی های کیفیدر این بخش به بررسی رابطه بین معماری های فرانت اند و ویژگی های کیفی مختلف سیستم می‌پردازیم. در شکل زیر جدولی را مشاهده می‌کنید که رابطه بین هر معماری و ویژگی کیفی را به طور خلاصه بیان می‌کند. در این جدول، o به معنی عدم تاثیر، و علامت های + و - به معنی تاثیر مثبت و منفی معماری بر بهبود ویژگی کیفی می‌باشد. وجود هر دو علامت + و – در یک خانه نشانگر وجود برخی تاثیر های مثبت و برخی تاثیر های منفی است. در ادامه‌ی، توضیحات تکمیلی برای هر خانه از جدول قرار داده شده است.شکل 1، جدول تاثیر معماری بر ویژگی های کیفی معماری یکپارچه (Monolithic Architecture)Security:مزیت: متمرکز بودن احراز هویت، دسترسی ها و سیاست های امنیتی، مدیریت امنیت سیستم را ساده تر می‌کند.عیب: وجود آسیب پذیری در یک قسمت از سیستم ممکن است در برخی شرایط کل اپلیکیشن را تحت تاثیر قرار دهد.Availability:عیب: به دلیل یکپارچگی، بروز مشکل در یک قسمت می‌تواند باعث از دسترس خارج شدن کل اپلیکیشن بشود. مقیاس پذیری ضعیف این معماری ممکن است باعث کاهش دسترسی پذیری سیستم در زمان های پر درخواست بشود. فرایند Deployment به دلیل یکپارچگی سیستم پر ریسک تر و زمانبر تر خواهد بود.Maintainability:مزیت: یکپارچه بودن پروژه در سیستم های کوچکتر می‌تواند باعث راحت تر شدن و افزایش سرعت توسعه شود.عیب: Coupling بالا با بزرگ شدن سیستم می‌تواند باعث ایجاد پیچیدگی و کد های درهم پیچیده و کثیف شود.Performance:عیب: عدم امکان اختصاص جداگانه منابع به پروسس های bottleneck سبب کاهش عملکرد می‌شود. همچنین، بزرگ بودن اپلیکیشن سمت Client می‌تواند باعث افزایش Bundle Size شده و عملکرد مربوط به لود اولیه را کاهش دهد.  معماری Component-BasedAvailability:مزیت: Error Handling در سطح Component می‌تواند برخی خطاهای رابط کاربری را محدود کرده و از از کار افتادن کل سیستم جلوگیری کندMaintainability:مزیت: این معماری با ایجاد امکان استفاده مجدد از کامپوننت ها و همچنین جداسازی دغدغه ها می‌تواند Maintinability کد را بهبود دهد.Testability:مزیت: Component ها را می‌توان به صورت مستقل و با استفاده از Unit Testing و Component-Level Testing تست کرد.Performance:مزیت: وجود Virtual DOM در فریمورک های کامپوننت بیس مانند React امکان به روز رسانی انتخابی Component ها را فراهم می‌کند و با کاهش عملیات غیرضروری روی DOM عملکرد را بهبود می‌دهد.عیب: افزایش بیش از حد تعداد کامپوننت ها سبب ایجاد Overhead هنگام رندر کردن شده و عملکرد را کاهش می‌دهد.  معماری Micro FrontendSecurity:مزیت: Isolation میان میکرو فرانت اند های مختلف می‌تواند تاثیر آسیب پذیری در یک اپلیکیشن را به داخل همان اپلیکیشن محدود کند.عیب: وجود چندین اپلیکیشن میکرو فرانت اند، مکانیزم ارتباطی میان آنها و مرزهای مختلف درDeployment باعث افزایش Attack Surface شده و مدیریت Authentication و Authorization را دشوار می‌کند.Availability:مزیت: Deployment و اجرای مستقل سرویس ها سبب می‌شود که مشکل در یک سرویس سبب از دسترس خارج شدن کل سیستم نشود.Maintainability:مزیت: این معماری امکان تقسیم بندی سیستم و تیم ها بر اساس Domain را فراهم کرده و امکان توسعه همزمان به تیم ها می‌دهد.عیب: این معماری سبب ایجاد پیچیدگی عملیاتی، نیاز به بستر مناسب برای مدیریت سیستم، پیاده سازی چند باره قابلیت های تکراری در سرویس های مختلف شده و Maintenance سیستم را دشوار کند.Testability:مزیت: هر Micro-Application را می‌توان به صورت مستقل توسعه داده و تست کرد.Performance:مزیت: هر Micro-Application می‌تواند به صورت مستقل کد و نحوه ارائه Resource های خود را بهینه کند و در صورت نیاز به منابع بیشتر Scale شود.عیب: این معماری سبب پیچیدگی ارتباط سرویس های مختلف شده که ممکن است سربار ارتباطی ایجاد کرده و عملکرد را کاهش دهد.  معماری Model-View-Presenter (MVP)Security:مزیت: جداسازی View، Presenter و Model می‌تواند میزان منطق حساس که در Presenter تحت خطر قرار می‌گیرد را کاهش دهد.Maintainability:مزیت: جداسازی سه سطح MVP به تیم های با تخصص های متفاوت (UI Designer, Developer) امکان کار مجزا می‌دهد و جداسازی دغدغه انجام می‌دهد..Testability:مزیت: کد های مربوط به Presenter را می‌توان به صورت مستقل از UI و DOM به صورت Unit Test تست کرد.  معماری Model-View-ViewModel (MVVM)Security:مزیت: همانند MVP، جداسازی UI از منطق کسب و کار منطق حساس در معرض خطر را کاهش می‌دهد.Availability:مزیت: جداسازی View و ViewModel این امکان را فراهم می‌کند که Component های رابط کاربری بدون از دست رفتن State سیستم دوباره ایجاد شوند.Maintainability:مزیت: مشابه MVPTestability:مزیت: ViewModel ها را می‌توان معمولا به صورت مستقل از Rendering Layer به صورت Unit Test تست کرد.  معماری Server-Side Rendering (SSR)Security:مزیت: عملیات حساس و منطق کسب و کار سمت سرور انجام شده و Credential ها می‌توانند خارج از محیط Client نگهداری شوند.Availability:مزیت: سرور می‌تواند به تنهایی به کاربر محتوای قابل استفاده ارائه کند بنابراین ایجاد مشکلات Rendering در کلاینت، شبکه و ... تاثیر کمتری بر Availability دارند.Maintainability:عیب: مدیریت کدی که هم در محیط Server و هم در محیط Client اجرا می‌شود پیچیدگی معماری را افزایش می‌دهد.Testability:عیب: تفاوت های میان محیط اجرای سرور و کلاینت، مخصوصا وقتی از روش رندرینگ ترکیبی استفاده می‌کنیم تحلیل و تست کامل سیستم را دشوار می‌کند.Performance:مزیت: از جایی که پردازش ها بجای مرورگر کلاینت در سرور انجام می‌شوند، عملکرد برای کلاینت هایی که توان پردازش کمتری دارند (تلویزیون های هوشمند، کامپیوتر های نهفته اتومبیل، ...) بسیار بهتر است. همچنین، SSR می‌تواند زمان Initial Content Delivery و First Contentful Paint (FCP) را بهبود دهد.عیب: نیازمند منابع پردازشی بیشتر برای سرور هستیم.  معماری JamstackAvailability:مزیت: توزیع محتوا از طریق CDN و Edge می‌تواند Availability بالایی برای محتوای Static فراهم کند.Maintainability:مزیت: جداسازی سرویس های مربوط به بک اند از مولفه های Static در فرانت اند می‌تواند سبب ساده تر شدن توسعه سیستم بشود.عیب: مدیریت API ها، توابع Serverless و سرویس های خارجی می‌تواند پیچیدگی سیستم را افزایش دهد.Testability:مزیت: با توجه به جداسازی محتوای Static از Dynamic می‌توان هر کدام را به طور مجزا و با روش های مخصوص و مناسب تر تست کرد.Performance:مزیت: CDN Caching و Asset های از قبل ساخته شده می‌توانند ارسال محتوا و به ویژه Initial Content Delivery را بسیار سریع کنند.  معماری Single-Page Application (SPA)Availability:مزیت: پس از بارگزاری اپلیکیشن، برخی قابلیت ها می‌توانند بدون نیاز به درخواست دوباره به Server به کار خود ادامه دهند. همچنین، PWA امکان ارائه آفلاین برخی فیچر ها را فراهم می‌کند.Maintainability:عیب: بزرگ و حجیم شدن SPA می‌تواند Coupling و Depencency زیادی ایجاد کند و در نتیجه نگهداری سیستم دشوار شود.Performance:مزیت: SPA با Client-Side Navigation از ریلود کامل صفحات جلوگیری کرده و انتقال های روان تری را ایجاد می‌کند. همچنین، بسیاری از عملیات در سمت کلاینت بدون نیاز به درخواست به سرور ممکن است که سبب کاهش زمان واکنش می‌شود.عیب: هنگام لود اولیه اندازه JavaScript Bundle بزرگ می‌تواند Startup Time را به ویژه در دستگاه های ضعیف یا شرایط کند شبکه به میزان قابل توجهی افزایش دهد.  معماری Static Site Generation (SSG)Security:مزیت: در این معماری، هنگام پاسخ دادن به درخواست کاربران دیگر کدی سمت سرور اجرا نمی‌شود. این امر باعث کاهش خطر در برابر برخی آسیب پذیری های زمان اجرا می‌شود.Availability:مزیت: فایل های Static تولید شده را می‌توان از طریق CDN ها و Edge Network های با Availability بالا توزیع کرد.Testability:مزیت: عوامل متغیر زمان اجرا در این معماری وجود ندارند و  HTML تولید شده را می‌توان قبل از دیپلوی کاملا تست کرد.Performance:مزیت: از جایی که کد HTML از قبل تولید شده است، نیازی به پردازش سمت سرور یا کاربر هنگام اجرا نداریم و صفحه به سرعت به دست کلاینت می‌رسد.  معماری Signal-FirstAvailability:مزیت: به روزرسانی های fine-grained رابط کاربری که در این معماری انجام می‌شوند سبب می‌شود تا بروز مشکل در یک منطقه کل سیستم را خراب نکند..Maintainability:مزیت: Reactive Dependency های مشخص می‌توانند مدیریت State ها را محلی تر کرده و درک و تغییر سسآن را ساده تر کنند.عیب: گراف هایSignal  بزرگ و به هم پیوسته می‌توانند درک و نگهداری پروژه را دشوار تر کنند.Testability:مزیت: منطق مربوط به  هایState مبتنی بر Signal را می‌توان به صورت مستقل از DOM تست کرد.Performance:مزیت: بروزرسانی های find-grained تنها قسمت های مورد نیاز در رابط کاربری را به روز رسانی کرده و در نتیجه رندر کردن های غیر ضروری را کاهش داده و سبب بهبود عملکرد می‌شود.    5. بررسی معماری های فرانت اند در پروژه های واقعیدر این بخش برای درک بهتر معماری هایی که مرور کردیم و ویژگی های کیفی مرتبط با هر کدام، به بررسی نمونه هایی از معماری های واقعی استفاده شده در پروژه های صنعتی می‌پردازیم. معماری های وبسایت هیا نتفلیکس و فیسبوک در این بخش مورد بررسی قرار می‌گیرند. منابع استفاده شده برای توضیحات این بخش در انتهای مقاله درج شده اند. 5.1 معماری نتفلیکس، میکرو فرانت اند های توزیع شده به همراه SSRنتفلیکس، در ابتدا کار خود را با یک معماری فرانت اند یکپارچه آغاز کرد، اما با بزرگتر شدن سیستم و افزایش تعداد فیچر های آن به سمت معماری میکرو فرانت اند مبتنی بر Domain رفت. در این معماری، رابط کاربری به تعدادی اپلیکیشن مستقل و مرتبط با یک حوزه مشخص مانند احراز هویت، جستجو، پخش ویدیو، پرداخت و ... تقسیم می‌شود. این قسمت ها از طریق یک API Gateway و یک لایه GraphQL Federation با یکدیگر ارتباط برقرار کرده و در نهایت در کنار یکدیگر قرار می‌گیرند. GraphQL Federation یک معماری داده مختص میکروسرویس هاست که در آن تعدادی سرویس مختلف که هر کدام با GraphQL توسعه داده شده اند و subgraph نام دارند را ادغام کرده و یک گراف دیتای یکپارچه ایجاد می‌کند. همچنین Netflix از Node.js برای انجام Server-Side Rendering استفاده می‌کند تا بخش زیادی از رابط کاربری قبل از ارسال به دستگاه کاربر تولید شود. این کار به بهبود عملکرد و لود صفحه به ویژه در دستگاه های ضعیف تر همچون تلویزیون های هوشمند کمک بسیاری می‌کند. چند تکنیک قابل توجه به کار رفته شده در معماری نتفلیکس عبارتند از:Edge SSR: برای انجام Edge SSR درخواست کاربران به نزدیک ترین سرور Edge ارسال شده، آن سرور کد های React را اجرا کرده و HTML/CSS مورد نیاز برای آن را ساخته و در درخواست قرار می‌دهد (SSR) و سپس پاسخ را برای کاربر می‌فرستد. در نتیجه، هنگامی که کاربر صفحه را دریافت می‌کند، آن صفحه به طور کامل قابل مشاهده و اجرا است.مدیریت A/B Testing در لایه Edge: تست‌های A/B به صورت مستقیم در لایهEdge   اعمال می‌شوند. تحلیل های مورد نیاز برای تست A/B و Feature Flagging در سرور انجام شده و نسخه میکرو فرانت‌اند مناسب بدون نیاز به اجرای منطق پیچیده در مرورگر سمت کاربر، برای او ارسال می‌شود.Runtime Module Orchestration: در این روش، میکو فرانت اند های مختلف می‌توانند به صورت مستقل توسعه داده شده و دیپلوی شوند و در زمان اجرای برنامه به Application Shell افزوده شوند. Application Shell وظیفه دربرگرفتن میکرو فرانت اند های مختلف کنار هم گذاشتن و نمایش آنها را بر عهده دارد.استراتژی‌های ایزوله کردن استایل ها: برای جلوگیری از نشت استایل‌ها (Style Bleeding) بین میکرو فرانت‌اند‌های مختلف در داخل Application Shell، از استراتژی‌های Scoped CSS و سیستم دیزاین اختصاصی نتفلیکس (Hawkins Design System) استفاده می‌شود. این کار باعث حفظ یکپارچگی بصری (Visual Consistency) بدون ایجاد وابستگی مستقیم کدهای تیم‌ها به یکدیگر می‌شود. تاثیر بر معیار های کیفی·        همانطور که دیدیم، معماری میکروسرویس تاثیر مثبتی بر توسعه پذیری سیستم دارد و تیم های مختلف را قادر می‌کند تا به طور همزمان به توسعه بخش های مختلف سیستم بپردازند. همچنین، هر تیم می‌تواند پایپلاین های جداگانه برای تست، CI/CD، و دیپلوی داشته باشد. همچنین، برای اعمال تغییر در یک قسمت از سیستم نیازی به Build و Deploy کردن کل برنامه وجود ندارد.·        این معماری از نظر Reliability و Fault Tolerance نیز مزایایی دارد، زیرا قسمت های مختلف سیستم تا حد زیادی از یکدیگر مستقل هستند. بنابراین، اگر یک Micro-Frontend غیر ضروری مانند بخش پیشنهاد فیلم ها با مشکل مواجه شود، این خطا لزوما باعث از کار افتادن Application Shell یا قسمت های اصلی مانند پخش ویدیو نمی‌شود.·        از نظر Performance، استفاده از Edge SSR سبب کاهش زمان نمایش اولیه محتویات صفحه و بهبود معیار هایی مانند First Contentful Paint (FCP) و Time to Interactive (TTI) می‌شود. این موضوع به ویژه برای دستگاه هایی با منابع سخت افزاری محدود مانند تلویزیون های هوشمند ها اهمیت بیشتری دارد.·        در مقابل، پیچیدگی یکی از مشکلات اصلی این معماری است. از آنجایی که قسمت های مختلف سیستم به صورت مستقل توسعه پیدا می‌کنند، مدیریت State های مشترک، و مدیریت قابلیت های مشترک مانند احراز هویت، Routing و Telemetry پیچیده تر می‌شود. بنابراین، اگرچه این معماری Scalability و سرعت توسعه بالایی ایجاد می‌کند، اما مدیریت زیرساخت و پلتفرم را پیچیده تر می‌کند.  5.2 معماری فیسبوک: Monolithic Componentization with Declarative Data-Fetchingهمانطور که گفتیم React در ابتدا توسط شرکت متا و به هدف استفاده در داخل شرکت توسعه داده شد. بنابراین عجیب نیست که فیسبوک بر بستر این فریمورک توسعه داده می‌شود. فیسبوک از معماری Monolithic Componentization استفاده می‌کند. در این معماری، کل وب‌سایت در قالب یک مخزن کد یکپارچه نگهداری می‌شود، اما ایزوله‌سازی و استقلال تیم‌های توسعه مختلف نه در سطح برنامه یا دامنه (Domain)، بلکه در سطح کامپوننت اعمال می‌گردد. فیسبوک از ترکیب React، Relay (GraphQL Client) و Atomic CSS استفاده می‌کند. استفاده ازFragment Co-Location در GraphQL و Atomic CSS به فیسبوک کمک می‌کنند تا بدون احتیاج به جداسازی کد بیس سرویس های مختلف، بتواند کامپوننت های مختلف را ایزوله کند (توضیح این دو مورد در قسمت بعد آورده شده اند). چند تکنیک قابل توجه به کار رفته در فیسبوک عبارتند از:Declarative Co-Location: این تکنیک به کمک Relay پیاده سازی شده و در آن، هر کامپوننت React با استفاده از یک Fragment در GraphQL داده های مورد نیاز خود را مشخص می‌کند و بنابراین برای دریافت داده ها به مولفه والد خود وابسته نیست. سپس، Relay Compiler این Fragment ها را در زمان بیلد با یکدیگر ترکیب کرده و یک کوئری بهینه تولید می‌کند. همچنین، این کامپایلر فیلد های تکراری را حذف کرده و تایپ های مورد نیاز را به صورت static تولید می‌کند.Atomic CSS Extraction: این مکانیزم با استفاده از StyleX پیاده سازی می‌شود. در این روش، استایل مربوط به هر کامپوننت در کنار کد همان کامپوننت نوشته می‌شود، اما در زمان بیلد توسط یک پلاگین استخراج شده و به کلاس های CSS استاتیک و Atomic تبدیل می‌شود. در نتیجه، بجای تولید استایل های جداگانه برای هر کامپوننت، کلاس های کوچک و قابل استفاده مجدد ایجاد می‌شوند.ارسال داده تدریجی (@defer / @stream): برای جلوگیرى از تاخیر در نمایش UI، بخش‌های اصلی صفحه سریع تر رندر شده و بخش‌های سنگین‌تر یا با اولویت کمتر با استفاده از @defer و @stream به صورت تدریجی دریافت و به UI افزوده می‌شوند. تاثیر بر معیار های کیفی·        این معماری بر Maintainability تاثیر مثبتی دارد زیر استایل های CSS و کوئری های دیتا مستقیما در داخل کامپوننت مربوط به خود قرار گرفته اند که سبب افزایش ماژولاریتی و Encapsulation می‌شود. در نتیجه، توسعه دهندگان می‌توانند یک کامپوننت را جابجا، تغییر یا حذف کند بدون این که نیاز باشد قسمت های مختلف CSS یا Query های قرار گرفته در بخش های دیگر سیستم را تغییر دهند.·        از نظر Performance، این معماری مزایا و معایب مختلفی دارد و درواقع یک Tradeoff است. از یک طرف، استفاده از Atomic CSS باعث می‌شود با افزایش تعداد کامپوننت ها، حجم CSS به صورت متناسب با اندازه کل Codebase افزایش پیدا نکند، زیرا کلاس های CSS میان کامپوننت های مختلف قابل استفاده مجدد هستند. همچنین Relay با ترکیب Fragment ها و ایجاد یک Query بهینه، از دریافت داده های اضافی و ایجاد چندین درخواست پشت سر هم جلوگیری می‌کند. از طرف دیگر، وابستگی زیاد این معماری به اجرای JavaScript در سمت کاربر و همچنین انجام عملیات Graph Normalization در مرورگر، می‌تواند در زمان اجرای اولیه برنامه فشار پردازشی زیادی به CPU وارد کند. این مشکل به ویژه در دستگاه هایی که قدرت پردازشی پایینی دارند چالش های بیشتری را ایجاد می‌کند.·        این معماری از نظر Testability مزیت هایی را برای ما فراهم می‌کند. Type های تولید شده توسط GraphQL و Fragment های هر کامپوننت به توسعه دهنده اجازه می‌دهند به راحتی وضعیت های مختلف داده را برای تست Mock کنند و نیازی به اتصال واقعی به سرویس های API وجود نداشته باشد. 6. جمعبندی و نتیجه گیریتوسعه سیستم‌های فرانت‌اند در طول سال ها از تولید صفحات استاتیک و ساده به سیستم‌های پیچیده، توزیع‌شده و واکنش‌پذیر در سمت کلاینت تحول یافته است. انتخاب معماری و فریم‌ورک برای این سیستم ها تنها یک تصمیم فنی ساده نیست، بلکه تصمیمی استراتژیک است که تاثیر مستقیمی بر ویژگی‌های کیفی سیستم از جمله عملکرد (Performance)، نگه‌داری‌پذیری (Maintainability)، مقیاس‌پذیری (Scalability)، و تست‌پذیری (Testability) می‌گذارد. نیازمندی سیستم های مدرن از جمله پیچیدگی رابط‌های کاربری، حجم بالای منطق مورد اجرا در مرورگر کاربر، و نیاز به پاسخگویی سریع صفحه به تعاملات کاربر باعث شده اند تا انتخاب معماری به یکی از عوامل مهم در موفقیت سیستم‌های نرم‌افزاری تبدیل شود.در این تحقیق، الگو های معماری فرانت اند مختلفی را بررسی کردیم. همان طور که انتظار می‌رفت، دیدیم که یک معماری واحد وجود ندارد که به همه نیازمندی های کیفی پاسخ مناسبی بدهد و انتخاب هر معماری Tradeoff ی است که بر برخی جنبه ها تاثیر مثبت و بر برخی جنبه ها تاثیر منفی می‌گذارد. برای مثال، معماری‌های ساده‌تر می‌توانند پیچیدگی توسعه و نگه‌داری را کاهش دهند، اما ممکن است در سیستم‌های بسیار بزرگ از نظر مقیاس‌پذیری یا جداسازی اجزا محدودیت داشته باشند. در مقابل، معماری‌های پیچیده‌تر امکان جداسازی بهتر مسئولیت‌ها و توسعه مستقل بخش‌های مختلف را فراهم می‌کنند، اما هزینه بیشتری از نظر پیچیدگی، هماهنگی و نگه‌داری ایجاد می‌کنند.یکی دیگر از نتایج مهم این بررسی، وابستگی شدید تصمیم معماری به حوزه مسئله (Domain) و شرایط عملیاتی سیستم است. برای یک وب‌سایت محتوایی با تعاملات محدود، استفاده از معماری پیچیده سمت کلاینت ممکن است هزینه غیرضروری ایجاد کند، در حالی که برای یک نرم‌افزار تعاملی و بزرگ مانند سامانه‌های مدیریت سازمانی، پلتفرم‌های آنلاین یا نرم‌افزارهای مبتنی بر داده، معماری‌های ساختاریافته‌تر می‌توانند مزایای قابل‌توجهی در زمینه نگه‌داری و توسعه‌پذیری ایجاد کنند. به همین دلیل، نمی‌توان یک معماری را صرفاً بر اساس محبوبیت آن یا استفاده گسترده در صنعت به‌عنوان بهترین گزینه انتخاب کرد.در نهایت، ماتریس تاثیر معماری ها بر ویژگی های کیفی که در این تحقیق ارائه کردیم نشان می‌دهد که مهندسان و معماران نرم‌افزار باید پیش از انتخاب فریم‌ورک یا معماری، نخست نیازمندی‌های کیفی کلیدی و حوزه مسئله سیستم خود را مشخص کرده، و متناسب با نیازمندی مختص به پروژه خود، مناسب‌ترین ترکیب معماری را انتخاب کنند. 7. منابعوبسایت Mediumوبسایت Engeenering facebook comوبسایت hashbyt[1] Arruat, M., Fernandez, L., Jackson, S., Locci, F., Nougaret, J.-L., Peryt, M., Radeva, A., Sobczak, M., & Vanden Eynden, M. (2007). Front-end software architecture. Proceedings of the 11th International Conference on Accelerator and Large Experimental Physics Control Systems (ICALEPCS 2007), 18–20.[2] Chen, W. (2025). Analysis and research on computer website front-end development technology and optimization measures. Proceedings of the 2025 International Conference on Digital Management and Information Technology (DMIT 2025), 1–6.[3] Cunha de Amorim, G., & Dias Canedo, E. (2025). Micro-frontend architecture in software development: A systematic mapping study. Proceedings of the 27th International Conference on Enterprise Information Systems (ICEIS 2025), 2, 105–116.[4] Kurapati, L. (2024). Different types of architectures in frontend design and development. International Journal for Multidisciplinary Research (IJFMR), 6(5), 1–5.[5] Offutt, J. (2002). Quality attributes of web software applications. IEEE Software, 19(2), 25–32.[6] Sarkar, R. (2025). The future of frontend architecture: How micro frontends will transform the software industry forever. International Journal of Innovative Science and Research Technology (IJISRT), 10(11), 519–521.[7] Tkachenko, O., Chechet, A., Chernykh, M., Bunas, S., & Jatkiewicz, P. (2025). Scalable front-end architecture: Building for growth and sustainability. Informatica, 49(1), 137–150. اين مطلب، بخشي از تمرينهاي درس معماري نرم‌افزار در دانشگاه شهيدبهشتي استکیانوش آرینکیانوش آرینSun, 09 Aug 2026 19:21:03 +0330https://virgool.ir/@m_98739531/سخنرانی-when-to-use-microservices-and-when-not-to-sam-newman-martin-fowler-goto-2020-x8ctvunktqlsسخنرانی When To Use Microservices (And When Not To!) • Sam Newman & Martin Fowler • GOTO 2020سخنرانان: Sam Newman, Martin Fowlerلینک ویدیو: https://www.youtube.com/watch?v=GBTdnfD6s5Q&pp=ygUPU2FtIE5ld21hbiBRQ29uدر این سخنرانی، مارتین فاولر و سم نیومن به گفتگو درباره چالش های معماری میکرو سرویس و نحوه شکستن سیستم های مونولیت به میکروسرویس صحبت می‌کنند.سخنرانان بیان می‌کنند که انتخاب پیش‌فرض در معماری سیستم باید یک مونو‌لیت تک‌پروسسی (Single-process monolith) باشد، مگر اینکه معماران بتوانند دلیل قانع کننده ای برای تغییر معماری ارائه کنند. یکی از اشتباه های بزرگ صنعت نرم‌افزار این است که به جای خروجی و هدف نهایی، روی خود ابزار و فناوری تمرکز می‌کند. میکروسرویس‌ها در واقع فرآیند پرهزینه‌ای هستند که برای شما گزینه‌های تصمیم‌گیری جدیدی می‌خرند، اما این گزینه‌ها برای سازمان هزینه هایی خواهند داشت.مزایای استفاده از معماری میکروسرویس:دیپلوی مستقل: دلیل اصلی برای استفاده از میکروسرویس‌ها قابلیت دیپلوی مستقل است. دیپلوی مستقل به این معنی است که بتوان قابلیت خاص را تغییر داد و دیپلوی کرد، بدون اینکه نیاز باشد کل سیستم تغییر کند. میکرو سرویس ها همچنین امکان دیپلوی بدون قطعی (Zero downtime).  را فراهم می‌کنند.جداسازی داده‌ها و پردازش آن‌ها: این موضوع برای رعایت حریم خصوصی (مانند GDPR) بسیار مهم است؛ چرا که مشخص می‌کند داده‌های حساس دقیقاً در کدام سرویس‌ها قرار دارند تا بتوانیم از نظر امنیتی بیشتر به آنها بها بدهیم.خودمختاری سازمانی (Organizational Autonomy): افزایش استقلال تیم‌ها و تقسیم مسئولیت‌ها به شکلی که نیاز به هماهنگی مداوم بین تیم‌های مختلف برای انجام یک کار کاهش یابد.معایب استفاده از معماری میکروسرویس:1. تله مونو‌لیت توزیع‌شده (Distributed Monolith): یکی از خطرات رایج این است که سیستمی بسازیم که نام آن میکروسرویس باشد، اما برای دیپلوی یک سرویس مجبور باشیم سرویس‌های دیگر را هم هم‌زمان آپدیت و دیپلوی کنیم. راهکار دوری از این تله، رعایت جدی اصل پنهان‌سازی اطلاعات (Information Hiding) درون مرزهای هر سرویس است. همچنین با بررسی الگوهای کامیت در ابزارهایی مثل جیرا می‌توان فهمید کدام سرویس‌ها همیشه با هم تغییر می‌کنند تا در صورت نیاز، آن‌ها را دوباره با هم ادغام کرد.2. چالش پیچیدگی داده‌ها (Data Complexity): سخت‌ترین بخش شکستن مونو‌لیت، جداسازی دیتابیس است. دیتابیس‌های relational به خاطر قابلیت‌هایی مثل Join و تراکنش‌های ACID کار را بسیار ساده می‌کنند، اما با حرکت به سمت میکروسرویس، این مزایا از دست می‌روند و ما را با چالش هایی مواجه می‌کنند.3. بعد سازمانی و رفتاری انسان‌ها: چالش های معماری میکروسرویس بیش از اینکه منشا فنی داشته باشند، منشا انسانی دارند. سازمان‌هایی با تفکر سنتی و مدیریت مرکزی نمی‌توانند از مزایای میکروسرویس بهره‌مند شوند. همچنین نباید یک‌شبه وظایف سنگین دِواپس و پشتیبانی تولید را به تیمی تحمیل کرد که آمادگی آن را ندارد. تغییرات در معماری سیستم باید کاملاً تدریجی و همگام با تغییرات ساختار تیم‌ها پیش برود.در کل سخنرانان این گفتگو بیان می‌کنند که میکروسرویس‌ها برای هر پروژه‌ای مناسب نیستند و استفاده از آن‌ها نیاز به درک عمیق از هزینه‌ها، پیچیدگی دیتابیس و فرهنگ سازمانی دارد.اين مطلب، بخشي از تمرينهاي درس معماري نرم‌افزار در دانشگاه شهيدبهشتي استکیانوش آرینکیانوش آرینSat, 11 Jul 2026 17:30:11 +0330https://virgool.ir/@m_98739531/سخنرانی-infoq-architecture-and-design-trends-in-2025-igib0xym61qvInfoQ Architecture and Design Trends in 2025سخنرانان: Thomas Betts, Ivar Stiller, Daniel Bryant, Sarah Wellsلینک ویدیو: https://www.youtube.com/watch?v=Fc_ECVXGu3Y&t=1021sاین ویدیو پنلی به میزبانی توماس بتس و با حضور کارشناسان شامل اران استیلر، دنیل برایانت و سارا ولز، به بررسی مهم‌ترین چالش‌ها و ترند های نوظهور معماری نرم‌افزار در سال ۲۰۲۵ می‌پردازد. مباحث مطرح‌شده در این گفتگو را می‌توان در چند دسته بندی اصلی بیان کرد:۱. استفاده از هوش مصنوعی در معماری سیستم‌ها: صحبت با بیان این موضوع آغاز می‌شود که هوش مصنوعی دیگر یک ابزار جانبی یا صرفاً چت‌بات‌های ساده نیست، بلکه معماران باید به نحوه ادغام آن در سیستم‌ها توجه کنند. مفاهیمی مانند RAG (تولید به همراه بازیابی) برای غنی‌سازی متنی مدل‌ها بدون نیاز به train مجدد و هوش مصنوعی عامل محور (Agentic AI) به عنوان روندهای کلیدی معرفی می‌شوند. در مدل عامل محور، به جای یک سیستم یکپارچه، چندین عامل هوشمند با وظایف مشخص و با استفاده از پروتکل‌هایی مانند MCP با یکدیگر و با APIها تعامل دارند. کارشناسان پیشنهاد می‌کنند که می‌توان این عامل‌ها را مانند میکروسرویس‌ها با مرزهای مشخص (Bounded Context) در نظر گرفت تا تعاملات آن‌ها قابل‌کنترل‌تر شده و از نشت داده‌های حساس به ابزارهای خارجی جلوگیری شود. همچنین مفهوم مدل‌های زبانی کوچک (SLM) برای اجرا در مرز سیستم‌ها با هدف کاهش هزینه‌ها و تأخیر بیان شد. نکته دیگر، تغییر نقش خود معماران است؛ معماران اکنون می‌توانند از ابزارهایی مثل Cursor یا Copilot و قابلیت‌هایی مانند ایجاد قوانین (Cursor Rules) راهبردها و گایدلاین‌های معماری ای را به هوش مصنوعی ارائه کنند تا در فرآیند کدنویسی استفاده شود.۲. معماری مبتنی بر سلول (Cell-Based Architecture): این رویکرد به عنوان تکاملی بر میکروسرویس‌ها معرفی شد که در آن سیستم به واحدهای مستقلی به نام سلول تقسیم می‌شود تا فرآیند جداسازی بهبود یافته و میزان آسیب حاصل از خطاها محدود شود. یکی از نمونه های آن سیستم اسلک یا استراتژی Monzo  است.3. انتقال به چپ در معماری و مدیریت بار شناختی: مفاهیمی مانند مهندسی حریم خصوصی و نرم‌افزارهای سبز (مشابه مدل‌سازی تهدیدات اما با تمرکز روی پایداری و کاهش مصرف کربن و هزینه‌ها) اکنون از همان ابتدای طراحی سیستم در آن لحاظ می‌شوند. هرچند انتقال این وظایف به مراحل اولیه فرآیند توسعه هزینه‌های اصلاحات بعدی را به شدت کاهش می‌دهد، اما ریسک بزرگی به نام افزایش بار شناختی (Cognitive Load) بر توسعه‌دهندگان و معماران را به همراه دارد.4.  معماری پلتفرم و کوبرنتیز: معماری پلتفرم (مثلا کوبرنتیز) به عنوان یک راهکار مهم برای حل چالش بار شناختی مطرح می‌شود. پلتفرم باید به عنوان یک محصول توسعه یابد تا با ایجاد یک مسیر مشخص، رعایت اصول امنیتی، پایداری و حریم خصوصی را بدون درگیر کردن توسعه‌دهنده با جزئیات پیچیده، به ساده‌ترین کار ممکن تبدیل کند. برایانت اشاره می‌کند که امروزه ارتباط عمیقی بین معماری نرم‌افزار و پلتفرم شکل گرفته و حتی معماران اپلیکیشن نیز به دلیل بسته‌بندی‌های نوین نرم‌افزاری، مجبور به یادگیری پلتفرم‌هایی مثل کوبرنتیز هستند.اين مطلب، بخشي از تمرينهاي درس معماري نرم‌افزار در دانشگاه شهيدبهشتي استکیانوش آرینکیانوش آرینSat, 11 Jul 2026 17:01:29 +0330https://virgool.ir/@m_98739531/سخنرانی-building-evolutionary-architectures-rebecca-parsons-neal-ford-james-lewis-goto-2023-ccydqookgk7a Building Evolutionary Architectures • Rebecca Parsons, Neal Ford & James Lewis • GOTO 2023سخنرانان: Rebecca Parsons, Neal Ford, James Lewisلینک ویدیو: https://www.youtube.com/watch?v=m2ZlX1je3as&t=1sدر این ویدیو گفتگویی میان جیمز لوئیس، ربکا پارسونز (مدیر ارشد فناوری ThoughtWorks) و نیل فورد را می‌بینیم که در آن درباره کتابشان به نام ساخت معماری‌های تکاملی صحبت می‌کنند. ایده اصلی این کتاب ترکیب مفاهیم محاسبات تکاملی و الگوریتم‌های ژنتیک با معماری نرم‌افزار می‌باشد.ابتدا، سخنرانان به تعریف معماری تکاملی پرداخته و آن را معماری ای تعریف می‌کنند که از تغییرات تدریجی و هدایت شده در ابعاد متفاوت نرم‌افزار پشتیبانی می‌کند. منظور از هدایت شده در این تعریف، استفاده از Fitness Function ها برای ارزیابی سیستم است. برخلاف کدنویسی که اصولی کلی و ثابت دارد و صحت آن به طور دقیق قابل اندازه گیری است، قانون مطلقی برای خوب بودن یک معماری نداریم و ویژگی‌های یک معماری موفق وابسته به نیازهای خاص آن سیستم و سازمان است. Fitness Function ها در واقع ابزارهایی (مانند تست‌های واحد معماری) هستند که معیارهای حیاتی سیستم مثل امنیت، مقیاس‌پذیری و کیفیت کد را در طول زمان و در مواجهه با فشار تحویل پروژه زیر نظر گرفته و به حفظ آن کمک می‌کنند.یکی از نکات مهم در این کتاب که بیشتر در ویرایش دوم آن ایجاد شد، تمرکز روی ساختار معماری و مسئله جفت‌شدگی (Coupling) است. نیل فورد با اشاره به مفهوم هم‌زادی (Connascence) که اولین بار در سال ۱۹۹۳ مطرح شد، بیان می‌کند که کنترل هم‌زادی‌های پویا و محدود کردن مرزهای جفت‌شدگی، همان چیزی است که به سیستم اجازه می‌دهد بدون ایجاد مشکل در سایر بخش‌ها تغییر کند. همچنین، مفهوم کوانتوم معماری (Architecture Quantum) به عنوان کوچک‌ترین واحد مستقل و قابل استقرار در معماری‌های توزیع‌شده معرفی می‌شود که به کنترل جفت‌شدگی‌های استاتیک و پویا کمک می‌کند. همچنین تأکید می‌شود که معماری تکاملی صرفاً محدود به میکروسرویس‌ها نیست و اگر معماری های مونولیت دارای مرزهای دقیق باشد، می‌تواند از اصول معماری تکاملی استفاده کند.در نهایت، نویسندگان اشاره می‌کنند که این رویکرد بیش از آنکه یک متدولوژی فرآیندی باشد، یک تغییر نگرش و مجموعه‌ای از مهندسی فرآیندهاست. با پیشرفت ابزارهایی مثل داکر، کوبرنتیز و زیرساخت به عنوان کد (IaC)، امکان آزمایش و توسعه تکاملی بسیار بیشتر از گذشته فراهم شده است. به عنوان توصیه پایانی برای مهندسان ارشد سخنرانان پیشنهاد می‌کنند که ابتدا حیاتی‌ترین ویژگی‌های معماری سیستم خود را شناسایی و مکتوب کنند و Fitness Function ها را بر اساس اولویت‌های واقعی سازمان توسعه دهند.اين مطلب، بخشي از تمرينهاي درس معماري نرم‌افزار در دانشگاه شهيدبهشتي استکیانوش آرینکیانوش آرینSat, 11 Jul 2026 15:25:26 +0330https://virgool.ir/@m_98739531/سخنرانی-software-architecture-the-hard-parts-neal-ford-mark-richards-goto-2023-hwbnosilloqnSoftware Architecture: The Hard Parts • Neal Ford & Mark Richards • GOTO 2023سخنرانان: Neal Ford, Mark Richardsلینک ویدیو: https://www.youtube.com/watch?v=rIgTE9aDVj4&t=2sدر این سخنرانی، نیل فورد و مارک ریچاردز درباره کتاب جدیدشان به نام Software Architecture: The Hard Parts صحبت می‌کنند. سخنرانان به بررسی چالش‌های موجود در معماری‌های توزیع‌شده (مثل میکروسرویس‌ها) و فرآیند تکامل ایده‌هایشان می‌پردازند. به نظر من نقطه قوت این فیلم این بود که نشان می‌داد چطور مفاهیم پیچیده و انتزاعیِ مهندسی نرم‌افزار را می‌توان با استفاده از داستان‌سرایی و فرآیندهای تکرارپذیر (Iterative) به اصول کاربردی تبدیل کرد.سخنرانان توضیح می‌دهند که ایده این کتاب زمانی شکل گرفت که در حال نگارش کتاب قبلی خود یعنی اصول معماری نرم‌افزار بودند و مدام با مسائل بسیار سختی برخورد می‌کردند که در آن کتاب جای نمی‌گرفت. آن‌ها ساختار کتاب جدید را به دو بخش کلی 1- جدا کردن اجزا از هم و 2- کنار هم قرار دادن مجدد آن‌ها تقسیم کردند. این تقسیم‌بندی بسیار منطقی است، زیرا نشان می‌دهد که بالا بردن ماژولاریتی پایان کار نیست و تازه چالش‌های ارتباطی و مدیریت داده‌ها بعد از آن آغاز می‌شود.یکی از جذاب‌ترین بخش‌های فیلم، توضیح فرآیند نگارش کتاب بود. فورد و ریچاردز در نوشتن این کتاب از فرایند مشابه با توسعه نرم‌افزار چابک، یعنی حلقه های بازخورد (Feedback Loops) استفاده کردند؛ یعنی ابتدا ایده‌ها را در کلاس‌های آموزشی و کنفرانس‌ها با مخاطبان به اشتراک می‌گذاشتند و بر اساس بازخورد آن‌ها، مفاهیم را پخته‌تر می‌کردند. برای ملموس کردن مباحث انتزاعی نیز از یک سناریوی واقعی و داستانی به نام Sysops Squad (یک سیستم ثبت تیکت خرابی) استفاده کردند که هر فصل با گفت‌وگوی بین اعضای این تیم فنی شروع می‌شود. این کار به فهم چرایی تصمیمات معماری در دنیای واقعی کمک بسیاری می‌کند.بزرگ‌ترین دستاورد علمی که در این گفت‌وگو به آن اشاره شد، کشف ارتباط متقابل بین سه نیروی اصلی در سیستم‌های توزیع‌شده بود: ارتباطات (همگام/ناهمگام)، سازگاری داده‌ها (اتومیک/نهایی) و هماهنگی (ارکستریشن/کوروگرافی). سخنرانان بیان کردند که نمی‌توان این تصمیمات را مستقل از هم گرفت؛ مثلاً تیم‌ها اغلب برای بالا بردن کارایی، ارتباطات را ناهمگام (Async) می‌کنند، بدون اینکه متوجه باشند این کار بار سنگینی روی مدیریت تراکنش‌ها و هماهنگی سیستم می‌گذارد و یا گاهی آن‌ها را به سمت ترکیب ناهمگام، کوروگرافی و تراکنش atomic هدایت می‌کند که پیاده‌سازی بسیار پیچیده ای دارد.در نهایت، فیلم بر اهمیت «تحلیل سبک‌سنگین کردن ویژگی‌ها» (Trade-Off Analysis) تأکید می‌کند؛ چرا که در پروژه‌های جدید اعداد و ارقام دقیقی برای ارزیابی نداریم و باید بر اساس اصول معماری حرکت کنیم. پیام اصلی فیلم این است که معماری نرم‌افزار صرفاً ابزارها و نحوه پیاده‌سازی (How) نیست، بلکه درک عمیق «چرایی» (Why) تصمیمات و پیامدهای حاصل از انتخاب‌های ماست.کیانوش آرینکیانوش آرینSat, 11 Jul 2026 15:09:10 +0330https://virgool.ir/@m_98739531/تمرین-اول-معماری-نرم-افزار-ckganjp6hamdکیانوش آرین  404443009تمرین اول معماری نرم‌افزار 1. Chaos Engineeringدر Chaos Engineering، برای این که عملکرد سیستم را تحت شرایط خاص بررسی کنیم خودمان مشکلات مختلفی در آن ایجاد می‌کنیم و بررسی می‌کنیم که سیستم چه واکنشی نشان می‌دهد. مثلا درگاه های خارجی (مثلا درگاه پرداخت، پیامک و ...) را قطع می‌کنیم، دیتابیس را قطع می‌کنیم، سرعت اینترنت سرور را کم می‌کنیم، یا سیستم را تحت فشار ترافیک بالا قرار می‌دهیم. پس از بررسی رفتار سیستم، می‌توانیم چاره هایی بیاندیشیم تا اگر زمانی این مشکلات واقعا در پروداکشن پیش آمدند، سیستم Resilience  و Robustness بیشتری داشته باشد. از معروف ترین ابزار هایی که برای Chaos Engineering پدید آمده اند می‌توان Chaos Monkey را نام برد که توسط Netflix ایجاد شده که به طور رندوم VM های مختلف در محیط Production را از کار می‌اندازد تا بتوانیم رفتار سیستم را در آن شرایط بررسی کنیم. 2. Backend for Frontendدر بسیاری از اپلیکیشن های تحت وب، تنها یک بک اند توسعه می‌دهیم و در تمام فرانت اند هایمان (مثلا اپ سمت کاربر، اپلیکیشن سمت ادمین، در گوشی، دسکتاپ،...) از همان یک بک اند استفاده می‌کنیم. از جایی که منطق مورد نیاز در  فرانت اند های مختلف تا حد زیادی شبیه به یکدیگر است توسعه ی یک بک اند برای تمامی آنها منطقی به نظر می‌رسد. اما مشکل آنجاست که نیازمندی های non-functional در فرانت اند های مختلف، مثلا سمت کاربر و ادمین، با یکدیگر متفاوت هستند و ممکن است اپ سمت کاربر هزاران درخواست در ساعت داشته باشد درحالی که اپ سمت ادمین تنها چند صد درخواست در روز دارد، یا فرانت اند های مختلف از نظر سطح امنیت با یکدیگر متفاوت باشند. بنابراین، معماری Backend for Frontend پیشنهاد می‌دهد که برای هر frontend مختلف، یک سرویس backend مخصوص به خودش ایجاد کنیم تا متناسب با نیاز های آن front-end به آن سرویس ارائه کند. این معماری چهار مزیت کلیدی دارد.1.      داده های ارائه شده به هر فرانت اند دقیقا به اندازه نیازش است، بنابراین باعث کاهش استفاده از اینترنت، شارژ موبایل و ... می‌شود.2.      وابستگی بین تیم های توسعه مختلف به دلیل جداسازی دغدغه ها کاهش می‌یابد.3.      پیچیدگی در فرانت اند های مختلف کاهش می‌یابد زیرا دیگر لازم نیست با بک اند بزرگ و کلی ارتباط برقرار کنند.4.      به دلیل اضافه کردن یک لایه BFF میانی، امنیت را افزایش می‌دهد. 3. AI4SEبه طور کلی هر گاه که از هوش مصنوعی برای کمک در قسمتی از مهندسی نرم‌افزار استفاده کنیم، به آن AI4SE گفته می‌شود. امروزه با پیشرفت های مدل های بزرگ زبانی ابزار های بسیاری از جمله Cursor, Windsurf, Claude Code و ... ایجاد شده که توانایی انجام کار هایی از جمله تولید کد، دیباگ کردن، ایجاد داکیومنتیشن، و حتی اجرای دستورات در shell و تست کردن نرم‌افزار را دارا هستند.  به غیر از کمک در برنامه نویسی، می‌توان از این ابزار ها در مراحل دیگر مهندسی نرم‌افزار از جمله تولید و بررسی مورد های کاربری، نیازمندی ها و ... استفاده کرد. 4.  SE4AISE4AI به هنگامی گفته می‌شود که از اصول مهندسی نرم افزار برای ایجاد یا بهبود و مدیریت سیستم های هوش مصنوعی استفاده کنیم. برای مثال، میدانیم که سیستم های هوش مصنوعی غیر قابل پیش بینی هستند، و این غیر قابل پیش بینی بودن تست کردن عملکرد آنها را دشوار می‌کند. یکی از سوال های زمینه SE4AI این است که چگونه سیستمی طراحی کنیم که بتواند عملکرد ایجنت های هوش مصنوعی را تست کند. یا ممکن است نیاز داشته باشیم تا Guardrail هایی را بر روی مدل های هوش مصنوعی نصب کنیم تا پاسخ های غیرقابل قبول یا محرمانه به کاربران ندهند. این Guardrail ها باید سیستم های قابل اعتماد نرم‌افزاری باشند تا مطمئن باشیم در صورت تولید پاسخ های نامناسب، این پاسخ ها به کاربران نمایش داده نشود. یا مثلا برای تولید، آزمایش و مقایسه Prompt هایی که برای استفاده از مدل های هوش مصنوعی استفاده می‌کنیم نیاز به یک سیستم مدیریت متن داریم که باید تحت اصول مهندسی نرم‌افزار تولید شود. به این گونه کارکرد های مهندسی نرم‌افزار برای بهبود و مدیریت سیستم های هوش مصنوعی، SE4AI گفته می‌شود. 5.  MLOpsایجاد سیستم های مبتنی بر یادگیری ماشین شامل مراحل مختلفی از جمله جمع آوری داده، pre-process، یادگیری، ارزیابی، دیپلوِی، و مانیتورینگ می‌باشد. در MLOps، به طراحی pipeline هایی می‌پردازیم که قسمت هایی از این فرایند را خودکار کنند. برای مثال، با وارد شدن داده های جدید، به طور خودکار مدل را دوباره train کرده و دیپلوی و ارزیابی کنند. این کار CT (Continuous Training) نام دارد. همچنین، ورژنینگ نسخه های مختلف مدل، پارامتر ها و وزن های مدل به همراه مانیتور کردن عملکرد مدل ها و تشخیص Data Drift و Concept Drift از جمله کار هایی هستند که در MLOps انجام می‌شوند. 6. Infrastructure as Codeدر Infrastructure as Code، بجای آن که سرور، دیتابیس، یا شبکه را به صورت دستی مدیریت و کانفیگ کنیم، برای انجام آن اسکریپت هایی می‌نویسیم تا آن عملیات را به طور خودکار انجام دهند. مثلا هر بار بعد از تعویض سرور، برای انجام تنظیمات اولیه بجای انجام دستی این تنظیمات، برای آنها اسکریپت و کانفیگ های آماده ای ایجاد می‌کنیم تا این تنظیمات راحت تر انجام شوند. از مزایای IaC می‌توان امکان خودکار سازی، مستند سازی تنظیمات، عدم وابستگی به یک شخص خاص برای انجام تنظیمات، و مقیاس پذیری ساده تر را نام برد. Ansible و Terraform از معروف ترین ابزار ها جهت انجام این کار هستند. برای ایجاد IaC ها، دو روش Imperative و Declarative وجود دارد. در روش Imperative به ترتیب Command هایی که باید انجام شوند را بیان می‌کنیم، در حالی که در روش Declarative یک توصیف از وضعیت مطلوب سیستم (مثلا یک فایل yml) به ابزار های IaC ارائه می‌کنیم و این ابزار ها، عملیات مورد نیاز برای رسیدن به وضعیت مطلوب را برای ما انجام می‌دهند. 7. API Gateway and Service Meshدر روش ارتباط API Gateway، یک Gateway کلی داریم که کلاینت ها برای تمامی عملیات خود به آن Gateway مراجعه کرده و API مورد نیاز خود را فراخوانی می‌کنند. این مدل یک مدل client to service است که در آن کلاینت ها به سرویس (همان API Gateway) مراجعه می‌کنند. درحالی که Service Mesh، یک مدل service to service می‌باشد و معمولا برای مدیریت ارتباطات میان میکروسرویس ها استفاده می‌شود. در این مدل، در کنار هر میکروسرویس یک پروکسی به نام Sidecar قرار می‌دهیم (که به آن Data Plane نیز گفته می‌شود) و این پروکسی، تمامی ارتباطات ورودی و خروجی میکروسرویس را مدیریت می‌کند. همچنین یک Control Plane داریم که پروکسی ها را مدیریت کرده و به هر Sidecar می‌گوید که چگونه ارتباطات را مدیریت کند، پروتکل های امنیتی را اعلام کرده و آنها را مانیتور می‌کند. این مدل ارتباطی سبب می‌شود تا مدیریت ارتباطات بین سرویس ها ساده تر شده، امنیت افزایش پیدا کرده و قابلیت مشاهده سیستم بالا برود. 8. Command Query Responsibility Segregationمعماری CQRS عملیاتی که در داده ها تغییر ایجاد می‌کنند (update, delete, create) را از عملیاتی که تغییری ایجاد نمی‌کنند (read) جدا کرده و دسته اول را command ها و دسته دوم را query ها نام‌گذاری می‌کند. همچنین، این معماری دیتامدل های مورد استفاده توسط کامند ها و کوئری ها را کاملا از یکدیگر جدا کرده و حتی این قابلیت را به ما می‌دهد که برای هر کدام از دیتابیس های مختلفی استفاده کنیم. این کار به پرفورمنس ما کمک می‌کند زیرا می‌توان از دیتابیس های مختلف بهینه شده برای هر کدام از عملیات های خواندن و تغییر داده ها استفاده کرد. همچنین این معماری به ما قابلیت scalability زیادی برای دیتابیس کوئری ها می‌دهد زیرا این دیتابیس ها معمولا از سرعت بسیار بالا تری برخوردارند. همچنین با استفاده از این معماری می‌توان می‌توان مدیریت امنیت و پیچیدگی را بیشتر در سمت command ها نگاه داشت و آنها را از قسمت query ها جدا کرد. 9. Event-Driven Architectureدر معماری Event-Driven، کامپوننت های مختلف از طریق تولید و واکنش دادن به Event های مختلف با یکدیگر ارتباط برقرار می‌کنند. در این معماری، سه عضو کلیدی وجود دارند. اولین عضو، Event Producer ها هستند که همان کامپوننت های تولید کننده Event هستند و پس از ایجاد شرایط خاصی، یک Event تولید کرده و ارسال می‌کنند. این کامپوننت ها اطلاعی از دریافت کنندگان ایونت ندارند و تنها آنرا تولید کرده و ارسال می‌کنند. دومین عضو، Event Router ها هستند که در واقع middleware هایی هستند که ایونت ها را دریافت کرده و ایونت های متناسب با نیاز هر کامپوننت مصرف کننده را به آن هدایت می‌کنند. سومین عضو، Event Consumer ها هستند که ایونت ها را دریافت کرده و متناسب با آنها واکنش نشان می‌دهند. هر consumer به تعدادی Event خاص Subscribe کرده و هر گاه آن Event منتشر شود، از آن مطلع می‌شوند. این معماری مزایایی از جمله Loose Coupling و ارتباط Async میان کامپوننت ها را به ما می‌دهد زیرا کامپوننت ها برای مطلع شدن از یکدیگر، نیازمند به ارسال درخواست و دریافت پاسخ ندارند. همچنین، این معماری Scalability و Flexibility سیستم را افزایش می‌دهد. 10. Serverless Architectureدر معماری Serverless، بجای این که توسعه دهنده یک سرور خریداری کرده و تمام زیرساخت های لازم را روی آن سرور بالا بیاورد، از سرویس های Cloud مانند آمازون، گوگل، و یا Azure برای اجرای کد ها استفاده می‌کند. در این معماری، توسعه دهنده Function های مختلفی را تعریف می‌کند و آنها را بر روی Cloud قرار می‌دهد. این فانکشن ها به صورت Event-Driven اجرا شده و در ابتدا غیر فعال بوده، و پس از یک ایونت (مثلا درخواست کاربر، آپلود فایل، ...) فراخوانی شده و وظایف خود را انجام داده و دوباره خاموش می‌شوند. در این روش توسعه دهندگان لازم نیست هزینه کامل سرور را پرداخت کنند و می‌توانند تنها به اندازه فراخوانی شدن فانکشن هایشان پول بپردازند. همچنین، Scaling و هندل کردن کاهش و افزایش بار درخواست ها توسط ارائه دهنده سرویس Cloud به طور خودکار انجام شده و از دغدغه های توسعه کننده حذف می‌شود. 11.  API-first Approachدر این روش پیش از آغاز توسعه، ابتدا API ها به طور کامل طراحی شده و endpoint های آنها، فرمت و داده های درخواست و پاسخ و مستندات API ها به طور کامل مشخص می‌شوند تا تمام تیم ها از کارکرد آنها کاملا مطلع باشند. این به تیم های مختلف توسعه کمک می‌کند تا از فرمت نهایی درخواست ها آگاه باشند، و بتوانند توسعه بخش مربوط به خود را (مثلا front-end) با کمک داده های mock که از مستندات API استخراج شده پیش ببرند و به طور موازی کار کنند. 12. Domain Driven Designدر DDD، سعی می‌کنیم تا ساختار کلاس ها و کدمان تا جای ممکن شبیه به ساختار کسب و کار باشد. برای مثال، اگر برای یک فروشگاه دارای موجودیت های "مشتری"، "کالا" و "پرداخت" یک سیستم طراحی می‌کنیم، تقسیم بندی و نامگذاری کلاس های این سیستم را نیز به شکل "مشتری"، "کالا" و "پرداخت" انجام می‌دهیم. این روش یک زبان مشترک به تیم های مختلف از جمله افراد کسب و کار و افراد فنی می‌دهد، برای مثال وقتی کسی از "مشتری" صحبت می‌کند، همه می‌فهمند که منظور از این مشتری چه موجودیتی است. همچنین، در حوزه های گسترده ای که یک کلمه ممکن است در چندین مکان به معانی مختلف استفاده شود، context های مختلف تعریف می‌شوند. مثلا context انبار و context فروشگاه می‌توانند هر دو دارای موجودیت "مشتری" باشند اما معنی این مشتری در این دو context متفاوت تعریف می‌شود. به این عمل، Bounded Context می‌گویند. 13. Hexagonal Architectureدر معماری Hexagonal، منطق کسب و کار با استفاده از تعدادی Adapter به طور کامل از دیگر قسمت ها محافظت می‌شود. در واقع بجای این که منطق کسب و کار به طور مستقیم با UI و DB در ارتباط باشد، تعدادی Adapter در میان این ارتباط قرار می‌گیرند و به عنوان واسط بین منطق کسب و کار و دیگر اجزا نقش ایفا می‌کنند. همچنین، تعدادی Port تعریف می‌شوند که قوانین و شرایطی که Adapter ها برای ارتباط با خارج باید از آنها پیروی کنند را مشخص می‌کنند. به دلیل Decouple شدن قسمت های مختلف نرم‌افزار، می‌توان هر قسمت را به طور جداگانه و بدون نگرانی از تغییرات خارجی تست کرد، و یا کامپوننت های مختلف از جمله دیتابیس را بدون نگرانی از خراب کردن دیگر قسمت های نرم‌افزار تعویض کرد. همچنین، این معماری امکان توسعه جداگانه قسمت های مختلف نرم‌افزار توسط تیم های مختلف را فراهم می‌کند. 14. Event Sourcingدر سیستم های عادی، داده ها را به شکل یک مقدار عددی یا متنی نگه داری می‌کنیم. اما در Event Sourcing، بجای این که تنها یک عدد یا متن برای مقدار فعلی داده ها داشته باشیم، یک لیست نگهداری می‌کنیم که تمامی تغییرات داده از ابتدا تا انتها در آن نگهداری می‌شوند. مثلا، برای آدرس کاربران مقدار لیست می‌تواند اینگونه باشد:address.added (Tehran)address.updated (Shiraz)این گونه بجای تنها مقدار فعلی، سابقه تمامی تغییرات داده ها را داریم و این به ما امکان انجام انواع تحلیل های داده، دیباگ با کمک بازسازی استیت گذشته برنامه و ... می‌دهد. همچنین، با استفاده از این روش عملیات update بجای تغییر ویرایش مقدار قبلی تنها لازم است یک مقدار جدید به لیست Append کند که از نظر پرفورمنس عملکرد بهتری دارد. 15. Low-Code / No-Code Platformsاین پلتفرم ها، با ایجاد زیر ساخت های تصویری و منطقی به کاربران امکان ایجاد برنامه هایی بدون کد نویسی یا با مقدار بسیار کم کد نویسی می‌دهند. ایجاد برنامه در این پلتفرم ها بسیار ساده تر از برنامه نویسی سنتی است و می‌تواند توسط هر شخصی که لزوما با اصول برنامه نویسی آشنا نیست با هزینه کمتر انجام شود. در مقابل، این برنامه ها انعطاف پذیری کمتری به توسعه دهنده می‌دهند و امکان انجام هر عملی را برای افراد فراهم نمی‌کنند. از این پلتفرم ها برای ایجاد و آزمایش دمو های اولیه و کاهش هزینه ها استفاده می‌شود. از جمله این پلتفرم ها می‌توان Bubble, Zapier, Glide و Webflow را نام برد. 16. Business Process Management SystemsBPMS ها سیستم هایی هستند که فرایند های سازمانی را کامپیوتری و خودکار می‌کنند. برای مثال، اگر یک فرایند سازمانی شامل مراحلی از جمله ارسال نامه، بررسی توسط بخش مالی، امضای مدیر عامل، اعلام تایید هست، این فرایند ها داخل نرم افزار BPMS به شکل فایل های BPMN (Business Process Model and Notation) تعریف شده و مراحل آن هر بار به طور سیستماتیک به ترتیب اجرا می‌شود و به طور خودکار برای افراد مختلف از جمله مدیر عامل، بخش مالی، و ... ارسال می‌شوند. این برنامه ها معمولا در سازمان های بزرگ استفاده شده و به خودکار سازی فرایند ها، نظارت بر آنها، مانیتورینگ و گزارش گیری کمک فراوانی می‌کنند. از معروف ترین برنامه های BPMS میتوان به Camunda, jBPM, Bizagi اشاره کرد. 17. Message Queue (Kafka, RabbitMQ)Message Queue ها واسط هایی هستند که در میان دو سیستمی که می‌خواهند با یکدیگر ارتباط برقرار کنند قرار می‌گیرند و بجای این که این سیستم ها به طور مستقیم با یکدیگر ارتباط برقرار کنند، پیام ها را به این Queue داده و یا از آن دریافت می‌کنند. این Queue ها در مدیریت ارتباطات مثلا هنگام شلوغ بودن و یا در دسترس نبودن سیستم ها کمک می‌کنند تا ارتباط به شکل Async انجام شده و سیستم ها بتوانند طبق زمان بندی خودشان و هر وقت که بخواهند پیام ها را دریافت و به آنها رسیدگی کنند. Kafka یکی از این ابزار هاست که به طور خاص برای سیستم های بزرگ با حجم بالای ارتباطات مثلا چندین میلیون پیام تولید شده و RabbitMQ یکی دیگر از این ابزار هاست که برای ارتباطات Reliable ایجاد شده است. 18. Containers (Docker) and Container Orchestration (Kubernetes)کانتینر ها محیط هایی برای اجرای نرم‌افزار هستند که تمامی سورس کد، Dependency ها، تنظیمات، و محیط اجرای نرم‌افزار ها را در خود جمع آوری کرده و قابلیت اجرای آنها را بر روی هر سیستمی با Virtualization فراهم می‌کنند. با کمک کانتینر ها، اجرای برنامه در یک محیط جدید بدون نیاز به ورژن کنترل و انجام دوباره تنظیمات محیط برقرار می‌شود. Docker معروف ترین ابزار Containerization است که تمامی مولفه های مورد نیاز برای اجرای نرم‌افزار را در Docker Image ها جمع آوری می‌کند. هنگامی که تعداد زیادی کانتینر (صد ها و یا هزاران) داشته باشیم که به صورت توزیع شده برنامه را اجرا می‌کنند، به یک ابزار نیاز داریم که مدیریت لود، اسکیل کردن، ریکاوری از مشکلات، و به روز رسانی نرم‌افزار را برای این تعداد از کانتینر ها انجام دهد. به این کار Container Orchestration گفته می‌شود و توسط ابزار هایی از جمله Kubernetes به طور خودکار انجام می‌شود. این ابزار، هر کانتینر (یا تعدادی کانتینر به شدت مرتبط با یکدیگر) را در یک Pod قرار داده، و Pod ها را بین Node ها که سرور های اجرا کننده هستند پخش می‌کند. به تمامی Node هایی که برای اجرای نرم‌افزار با یکدیگر همکاری کرده و کار می‌کنند Cluster گفته می‌شود. 19. Multi-Tenacy Architectureدر معماری Multi-Tenacy، تعدادی گروه کاربر مختلف از یک نرم‌افزار استفاده می‌کنند، بدون این که داده ها و تنظیمات هر گروه بر استفاده از نرم‌افزار گروه دیگر تاثیر بگذارد. برای مثال، ممکن است که چندین شرکت از یک نرم‌افزار CRM (مدیریت ارتباطات با مشتری) استفاده کنند. در این صورت، داده های هر شرکت، باید به روشی از داده های دیگر شرکت ها جداسازی شود. چند روش برای انجام این کار وجود دارد. روش اول جداسازی کامل دیتابیس ها است، به طوری که نرم افزار مورد استفاده توسط هر گروه کاربر از یک دیتابیس کاملا جداگانه استفاده می‌کند. روش دوم، جداسازی Schema هاست، به طوری که نرم افزار همیشه از یک دیتابیس استفاده کرده، اما هر گروه کاربر Schema مخصوص به خود را دارد. روش سوم، استفاده از دیتابیس و Schema مشترک، و جداسازی رکورد های مربوط به هر گروه کاربر با استفاده از ستونی مانند TenantId می‌باشد. این روش کمترین هزینه را دارد اما از نظر امنیت و ایزوله سازی، ضعیف تر از روش های دیگر است.  20.  Data MigrationData Migration هنگامی است که می‌خواهیم داده ها را از یک پایگاه داده به یک پایگاه داده دیگر منتقل کنیم. برای مثال، ممکن است بخواهیم دیتابیس خود را از PostgresSQL به MongoDB تغییر دهیم یا بجای ذخیره سازی داده ها در یک دیتابیس Cloud، آنها را در یک دیتابیس جدید در سرور و کنار خود اپلیکیشن نگهداری کنیم. در این موارد، ممکن است به دلیل تفاوت های موجود در دیتابیس های مبدا و مقصد، مانند SQL و no-SQL بودن، تفاوت در دیتا مدل ها و یا قوانین پایگاه داده، مجبور شویم عملیاتی برای هماهنگ سازی داده ها با نوع جدید ذخیره سازی انجام دهیم که به این کار Data Transform گفته می‌شود. منابع:geeksforgeeksaws amazonbytebytegoredhatwikipediasamnewmanmediumگفت و گو با Chatgpt و Gemini  کیانوش آرینکیانوش آرینSun, 31 May 2026 18:40:35 +0330https://virgool.ir/@m_98739531/کارکرد-knowledge-graphs-در-بازیابی-اطلاعات-برای-حافظه-مدل-های-زبانی-dpvv0yocu300کارکرد Knowledge Graphs در بازیابی اطلاعات برای حافظه مدل های زبانیکیانوش آرین 404443009 چکیدهبا پیشرفت و قدرتمند تر شدن مدل های زبانی، استفاده از آنها در حوزه های مختلف افزایش یافته است. اما این مدل های زبانی بی نقص نیستند و ممکن است پاسخ های غیرصحیح و ساختگی تولید کنند. همچنین، هزینه‌ی به روز رسانی و ساخت مجدد این مدل ها بسیار بالاست و امکان به روزرسانی داده های آنها به سادگی وجود ندارد. برای حل این مشکلات، راهکاری به نام Retrieval-Augmented Generation پیشنهاد شده که در آن LLM را به یک پایگاه داده خارجی متصل می‌کنند تا بتواند طبق نیاز خود از پایگاه داده اطلاعات بازیابی کند. این امر دسترسی مدل زبانی به اطلاعات جدید را فراهم می‌کند و به آن کمک می‌کند تا پاسخ هایش را بر اساس اطلاعات واقعی تولید کند. Knowledge Graph ها یک ساختار برای ذخیره سازی داده ها هستند که موجودیت ها و روابط میان آنها را در گراف ذخیره سازی می‌کنند و برخی عملیات از جمله جستجو، استدلال و پیمایش در اطلاعات را ساده تر می‌کنند. در این تحقیق، به بررسی نحوه استفاده از Knowledge Graph ها به عنوان منبع دانش برای استفاده مدل های زبانی می‌پردازیم و تحقیقات موجود در این زمینه را بررسی می‌کنیم. همچنین، این روش را با روش های سنتی بازیابی اطلاعات مقایسه کرده، و نقاط ضعف و قوت آن را نسبت به این روش ها بیان می‌کنیم. 1  مقدمهمدل های زبانی در بسیاری از عملیات‌های مربوط به زبان عملکرد قابل توجهی از خود نشان داده اند ]9[، به طوری که امروزه، از مدل های زبانی در زمینه های مختلف از جمله حوزه های پزشکی، اقتصادی و ... استفاده می‌شود ]8[. بنابراین مطالعات در زمینه بهبود کارکرد این مدل ها از اهمیت ویژه ای برخوردار است. مدل های زبانی هنگام تولید پاسخ از مشکلاتی همچون تولید توهم، دشواری پردازش متن های طولانی، و فراموش کردن تدریجی رنج می‌برند. همانطور که انسان ها می‌توانند از ابزار های خارجی، مانند دفترچه یادداشت، کامپیوتر، و... برای بهبود عملکرد مغز خود استفاده کنند، مدل های زبانی نیز می‌توانند از افزونه های خارجی برای بهبود توانایی های شناختی خود استفاده کنند ]8[. یکی از مهم ترین این ابزار ها، RAG است که با کمک آن مدل زبانی بجای اتکای کامل به حافظه درونی و پارامتر های خود، به از یک منبع دانش خارجی استفاده می‌کند تا پاسخ های مناسب تری را تولید کند. Knowledge Graph ها به دلیل ماهیت ساختارمندشان گزینه ی مناسبی برای استفاده به عنوان یک حافظه خارجی برای LLM هستند.در ادامه این مقاله، با ساختار فوق به بررسی  این موارد می‌پردازیم. در قسمت دوم به معرفی و توضیح Knowledge Graph ها و کاربرد های آن می‌پردازیم. در قسمت سوم به توضیح Information Retrieval و به ویژه کاربرد آن برای توانمند سازی LLM ها می‌پردازیم و به روش های استفاده شده کنونی در این زمینه می‌پردازیم. در قسمت چهارم، به بررسی کارکرد Knowledge Graph ها در بازیابی اطلاعات برای LLM پرداخته، چندین روش معرفی شده در تحقیقات بدین منظور را شرح داده و نقاط قوت و ضعف این روش در مقایسه با روش های پیشین بررسی می‌کنیم. در انتها، در قسمت پنجم به جمع‌بندی و نتیجه گیری کلی پرداخته و یافته های تحقیق در این حوزه را با تمرکز بر نقاط قوت و ضعف، بیان می‌کنیم.  2 مروری بر ادبیات  Knowledge Graph هاKnowledge Graph گراف جهت داری است که از تعداد راس و یال تشکیل شده، به طوری که هر راس یک موجودیت در جهان واقعی را نشان می‌دهد و یال های بین رئوس، رابطه معنایی بین دو موجودیت را نشان می‌دهد [1]. بنابراین Knowledge Graph را می‌توان با یک سه تایی (موجودیت اول، رابطه، موجودیت دوم) نمایش داد. برای مثال، رابطه بین دانشجو و رشته تحصیلی‌اش را می‌تواند به صورت (کیانوش آرین، تحصیل می‌کند، مهندسی کامپیوتر) نمایش داد. 2.1  ساخت Knowledge Graph هابرای ایجاد یک Knowledge Graph، ابتدا باید دانش (موجودیت ها و روابط میان آنها)، از منابع استخراج شود. این منابع می‌توانند ساختارمند (structured) یا بدون ساختار باشند [3]، برای مثال، یک صفحه کتاب منبعی بدون ساختار است، در حالی که یک فایل Excel می‌تواند حاوی اطلاعات ساختارمندی درباره یک موضوع باشد. استخراج دانش را می‌توان به روش‌ انسانی یا اتوماتیک انجام داد. روش انسانی بسیار هزینه‌بر است، در حالی که نتایج روش اتوماتیک به دلیل اجرای خودکار توسط کامپیوتر قابل اعتماد نیست و باید ارزیابی شود. چالش های ساخت Knowledge Graph عبارتند از قابل اعتماد بودن روش استخراج دانش و ارزیابی آن، محدود بودن روش های استخراج دانش به یک زبان، و ایجاد گراف های دانش چند وجهی (متن، تصویر، …) [3]. 2.2  کارکرد هاKnowledge Graph ها کاربرد وسیعی در بسیاری از زمینه‌ها از جمله پاسخ به query ها، جستجوی معنایی، به اشتراک گذاری دانش، سیستم های پیشنهاد‌دهی، مدیریت دانش و فیلد های مختلف از جمله پزشکی، آموزش و اقتصاد دارند [2] و از این جهت، تحقیق بر روی آنها از ارزش قابل توجهی برخوردار است. در بخش های بعدی این تحقیق به بررسی کاربرد این گراف ها در پاسخ به سوال، جستجوی معنایی و بازیابی اطلاعات می‌پردازیم. برخی از مهم ترین زمینه‌های تجقیقاتی مربوط به Knowledge Graph ها به شرح زیر هستند [3]:Knowledge Graph Embeddings:انتقال گراف به یک فضای برداری. معمولا این انتقال به گونه ای انجام می‌شود که نمایش برداری رئوس و یال ها با ساختار گراف رابطه داشته باشد.Knowledge Acquisition:نحوه استخراج دانش از منابع و ایجاد گراف از آنKnowledge Graph Completion:بهبود کیفیت گراف های موجود، پیش‌بینی رئوس و یال هایی که در گراف نمایش داده نشده اندKnowledge Fusion:ترکیب دانش استخراج شده از چندین منبع و استفاده از آنها برای ایجاد یک گراف واحدKnowledge Reasoning:استدلال بر روی گراف جهت پیدا کردن اطلاعات غلط، یا پیش‌بینی روابطی که یال های فعلی آنها را نمایش نداده استکارکرد در سیستم های هوش مصنوعی:مطالعه بر کارکرد Knowledge Graph ها در سیستم های پیشنهاد، پاسخ به سوال، و یا بازیابی اطلاعاتکارکرد های عملی:استفاده در فیلد هایی از جمله آموزش، پزشکی، فضای مجازی و … 3 مروری بر ادبیات  بازیابی اطلاعات برای LLM هابا پیشرفت های اخیر در توانایی مدل های زبانی، استفاده از این مدل ها در انواع کارهای روزمره و حرفه ای افزایش پیدا کرده. اما پاسخ تولید شده توسط این مدل ها همیشه قابل اعتماد نیست، و به خصوص در کاربرد های مختص دامنه های خاص که اطلاعات کمتری در آن زمینه موجود است ممکن است پاسخ های اشتباه یا نامربوط تولید کنند. به این امر، توهم گفته می‌شود [4]. علاوه بر این، قدیمی بودن داده های Train مدل های زبانی و نیاز به اطلاعات به روز، و همچنین بدون منبع بودن پاسخ های مدل زبانی از محدودیت هایی است که استفاده گسترده از مدل های زبانی را دشوار می‌کند [5].  برای بهبود این مشکلات، روش جدید معرفی شد که در آن LLM ابتدا در یک منبع داده خارجی جستجو می‌کند تا اطلاعات مربوط را بازیابی کند، و سپس با کمک اطلاعات بازیابی شده، به سوال پاسخ دهد [5]. این روش که Retrieval-Augmented Generation یا به اختصار RAG نام دارد، می‌تواند عملکرد LLM ها در انواع کار ها را بهبود بخشد، چرا که به ما اطمینان می‌بخشد خروجی های LLM بر اساس اطلاعات بازیابی شده تولید شده اند و باعث ایجاد پاسخ های دقیق تر و قابل اعتماد تر می‌شود [6]. از جمله زمینه هایی که RAG در آن کاربرد دارد می‌توان به پاسخ‌دهی به سوالات، تولید متن و خلاصه سازی، بازیابی اطلاعات، بررسی متن، تولید و نگهداری نرم‌افزار، و تصمیم گیری اشاره کرد [6]. 3.1  نحوه بازیابی اطلاعاتبازیابی اطلاعات ممکن است از سه نوع منبع انجام شود دسته اول متن های بدون ساختار هستند، مثلا فایل text که به شکل ساده نوشته شده است. دسته دوم منبع های نیمه-ساختارمند مانند فایل PDF هستند که ترکیبی از متن و جدول ها هستند. دسته سوم منبع های کاملا ساختارمند مانند Knowledge Graph هستند که برای دستیابی به اطلاعات با دقت بالا استفاده می‌شوند [5]. برای بازیابی، مدل زبانی ابتدا یک Query تولید می‌کند، که عبارتی‌ست که میخواهیم آن را در متن جستجو کنیم، و سپس به روش های جستجوی متن مختلف مانند Embedding Search، BM25، یا روش ترکیبی، Query را در منابع جستجو می‌کند [5].  4  کارکرد Knowledge Graph در بازیابی اطلاعات برای LLM هااستفاده از Knowledge Graph برتری های زیادی بر روش‌های Unstructured و Semi-Structured برای بازیابی اطلاعات دارد. تحقیقات نشان داده که روش های جستجوی Dense Vector Similarity مانند Embedding Search در پاسخ به سوالات پیچیده از سطح عملکرد کافی برخوردار نیستند [5]. همچنین، استفاده از Knowledge Graph ها در موقعیت هایی که توضیح و تفسیر پاسخ های داده شده از اهمیت برخوردار است ضروری می‌باشد [7]. برخی مثال های دیگر از این برتری ها عبارتند از [3]:افزایش بازدهی جستجو: با توجه به این که رئوس و یال های گراف از منابع متنی بسیار بزرگ استخراج شده اند، Knowledge Graph ها می‌توانند فضای جستجو را نسبت به کل منابع متنی کاهش دهند و  عملیات را بهینه تر کرده و زمان جستجو را بهبود دهند.نتایج جستجوی دقیق تر: جستجو در Knowledge Graph ها بر اساس روابط بین موجودیت های گراف انجام می‌شود، که روشی دقیق تر از صرفا پیدا کردن شباهت بین Query و Document در روش های عادی بازیابی است.نمایش معنایی مفاهیم: در Knowledge Graph، مفاهیم به صورت مدل های Formal و متصل نمایش داده می‌شوند و قابلیت جستجوی معنایی، استدلال و گسترش Query دارند. این امر عموما سبب می‌شود موارد بیشتری بازیابی شوند و قابلیت توضیح سیستم را افزایش می‌دهد. در ادامه این بخش، به بررسی نمونه‌هایی از نحوه پیاده سازی بازیابی اطلاعات با کمک Knowledge Graph ها در تحقیقات پرداخته و نقاط قوت و ضعف آنها را بررسی می‌کنیم. 4.1.1 روش KG-RAG برای پاسخ‌دهی به پرسش هامحققان در این تحقیق [8] با پیاده سازی مدلی به نام KG-RAG به مقایسه عملکرد Knowledge Graph و روش های سنتی RAG برای پاسخگویی مدل های زبانی به پرسش هایی در دیتاست ComplexWebQuestions پرداختند. در روش KG-RAG ابتدا با استفاده از LLM ها یک Knowledge Graph از منابع متنی بدون ساختار ایجاد می‌شود. بدین منظور، LLM رئوس و یال های گراف را از منابع متنی با روش Few-Shot Learning استخراج می‌کند و گراف به طور اتوماتیک ایجاد می‌شود. همچنین، برای نمایش روابط پیچیده، سه‌تایی های موجودیت-رابطه-موجودیت خودشان می‌توانند به عنوان رئوس گراف در نظر گرفته شوند و با یک رابطه به رئوس دیگر متصل شوند. پس از ایجاد گراف، embedding های تمامی رئوس و یال های گراف محاسبه شده و در دیتابیس ذخیره می‌شود. این تحقیق، برای بازیابی اطلاعات روشی نوین به نام Chain of Explorations معرفی می‌کند که روش اجرای آن به طور فوق است:ابتدا به کمک Embedding Search، تعدادی از رئوس مشابه با Query را پیدا می‌کنیم و روابط متصل به آنها را بازیابی می‌کنیم. سپس، هر کدام را ارزیابی کرده و با کمک LLM تصمیم می‌گیریم که آیا تا این مرحله به پاسخ مورد نظر رسیده ایم یا نه. اگر به پاسخ رسیده بودیم، اطلاعات کسب شده را باز گردانده و پاسخ نهایی را تولید می‌کنیم. در صورتی که هنوز به پاسخ نرسیده بودیم، دوباره یال ها و رئوس را در سطح بعدی بازیابی کرده و عملیات را بر روی روابط جدید تکرار می‌کنیم. 4.1.2 مقایسه نتایج روش KG-RAG برای پاسخ‌دهی به پرسش ها با روش های پیشیننتیجه ی تست این پیاده‌سازی بر روی دیتاست ComplexWebQuestions نشان می‌دهد که استفاده از Knowledge Graph برای پاسخ‌دهی به سوالات به مقدار F1-Score 25% منجر می‌شود در حالی که استفاده از  embedding-rag عادی مقدار F1-Score 37% به ما می‌دهد. همچنین، مقدار توهم های تولید شده توسط Knowledge Graph مقدار %15 می‌باشد، در حالی که روش embedding-rag عادی %30 توهم تولید می‌کند. این امر نشان‌دهنده آن است که با وجود این که Knowledge Graph عملکرد ضعیف تری در بازگرداندن پاسخ صحیح سوالات دارد، اما اطلاعات غلط بسیار کمتری نیز تولید می‌کند. این امر می‌تواند در کارکرد های خاصی که به شدت به پاسخ های غلط حساس هستند، مفید باشد. همچنین، نویسنده مقاله محدودیت توان پردازشی را مانعی در راه ایجاد Knowledge Graph از دیتاست به شکل کامل و همچنین تست تمام نمونه های دیتاست بیان می‌کند.  4.2.1 روش KRAGEN برای حل مسائل پیچیده و پاسخ‌دهی در حوزه پزشکیمحققان در این روش [10] برای کاهش توهم ها و اطمینان از صحت پاسخ های مدل زبانی در حوزه پزشکی، از Knowledge Graph ها برای بازیابی اطلاعات و از Graph of Thoughts برای تحلیل و استدلال بهره گرفته اند. هدف این تحقیق این بود که ببینند آیا افزودن Graph of Thoughts به فرایند بازیابی اطلاعات با Knowledge Graph ها سبب بهبود آن می‌شود یا نه. در این روش مسئله‌ای که مدل سعی در حل آن را دارد به تعدادی زیر مسئله مستقل شکسته شده و ارتباطات میان آنها (وابستگی های اطلاعاتی و پیش نیاز ها) به شکل یک گراف جهت دار نمایش داده می‌شوند (Graph of Thoughts). سپس، اطلاعات مورد نیاز برای هریک از زیر مسئله های داخل گراف با بازیابی اطلاعات از پایگاه داده استخراج می‌شود. بدین منظور، یک دیتاست با ساختار Knowledge Graph از اطلاعات پزشکی (بیماری ها، دارو ها، ویروس ها و ...) را انتخاب کرده، و آنرا به Embeddings تبدیل کرده، و در آن به صورت هیبرد Keyword Search و Embedding Search کردند. انجام Keyword Search به این دلیل اهمیت دارد که در حوزه پزشکی، اصطلاحات کمیاب و خاص بیشتر وجود دارد و Embedding Search به تنهایی، برای این نوع اطلاعات عملکرد ضعیف تری دارد. سپس، مدل با استفاده از پاسخ هر زیر مسئله و با توجه ارتباط زیر مسائل مختلف در گراف برای رسیدن به جواب صحیح استدلال کرده و جواب نهایی مسئله را تولید می‌کند. 4.2.2 نتایج روش KRAGENنویسندگان برای ارزیابی تاثیر این روش، آنرا بر روی دیتاست Alzheimer's Knowledge Graph پیاده سازی کرده و نتایج دو حالت زیر را مقایسه کردند:در حالت اول مطابق شرح بالا، از Graph of Thoughts به همراه بازیابی اطلاعات از Knowledge Graph استفاده شد.در حالت دوم، بدون استفاده از Graph of Thoughts و تنها با بازیابی اطلاعات به همراه Knowledge Graph به سوالات پاسخ داده شد.نتایج آزمایش نشان داد که افزودن Graph of Thoughts به بازیابی اطلاعات سبب بهبود نتایج در پاسخ‌دهی به سوالات چهار گزینه‌ای و صحیح / غلط می‌شود. در سوالات چند گزینه ای تک مرحله ای (یک بار بازیابی از Knowledge Graph) عملکرد از 56.6% به 70.4% بهبود یافته و در سوالات دو مرحله ای (دو بار بازیابی از Knowledge graph) عملکرد از 53.1% به 71.8% بهبود می‌یابد. در سوالات صحیح / غلط تک مرحله ای، accuracy از 68.6% به 80.3% و در سوالات دو مرحله ای، از 62.4% به 62.9% بهبود یافتند. بنابراین، نتایج نشان می‌دهند که افزودن Graph of Thoughts به بازیابی اطلاعات توسط Knowledge Graph ها سبب بهبود قابل توجه در نتایج این روش می‌شود.  4.3.1 LLAMAREC، سیستم پیشنهاد فیلم با کمک LLM و Knowledge Graphنویسندگان این تحقیق [11] در ابتدا بیان می‌کنند که روش های سنتی RAG که برای سیستم های توصیه استفاده می‌شوند تنها بر پایه شباهت معنایی کلمات بازیابی را انجام می‌دهد و ارتباطات ساختاری میان سلیقه کاربر و آیتم های توصیه شده را در نظر نمی‌گیرند. برای مثال، برای پیشنهاد فیلم سینمایی به کاربران عوامل زیادی از جمله کارگردان، بازیگران، ژانر، خلاصه، سال انتشار، و ... می‌تواند در تصمیم‌گیری موثر باشند که بسیاری از این ارتباطات در جستجوی معنایی از دست می‌روند. بنابراین، نویسندگان یک Knowledge Graph از فیلم ها ایجاد کرده، و می‌کوشند با یافتن ارتباطات میان فیلم های مورد علاقه کاربران با فیلم های کاندید برای معرفی، فیلم های کاندید را بر حسب علایق کاربران اولویت بندی کنند. بدین منظور، ابتدا با یک مدل سبک وزن مانند LRURec تعدادی کاندید برای پیشنهاد به کاربر استخراج می‌شود. سپس، زیر گرافی شامل فیلم های مورد علاقه کاربر به همراه کاندید های پیشنهادی برای بررسی بیشتر از Knowledge Graph استخراج می‌شود. در این مرحله، Knowledge Graph به یک شبکه عصبی داده می‌شود تا به کمک آن، مهم ترین عوامل در علایق کاربر (کارگردان، ژانر، ...) پیدا شده و قوی ترین ارتباطات میان علایق و فیلم های پیشنهادی کاندیدا یافت شود. خروجی این مرحله، این ارتباطات هستند که به شکل زیر نمایش داده می‌شوند.Alex -> Likes -> Christopher Nolan -> Directed -> Dunkirkسپس، این ارتباطات برای هر یک از فیلم های کاندید به مدل زبانی داده شده و از آن خواسته می‌شود تا یک عدد به عنوان احتمال تماشای این فیلم توسط کاربر خروجی بدهد. فیلم ها، بر اساس احتمالات داده شده توسط مدل زبانی، اولویت بندی می‌شوند. 4.3.2 مقایسه نتایج LLAMAREC به همراه Knowledge Graphبرای ارزیابی این روش، نویسندگان مدل LLAMAREC را در دو حالت با استفاده از Knowledge Graph و شبکه عصبی و بدون استفاده از آنها بر روی دو دیتاست فیلم ها و محصولات آرایشی آمازون مقایسه کرده اند.نتایح مقایسه در دیتاست فیلم ها بهبود قابل توجه 22.5% در پیشنهاد اولویت اول (NDCG@1)، و بهبود 7% در 5 اولویت اول (NDCG@5) را نشان می‌دهد، در حالی که در دیتاست محصولات آرایشی آمازون بهبود کمتر 5% در پیشنهاد اولویت اول و بدون بهبود در 5 اولویت اول دیده می‌شود. نویسندگان بهبود کمتر در پیشنهاد لوازم آرایشی را به دلیل sparse تر بودن گراف محصولات آرایشی و ارتباطات کمتر میان آیتم ها در این گراف می‌دانند.همچنین، مقاله یک آزمایش دیگر برای مشاهده تاثیر شبکه عصبی بر بهبود پیشنهادات انجام می‌دهد و نتایج، نشان‌دهنده اهمیت بیشتر شبکه عصبی هستند به طوری که بدون وجود آن، Knowledge Graph به تنهایی عملکرد بسیار ضعیفی از خود نشان می‌دهد.  4.4.1 KRGAR-SC، انتقال معنایی و بازسازی پیام در محیط های با پهنای باند کم و نویز بالا به کمک Knowledge Graph هادر این مقاله، سیستم ارتباطی ای با بازدهی بالا به کمک Knowledge Graph ها و LLM ها طراحی شده است تا در محیط هایی که به دلیل نویز و یا محدودیت های مختلف از جمله پهنای باند امکان ارسال پیام های طولانی موجود نیست، بتوان با حداقل انتقال اطلاعات و رساندن مفهوم، ارتباط برقرار کرد. بدین منظور، لازم است که فرستنده و گیرنده هر دو یک Knowledge Graph یکسان از entity ها و relation های میان آنها و توضیحات برای هر entity ای که در پیام مورد بحث قرار می‌گیرد را در اختیار داشته باشند. عملکرد این مدل بدین صورت است که ابتدا پیام اصلی که احتمالا طول بلندی دارد در نظر گرفته می‌شود و با Named Entity Recognition، رئوس گراف مرتبط با مفاهیم موجود در پیام، به همراه ارتباط این مفاهیم (یال های گراف) از پیام استخراج می‌شوند. کامیونیتی های داخل Knowledge Graph اصلی، به جهت پیدا کردن Entity های مناسب تر با مفاهیم داخل پیام جستجو می‌شوند و Entity های استخراج شده توسط یک LLM بررسی می‌شوند. سپس، بجای این که کل پیام برای مقصد ارسال شود، یک زیرگراف مینیمم از Knowledge Graph اصلی که از پیام استخراج شده برای مقصد ارسال می‌شود که به عنوان استخوان بندی اصلی پیام در نظر گرفته می‌شود. هنگام ارسال، به Entity های مرکزی تر (Centrality) اولویت بالاتری داده می‌شود و هنگام ارسال برای آنها سیستم پیشگیری از خطای بیشتری در نظر گرفته می‌شود تا اگر نویز محیط ارسال را خراب کرد، نود های مهم تر با احتمال کمتری خراب شوند. در نهایت، گیرنده Entity های گراف را دریافت کرده، توضیحات این نود ها را از گراف استخراج کرده و به LLM می‌دهد تا با توجه به روابط گراف، پیام را بازسازی کند. 4.4.2 مقایسه عملکرد KGRAG-SC با روش های پیشین از جمله Huffman Codingبرای بررسی عملکرد این روش، نویسندگان از دیتاست WebNLG استفاده کرده و معیار ارزیابی صحت انتقال پیام ها را Semantic Similarity میان پیام ارسال شده و دریافت شده با استفاده از مدل AllMiniLM-L6-v2 در نظر گرفته اند. نتایج ارزیابی نشان می‌دهد که در شرایط نویز بسیار بالا، روش KGRAG-SC بهبود قابل توجه‌ی نشان می‌دهد، به طوری که در نویز 4db، شباهت معنایی این روش 0.78 است در حالی که روش Huffman شباهت 0.285 به ما می‌دهد. در نویز بالاتر از 8db، روش Huffman به عملکرد تقریبا بی نقص 0.997 می‌رسند که کمی بیشتر از روش ابداعی این تحقیق در 0.882 است. بنابراین نتیجه این آزمایش به ما نشان می‌دهد که روش KGRAG-SC در شرایط محیطی با نویز بسیار بالا، به ما بهبود قابل توجهی در انتقال پیام می‌دهد در حالی که با بهبود شرایط و کاهش نویز، روش های سنتی برای انتقال پیام عملکرد بهتری از خود نشان می‌دهند.  4.4.1 روش Graph-RAG برای پاسخ‌دهی به کوئری های سطح بالابازیابی اطلاعات به روش های سنتی مانند embedding search تنها تعداد محدودی از قطعات اطلاعات متن اصلی را به ما می‌دهند درحالی که برای برخی تسک ها مانند خلاصه سازی متنهای طولانی و استخراج مفهوم از متن، به کل متن نیاز داریم و قطعات محدود بازیابی شده توسط روش های سنتی کافی نیستند. بنابراین، نویسندگان این تحیق [13] یک فریمورک سطح بالا برای فهم تمامی محتوای متن پیشنهاد کرده اند که حتی برای متن های بسیار طولانی با بازدهی مناسبی عمل می‌کند. این فریمورک، ابتدا با استخراج Entity ها و Relation ها از متن اصلی، یک Knowledge Graph ایجاد کرده و سپس با الگوریتم Leiden بر روی آن Community Detection انجام می‌دهد. Community های ایجاد شده در سه سطح Top-Level، Sub-Communities و Leaf-Level ایجاد می‌شوند. سپس، برای هر Community یک خلاصه توسط LLM تولید می‌شود. این خلاصه برای کامیونیتی های سطح برگ توسط رئوس و یال های گراف ایجاد شده، و ای کامیونیتی های سطح بالا تر توسط خلاصه های کامیونیتی های سطح پایین زیرمجموعه شان تولید می‌شود. در این مرحله، آماده سازی داده ها به پایان می‌رسد. هر بار که از مدل زبانی پرسشی درباره متن صورت بگیرد، مدل پاسخ را بر حسب خلاصه هر یک از Community ها تولید کرده، و در نهایت ترکیب این پاسخ ها به پاسخ کلی مسئله می‌رسد. 4.4.2 نتایج ارزیابی روش KG-RAGبرای ارزیابی، مدل پیشنهادی با دو مدل Vector RAG (بازیابی اطلاعات سنتی) و Source Text Summarization (خلاصه سازی مستقیم متن توسط LLM) مقایسه شده و معیار های Comprehensiveness و Diversity پاسخ های تولید شده ارزیابی می‌شود. در مقالات خبری، روش Vector RAG عملکرد 25.23 (تعداد فکت هایی از مقالات خبری مختلف استخراج شده) داشت در حالی که روش Graph RAG با مقدار 34.18 فکت، عملکرد بهتری در پاسخگویی به سوالات نشان داد. روش Text Summarization عملکرد کمی ضعیف تر از مدل Graph RAG داشته، اما مصرف توکن آن 26% تا 97% بیشتر از آن بوده. این نتایج نشان می‌دهند که GraphRAG، هم از لحاظ بهینه بودن در استفاده از منابع و هم از لحاظ عملکرد، بر روش های پیشین برتری دارد و می‌تواند بهتر به Query های جامع پاسخ دهد. همچنین، عملکرد پاسخ‌دهی GraphRAG با استفاده از سطوح مختلف Community ها مقایسه شده و نتایج نشان دادند که سطوح پایین تر Community ها (ریز دانه تر)، عملکرد بهتری نسبت به سطوح بالا دارند اما توکن بیشتری نیز برای تولید جواب استفاده می‌کنند  5  نتیجه گیری و جمع‌بندیLLM ها با وجود توانایی قابل توجه در انجام عملیات های مربوط به زبان طبیعی، از مشکلاتی همچون توهم، دشواری استدلال و فراموش کردن رنج می‌برند. استفاده از Knowledge Graph برای بازیابی اطلاعات می‌تواند به بهبود این مشکلات کمک کند. Knowledge Graph ها با ارائه اطلاعات به صورت ساختارمند، امکان بازیابی دانش مورد نیاز را فراهم می‌کنند تا LLM ها بتوانند پاسخ هایی مناسب تر با نیاز کاربر تولید کنند. در این مقاله، نحوه پیاده سازی بازیابی اطلاعات با کمک Knowledge Graph ها به این منظور شرح داده شد و همچنین برتری های آنها بر روش های سنتی بازیابی اطلاعات ذکر شد. همچنین، چند مثال از پیاده سازی های موردی Knowledge Graph برای بازیابی اطلاعات شرح و بررسی شد. نتایج تحقیقات به ما نشان دادند که استفاده از Knowledge Graph ها نسبت به روش های بازیابی اطلاعات سنتی، می‌تواند منجر به کاهش توهمات مدل های زبانی شود ]8[. این درحالی‌ست که دیگر تحقیقات نشان می‌دهند چگالی روابط داخل Knowledge Graph می‌تواند بر کیفیت پیشنهاد‌ها در سیستم های پیشنهاد کننده به کمک LLM تاثیر مستقیم بگذارد و هر چقدر روابط کامل تر باشند، پیشنهادات بهتری دریافت می‌کنیم ]11[. این گراف ها با وجود این که در برخی موارد در عین بهبود عملکرد استفاده از منابع را برای پاسخ‌گویی کاهش می‌دهند ]13[، اما به نیروی اولیه ای برای ساخت گراف نیاز دارند که ممکن است در نهایت سبب هزینه بیشتری شود. همچنین، این گراف ها ما را در خلاصه سازی و استخراج معنا از پیام های بلند یاری می‌کنند و به ویژه در محیط های با نویز بالا، امکان ارتباط سبک وزن را به کمک LLM ها را برای ما فراهم می‌کنند. همچنین، چندین مورد از تحقیقات بررسی شده از الگوریتم های Community Detection برای بهبود بازیابی اطلاعات از این گراف ها استفاده کرده اند که نشانگر اهمیت مفهوم Community ها در این حوزه می‌باشد.  6  منابع[1]  Bordes A, Weston J, Collobert R et al (2011) Learning structured embeddings of knowledge bases. In: Twenty-fifth AAAI conference on artificial intelligence[2] Zou X (2020) A survey on application of knowledge graph. JPhCS 1487(1):012016[3] Peng, C., Xia, F., Naseriparsa, M. et al. Knowledge Graphs: Opportunities and Challenges. Artif Intell Rev 56, 13071–13102 (2023).[4] Kandpal, N., Deng, H., Roberts, A., Wallace, E., & Raffel, C. (2023). “Large language models struggle to learn long-tail knowledge,” In International Conference on Machine Learning. PMLR: 5696-15707.[5] Gao, Y., Xiong, Y., Gao, X., Jia, K., Pan, J., Bi, Y., ... & Wang, H. (2023). “Retrieval-augmented generation for large language models: A survey,” arXiv preprint arXiv:2312.10997.[6] Arslan, M., Ghanem, H., Munawar, S., & Cruz, C. (2024). “A survey on RAG with LLMs,” Procedia Computer Science, 246, 3781–3790.[7] Jiaoyan Chen, Freddy Lecue, Jeff Z. Pan, Ian Hor rocks, and Huajun Chen. Knowledge-based Transfer Learning Explanation. In KR, pages 349–358, 2018.[8] Sanmartin, D. (2024). “KG-RAG: Bridging the Gap Between Knowledge and Creativity,” arXiv preprint arXiv:2405.12035.[9] Pan, J. Z., Razniewski, S., Kalo, J.-C., Singhania, S., Chen, J., Dietze, S., Jabeen, H., Omeliyanenko, J., Zhang, W., Lissandrini, M., Biswas, R., de Melo, G., Bonifati, A., Vakaj, E., Dragoni, M., & Graux, D. (2023). Large language models and knowledge graphs: Opportunities and challenges. Transactions on Graph Data and Knowledge, 1(1), 2:1–2:38.[10] Matsumoto N, Moran J, Choi H, Hernandez ME, Venkatesan M, Wang P, Moore JH. KRAGEN: a knowledge graph-enhanced RAG framework for biomedical problem solving using large language models. Bioinformatics. 2024 Jun 3;40(6):btae353. doi: 10.1093/bioinformatics/btae353. PMID: 38830083; PMCID: PMC11164829.[11] Azizi, V., & Koochaki, F. (2025). LlamaRec-LKG-RAG: A Single-Pass, Learnable Knowledge Graph-RAG Framework for LLM-Based Ranking. arXiv preprint arXiv:2506.07449.[12] Fan, D., Meng, R., Gao, S., & Xu, X. (2025). KGRAG-SC: Knowledge Graph RAG-Assisted Semantic Communication. 2025 lEEE International Conference on Cloud Computing Technology and Science (CloudCom), 1-7.[13] Edge, D., Trinh, H., Cheng, N., Bradley, J., Chao, A., Mody, A.N., Truitt, S., & Larson, J. (2024). From Local to Global: A Graph RAG Approach to Query-Focused Summarization. ArXiv, abs/2404.16130.   کیانوش آرینکیانوش آرینMon, 09 Feb 2026 23:22:38 +0330