https://virgool.ir/feed/@m_10634336دانشجوی کارشناسی ارشد IT دانشگاه شهید بهشتیfa2026-11-10 21:36:49https://virgool.ir/images/default-avatar.jpghttps://virgool.ir/@m_10634336https://virgool.ir/@m_10634336/طراحی-معماری-مرجع-برای-سیستم-های-مبتنی-بر-هوش-مصنوعی-و-llm-از-مرور-ادبیات-تا-معماری-پیشنهاد-rdcqur04ia8jمروری بر معماری سیستم‌های ML و LLM و ارائه یک معماری مرجع پیشنهادیوقتی درباره سیستم‌های مبتنی بر هوش مصنوعی و Large Language Models یا همان LLMها صحبت می‌کنیم، اولین چیزی که به نظر می‌رسد خودِ مدل است؛ اینکه GPT چیست، چه مدلی دقیق‌تر است، چطور Prompt بنویسیم یا چطور یک مدل را Fine-tune کنیم و از این قبیل سؤال‌ها.اما هرچه بیشتر با سیستم‌های واقعی مبتنی بر ML و LLM کار می‌کنیم، یک سؤال مهم‌تر خودش را نشان می‌دهد:مدل قرار است دقیقاً کجای سیستم قرار بگیرد؟یک مدل زبانی به‌تنهایی یک سیستم نرم‌افزاری محسوب نمی‌شود. در یک سامانه واقعی، مدل باید با داده، پایگاه‌های دانش، سرویس‌های نرم‌افزاری، APIها، حافظه، ابزارهای خارجی، زیرساخت اجرا، مانیتورینگ، امنیت و در نهایت کاربر ارتباط داشته باشد و از همین‌جا مسئله معماری شروع می‌شود.در این مطالعه تلاش کردم به جای اینکه فقط درباره قابلیت‌های LLMها صحبت کنم، مسئله را از زاویه Software Architecture بررسی کنم: اگر قرار باشد یک سیستم هوشمند در مقیاس واقعی طراحی کنیم، چه اجزایی باید در معماری آن دیده شوند؟ چه دغدغه‌هایی با ورود ML و LLM به سیستم به وجود می‌آیند؟ و آیا می‌توان بر اساس پژوهش‌های موجود، یک Reference Architecture قابل دفاع برای این سیستم‌ها پیشنهاد کرد؟معماری نرم‌افزار برای سیستم‌های MLیکی از منابعی که برای شروع این مسیر اهمیت زیادی داشت، پژوهش Muccini و Vaidhyanathan درباره معماری سیستم‌های مبتنی بر Machine Learning بود. از دید این پژوهش مسئله صرفاً اضافه کردن یک مدل ML به نرم‌افزار نیست و ورود ML باعث ورود مفاهیم جدیدی به فضای معماری می‌شود؛ از داده و مدل گرفته تا Data Engineer، Data Scientist و دغدغه‌هایی مانند کیفیت داده، Fairness، Privacy و قابلیت اعتماد.در معماری نرم‌افزار سنتی، معمولاً تمرکز اصلی روی اجزای نرم‌افزاری، پایگاه داده، سرویس‌ها، رابط‌ها و ویژگی‌های کیفی سیستم است. اما در یک سیستم ML، داده و مدل نیز عملاً به بخشی از معماری تبدیل می‌شوند و حتی انتخاب مدل می‌تواند روی ویژگی‌های کیفی نرم‌افزار تأثیر بگذارد. برای مثال، یک مدل پیچیده‌تر ممکن است دقت بالاتری ایجاد کند، اما در مقابل منابع محاسباتی بیشتری مصرف کند و Latency را افزایش دهد. بنابراین از همان ابتدا یک رابطه میان کیفیت مدل و کیفیت کل سیستم شکل می‌گیرد. همین موضوع باعث می‌شود معمار دیگر نتواند نرم‌افزار و ML را کاملاً جدا از یکدیگر ببیند.آیا این معماری واقعاً در دنیای واقعی پایدار است؟این سؤال ما را به سمت MLOps می‌برد.در یک سیستم ML، کار با آموزش مدل تمام نمی‌شود. داده باید مدیریت شود، مدل باید Version شود، Training باید تکرارپذیر باشد، مدل باید Deploy شود و پس از Deployment نیز رفتار آن باید Monitoring شود.پژوهش Bialek، Groenboom و Andrikopoulos دقیقاً از همین زاویه جالب است. این پژوهش با یک Systematic Mapping Study، نقطه تلاقی سه حوزه Sustainable Digital Transformation، Machine Learning و Software Architecture را بررسی می‌کند. نتیجه قابل توجه این پژوهش این بود که با وجود حجم بالای پژوهش‌ها در هر یک از این حوزه‌ها، تقاطع هر سه حوزه نسبتاً کوچک است.از میان ۱۵۰ مطالعه نهایی این پژوهش، ۱۴۲ مطالعه با Machine Learning و Sustainable Digital Transformation ارتباط داشتند، اما فقط ۱۲ مطالعه ارتباط Sustainable Digital Transformation و Software Architecture را پوشش می‌دادند و تنها ۴ مطالعه در تقاطع هر سه حوزه قرار می‌گرفتند. این نتیجه نشان می‌دهد مسئله معماری سیستم‌های ML هنوز از نظر پژوهشی کاملاً تثبیت نشده است.از طرف دیگر، بررسی اجزای MLOps نیز تصویر جالبی نشان داد: Data Curation بیشترین حضور را داشت، در حالی که مؤلفه‌هایی مانند Storage & Versioning، CI/CD و Inference در مطالعات بسیار کمتر دیده می‌شدند.به زبان ساده، در بسیاری از پژوهش‌ها درباره «مدل و داده» صحبت شده، اما معماری کامل چرخه عمر مدل هنوز به همان اندازه در دنیای پژوهشی پررنگ نیست.در اینجا یک پژوهش دیگر نیز برای این بحث اهمیت پیدا می‌کند. Najafabadi در پژوهش Reference Architecture of MLOps Workflows دقیقاً به مسئله نبود یک روش استاندارد و یکپارچه برای طراحی و مدیریت Workflowهای MLOps پرداخته و یک Reference Architecture برای این Workflowها پیشنهاد می‌کند. نکته جالب این پژوهش، علاوه بر بحث یکپارچه‌سازی اجزای مختلف MLOps، توجه به میزان مناسب دخالت انسان در Workflowهای MLOps است. بنابراین MLOps فقط مجموعه‌ای از ابزارها برای Deploy کردن مدل نیست، بلکه بخشی از معماری و چرخه عمر سیستم محسوب می‌شود.وقتی LLM وارد معماری می‌شودبا ظهور LLMها، مسئله یک لایه پیچیده‌تر می‌شود.پژوهش Schmid و همکاران که ۱۸ مقاله مرتبط با استفاده از LLMها در Software Architecture را بررسی کرده است، نشان می‌دهد LLMها تاکنون در حوزه‌هایی مانند Classification & Detection، Extraction & Generation، Reference Architectures و Architectural Assistants به کار گرفته شده‌اند. طبق این مطالعات، LLMها گاهی برای انجام کامل یک وظیفه و گاهی فقط برای یک Subtask استفاده شده‌اند.اما نکته جالب‌تر این است که بخش قابل توجهی از این پژوهش‌ها هنوز به روش‌های ساده Prompting متکی هستند. Zero-shot Prompting رایج‌ترین تکنیک گزارش‌شده بوده و تکنیک‌هایی مانند Chain-of-Thought و Retrieval-Augmented Generation هنوز حضور محدودی داشته‌اند.بنابراین اکنون یک سؤال مهم شکل می‌گیرد:اگر قرار است LLM در یک سیستم واقعی و پیچیده قرار بگیرد، آیا صرفاً قرار دادن یک API برای مدل کافی است؟بر اساس این مجموعه مطالعات پاسخ به روشنی خیر است. حال باید علت این پاسخ را بررسی کنیم.از یک LLM تنها به یک سیستم LLMیکی از منابع مهم دیگر در این مسیر، SALLMA است؛ معماری‌ای برای سیستم‌های Multi-Agent مبتنی بر LLM.ایده اصلی SALLMA این است که یک Agent منفرد محدودیت‌هایی دارد؛ برای مثال محدودیت در تخصصی‌سازی وظایف، حافظه و دسترسی به اطلاعات معتبر. در مقابل، می‌توان چند Agent تخصصی را در یک معماری هماهنگ کرد تا هرکدام وظیفه مشخصی را انجام دهند.SALLMA این ساختار را در دو لایه اصلی سازمان‌دهی می‌کند:Operational Layer برای مدیریت درخواست، اجرای وظایف و OrchestrationKnowledge Layer برای نگهداری و مدیریت دانش، Metamodelها و تنظیمات Workflowها و Agentهااین ایده برای معماری پیشنهادی من یک پیام مهم دارد:LLM نباید به عنوان یک «جعبه هوشمند» منفرد در مرکز سیستم دیده شود؛ بلکه باید بخشی از یک اکوسیستم معماری‌شده در نظر گرفته شود.از طرف دیگر، مقاله Bucaioni و همکاران با عنوان A Functional Software Reference Architecture for LLM-Integrated Systems دقیقاً به همین خلأ معماری نزدیک می‌شود. نویسندگان با اشاره به نبود یک Software Reference Architecture پذیرفته‌شده برای سیستم‌های LLM-integrated، یک Functional Reference Architecture اولیه ارائه می‌کنند و دغدغه‌هایی مانند Privacy، Security، Modularity و Interoperability را مورد توجه قرار می‌دهند. معماری آن‌ها نیز روی سه سیستم متن‌باز در حوزه‌های Computer Vision، Text Processing و Coding بررسی شده است.برای این پژوهش، اهمیت این مقاله در این است که نشان می‌دهد مسئله Reference Architecture برای LLM-integrated Systems فقط یک ایده نظری نیست و در پژوهش‌های جدید نیز به‌عنوان یک مسئله معماری مستقل مطرح شده است.اما یک معماری خوب فقط با Functional Requirements ساخته نمی‌شود!وقتی وارد سیستم‌های واقعی می‌شویم، انتخاب معماری به یک مسئله Trade-off تبدیل می‌شود.پژوهش Indykov، Wohlrab و Strüber روی چهار شرکت فعال در حوزه AI نشان می‌دهد که سازمان‌ها به صورت تکرارشونده با کیفیت‌هایی مانند Reliability، Functional Suitability و Resource Efficiency مواجه‌اند. و مهم‌تر اینکه رسیدن به یک Quality Attribute معمولاً بدون هزینه برای سایر ویژگی‌ها نیست.برای مثال کاهش منابع مصرفی می‌تواند به کاهش تست، Monitoring یا ظرفیت پردازشی منجر شود. یا مدل‌های پیچیده‌تر ممکن است Accuracy بیشتری ایجاد کنند، اما توضیح‌پذیری تصمیمات آن‌ها دشوارتر شود.بنابراین معماری پیشنهادی نباید فقط بگوید «چه اجزایی وجود دارند»، بلکه باید امکان مدیریت این Trade-offها را نیز فراهم کند.جدول 1 ـ مقایسه معماری‌ها و پژوهش‌های مرتبطمقایسه معماری‌هااین جدول نشان می‌دهد هر یک از پژوهش‌های بررسی‌شده بیشتر روی کدام بخش از مسئله تمرکز دارند و معماری پیشنهادی چگونه تلاش می‌کند این دغدغه‌ها را در کنار یکدیگر قرار دهد. و رسم این جدول به معنی برتری مطلق معماری پیشنهادی نیست؛ بلکه هدف آن نشان دادن این است که ایده معماری پیشنهادی از کنار هم قرار دادن چند خط پژوهشی مختلف شکل گرفته است.یک مسئله دیگر: مقیاس‌پذیریسیستم LLM اگر قرار باشد در محیط واقعی استفاده شود، باید بتواند با افزایش تعداد درخواست‌ها کنار بیاید.اینجا مقاله Semerikov و همکاران درباره استفاده از Machine Learning برای Autoscaling در Microservices Architecture اهمیت پیدا می‌کند. این پژوهش به خوبی نشان می‌دهد که ML می‌تواند برای پیش‌بینی بار و تصمیم‌گیری درباره Scaling سرویس‌ها مورد استفاده قرار گیرد و در کنار الگوهایی مانند API Gateway، Circuit Breaker، SAGA و CQRS قرار بگیرد.بنابراین Scaling در معماری پیشنهادی صرفاً یک ویژگی زیرساختی نیست؛ بلکه می‌تواند بخشی از رفتار هوشمند سیستم نیز باشد.از اینجا به معماری پیشنهادی رسیدمبا کنار هم قرار دادن این خطوط پژوهشی، به یک نتیجه رسیدم:یک Reference Architecture برای سیستم‌های LLM/ML باید حداقل پنج مسئله را هم‌زمان پوشش دهد: تعامل با کاربر و سیستم‌های خارجی، Orchestration و مدیریت Workflow، مدیریت LLM و فرآیند Inference، مدیریت داده و دانش، Governance، Security، Monitoring و کنترل چرخه عمر. و بر همین اساس، معماری پیشنهادی به صورت یک معماری لایه‌ای و ماژولار طراحی شده است.معماری مرجع پیشنهادیشکل 1 ـ معماری مرجع پیشنهادی برای سیستم‌های ML/LLMمعماری را می‌توان در چند بخش اصلی دید.1. Presentation & Integration Layerاین لایه نقطه ورود کاربران و سیستم‌های خارجی است. رابط‌های وب، Chatbotها، API Gateway و Connectorها در این بخش قرار می‌گیرند و وجود این لایه باعث می‌شود LLM مستقیماً به Interface یا Client وابسته نباشد و بتواند از طریق APIهای استاندارد با سایر اجزا هم تعامل داشته باشد.2. Application & Orchestration Layerدر این لایه منطق اصلی سیستم قرار دارد.Orchestrator وظیفه دارد مشخص کند یک درخواست باید از چه Workflowای عبور کند و چه سرویس‌ها یا Agentهایی باید درگیر شوند. در سیستم‌های Multi-Agent، این بخش می‌تواند نقش هماهنگ‌کننده Agentهای تخصصی را داشته باشد. به این ترتیب، معماری از یک مدل منفرد به سمت یک سیستم قابل توسعه حرکت می‌کند.3. LLM Integration Layerاین بخش قلب AI سیستم است، اما عمداً آن را به عنوان «کل سیستم» در نظر نمی‌گیریم. در این لایه می‌توان اجزایی مانند Pre-processing، Prompt Processing، Model Inference، Model/Agent Selection، Post-processing و Output Filtering را قرار داد. همچنین این لایه باید امکان استفاده از مدل‌های مختلف را فراهم کند؛ یعنی معماری نباید به یک Provider یا یک مدل خاص وابسته باشد.4. Knowledge & Data Layerیکی از مهم‌ترین بخش‌های معماری همین لایه است.LLM به تنهایی نمی‌تواند دانش اختصاصی یک سازمان را در خود نگه دارد. بنابراین سیستم باید بتواند به منابعی مانند Document Repository، Enterprise Knowledge Base، Architecture Repository، Structured Databases، Vector Database و Interaction Memory متصل شود و در این مرحله RAG نیز می‌تواند نقش مهمی ایفا کند. کاربر سؤال می‌پرسد، سیستم اطلاعات مرتبط را از منابع معتبر بازیابی می‌کند و سپس این اطلاعات به عنوان Context در اختیار مدل قرار می‌گیرد. این کار وابستگی سیستم به دانش داخلی و ثابت مدل را کاهش می‌دهد و امکان استفاده از دانش به‌روز و تخصصی را فراهم می‌کند.5. Governance, Security & Monitoringاین بخش عمداً به صورت یک Concern عرضی در نظر گرفته شده است.امنیت، Privacy، Compliance، Fairness، Guardrails و Monitoring نباید فقط در یک مرحله از سیستم قرار بگیرند. برای مثال، Monitoring باید بتواند Latency، Error Rate، Resource Usage و رفتار سیستم را بررسی کند. Guardrails نیز می‌توانند سیاست‌های امنیتی و محتوایی را اعمال کنند و از ورود Promptهای مخرب یا خروجی‌های نامناسب جلوگیری کنند. از طرف دیگر، Human-in-the-loop در تصمیم‌های حساس اهمیت دارد. به‌خصوص در سیستم‌هایی که خروجی LLM می‌تواند مستقیماً روی یک تصمیم سازمانی اثر بگذارد، نباید خروجی مدل را معادل حقیقت در نظر گرفت.MLOps و Model Lifecycleیک جزء مهم دیگر که نباید در معماری نادیده گرفته شود، چرخه عمر مدل است.مدل همه مراحل زیر را در بر دارد:Train → Validate → Register → Deploy → Monitor → Evaluate → Updateشکل 2 ـ چرخه عمر مدل و عملیات MLOps در معماری پیشنهادیدر این چرخه، Model Registry، Versioning، CI/CD، Evaluation و Monitoring بسیار اهمیت پیدا می‌کنند.این بخش یکی از تفاوت‌های مهم سیستم‌های ML/LLM با بسیاری از نرم‌افزارهای سنتی است؛ زیرا Artifact اصلی سیستم فقط Source Code نیست. Dataset، Model، Prompt، Configuration و حتی نسخه‌های Knowledge Base می‌توانند بر رفتار سیستم اثر بگذارند. بنابراین Versioning نباید فقط به کد محدود شود.تصمیم‌های معماری که به این ساختار منجر شدنددر این مرحله چند تصمیم اصلی در طراحی معماری گرفته شد.اولین تصمیم، استفاده از یک ساختار Layered و Modular بود. دلیل این انتخاب این بود که مسئولیت‌های مختلف از یکدیگر جدا شوند و تغییر یک بخش، کمترین اثر ممکن را روی بخش‌های دیگر داشته باشد.تصمیم دوم، جدا کردن Application & Orchestration از LLM Integration بود. دلیل آن این است که منطق اصلی سیستم نباید به یک مدل یا Provider خاص وابسته شود. اگر مدل تغییر کند، نباید مجبور باشیم Business Logic سیستم را نیز تغییر دهیم.تصمیم سوم، جدا کردن Knowledge & Data از LLM بود. این تصمیم از این ایده می‌آید که دانش سیستم نباید الزاماً داخل مدل قرار داشته باشد. با این جداسازی می‌توان Knowledge Base را تغییر داد یا به‌روزرسانی کرد، بدون اینکه الزاماً مدل اصلی تغییر کند.تصمیم چهارم، قرار دادن Governance، Security و Monitoring به صورت Cross-cutting Concern بود. این تصمیم به این دلیل گرفته شد که این مسائل فقط مربوط به یک لایه خاص نیستند و باید در بخش‌های مختلف سیستم قابل اعمال باشند.تصمیم پنجم، جدا کردن Model Lifecycle از Runtime Processing بود. مدل بعد از Deploy شدن تمام نمی‌شود و باید Version، Monitor، Evaluate و در صورت نیاز Update شود. بنابراین MLOps باید به عنوان بخشی از چرخه عمر معماری در نظر گرفته شود.این تصمیم‌ها در کنار هم ساختار معماری پیشنهادی را شکل می‌دهند.جریان اجرای یک درخواست در معماری پیشنهادیتا اینجا معماری مشخص می‌کند چه اجزایی در سیستم وجود دارند. اما برای اینکه رفتار معماری واضح‌تر شود، می‌توان یک درخواست نمونه را نیز دنبال کرد.شکل 3 ـ جریان اجرای یک درخواست در معماری پیشنهادیفرض کنیم کاربر یک سؤال را از طریق Web یا Chatbot ارسال می‌کند. ابتدا درخواست وارد API Gateway می‌شود و Authentication و Validation اولیه انجام می‌شود. سپس درخواست به Application & Orchestration Layer می‌رسد. Orchestrator تصمیم می‌گیرد درخواست به چه Workflowای نیاز دارد. اگر سؤال نیازمند اطلاعات اختصاصی باشد، سیستم از Knowledge Layer اطلاعات مرتبط را بازیابی می‌کند. اطلاعات بازیابی‌شده به همراه درخواست کاربر در اختیار LLM قرار می‌گیرد. مدل پاسخ اولیه را تولید می‌کند و خروجی می‌تواند قبل از بازگشت به کاربر از Guardrails یا Output Filtering عبور کند. در موارد حساس، Human-in-the-loop نیز می‌تواند وارد این فرآیند شود.در تمام این مراحل، اطلاعاتی مانند Latency، Error Rate و Resource Usage می‌توانند برای Monitoring ثبت شوند. این جریان نشان می‌دهد که LLM تنها یکی از اجزای فرآیند است و نتیجه نهایی حاصل تعامل چندین جزء معماری است.Quality Attributes و Trade-offهایکی از دلایل اصلی طراحی این معماری، توجه هم‌زمان به چند Quality Attribute بوده است.برای مثال، جداسازی لایه‌ها می‌تواند Modifiability را افزایش دهد، اما تعداد Interfaceها و اجزای سیستم را بیشتر می‌کند. استفاده از RAG می‌تواند دسترسی به دانش تخصصی را بهتر کند، اما Retrieval نیز به سیستم اضافه شده و می‌تواند Latency و Complexity را افزایش دهد. Multi-Agent Architecture می‌تواند امکان تخصصی‌سازی وظایف را فراهم کند، اما Coordination Overhead ایجاد می‌کند. Human-in-the-loop می‌تواند کنترل و Safety را افزایش دهد، اما در مقابل زمان پاسخ را بیشتر می‌کند.بنابراین معماری پیشنهادی قرار نیست همه Quality Attributeها را به صورت هم‌زمان و بدون هزینه به حداکثر برساند. هدف، فراهم کردن ساختاری است که این Trade-offها در آن قابل مشاهده و مدیریت باشند.جدول 2 ـ ماتریس Trade-offهای معماریارتباط معماری با Quality Attributesمعماری پیشنهادی برای پشتیبانی از چند Quality Attribute اصلی طراحی شده است.شکل 3 ـ ارتباط اجزای معماری با Quality Attributesبرای مثال، جداسازی لایه‌ها و Provider Abstraction از Modifiability پشتیبانی می‌کنند. Knowledge Layer و RAG از دسترسی به دانش تخصصی و به‌روز حمایت می‌کنند. Monitoring و Fallback Mechanisms می‌توانند به Reliability کمک کنند و Autoscaling از Scalability پشتیبانی می‌کند.در مقابل، همان‌طور که در بخش Trade-offها گفته شد، هر مکانیزم معماری هزینه‌ای نیز دارد. بنابراین انتخاب هر جزء باید بر اساس Context و Requirements سیستم واقعی انجام شود.Traceability میان Requirements و Architectureبرای اینکه معماری پیشنهادی فقط مجموعه‌ای از اجزای انتخاب‌شده به صورت شهودی نباشد، ارتباط میان نیازمندی‌ها، اجزای معماری و Quality Attributes نیز در نظر گرفته شد.جدول 3 ـ Architecture Traceability Matrixاین جدول نشان می‌دهد که اجزای مختلف معماری مستقیماً با نیازمندی‌های استخراج‌شده مرتبط هستند و هر جزء حداقل یک مسئله مشخص در طراحی سیستم را پاسخ می‌دهد.چرا معماری مرجع؟منظور از Reference Architecture این نیست که این ساختار تنها معماری صحیح برای تمام سیستم‌های LLM است. و برعکس، معماری باید متناسب با Context، Requirements، Constraints و Quality Attributes هر سیستم تنظیم شود. هدف از بیان Reference Architecture این است که یک نقطه شروع مشترک ایجاد کند. که یعنی هنگام طراحی یک سیستم جدید بتوان پرسید: آیا داده و دانش سیستم مشخص شده است؟ مدل چگونه Integration می‌شود؟ Workflowها چگونه Orchestrate می‌شوند؟ مدل و Prompt چگونه Version می‌شوند؟ Monitoring کجاست؟ Security و Governance چگونه اعمال می‌شوند؟ و در نهایت، سیستم چگونه در برابر افزایش بار Scale می‌شود؟به این ترتیب، Reference Architecture بیشتر از اینکه یک نسخه آماده برای پیاده‌سازی باشد، یک ابزار برای فکر کردن درباره معماری است.نکته‌ای که برای من از این مرور مهم‌تر بوددر ابتدا ممکن است تصور کنیم چالش اصلی در ساخت یک سیستم LLM انتخاب مدل مناسب است. اما وقتی مطالعات مختلف را کنار هم قرار می‌دهیم، تصویر متفاوتی شکل می‌گیرد. مسئله اصلی فقط Model نیست. مسئله، سیستمی است که Model را در خود جای می‌دهد. داده، دانش، مدل، Workflow، API، زیرساخت، Monitoring، Security، Governance و انسان همگی بخشی از همان سیستم هستند. به همین دلیل، به نظر می‌رسد آینده سیستم‌های LLM نه صرفاً در «مدل‌های بزرگ‌تر»، بلکه در معماری‌هایی است که بتوانند این اجزا را به شکل قابل اعتماد، مقیاس‌پذیر و قابل کنترل کنار هم قرار دهند.محدودیت‌ها و مسیر ادامه کاراین معماری یک Reference Architecture پیشنهادی است و نه یک استاندارد نهایی.در این مرحله تمرکز اصلی پژوهش بر مرور منابع، استخراج دغدغه‌های معماری و سنتز یک معماری مرجع بوده است و هنوز یک Prototype کامل برای اندازه‌گیری Runtime اجرا نشده است. مرحله بعدی برای اعتبارسنجی آن می‌تواند شامل پیاده‌سازی یک Prototype، مقایسه معماری‌های مختلف و ارزیابی ویژگی‌هایی مانند Scalability، Latency، Reliability، Resource Efficiency، Explainability و Security باشد. همچنین می‌توان معماری را در یک Case Study واقعی پیاده‌سازی کرد و با استفاده از معیارهای کمی، تأثیر انتخاب Patternهای معماری را ارزیابی کرد.این موضوع با پژوهش‌هایی که اخیراً چارچوب‌های کمی برای ارزیابی معماری سیستم‌های ML ارائه کرده‌اند نیز هم‌راستا است؛ برای مثال معیارهایی مانند Number of Requests at Max Throughput، Horizontal Scaling Index و Scalability Coefficient می‌توانند در ارزیابی‌های آینده مورد استفاده قرار بگیرند.جمع‌بندیمسیر این مطالعه برای من از یک سؤال ساده شروع شد:اگر LLM قرار است بخشی از یک سیستم نرم‌افزاری واقعی باشد، معماری آن سیستم چگونه باید طراحی شود؟مرور پژوهش‌ها نشان داد که هنوز یک پاسخ واحد و تثبیت‌شده برای این سؤال وجود ندارد.پژوهش‌های معماری ML بر نقش داده، مدل، Stakeholderهای جدید و MLOps تأکید می‌کنند. مطالعات LLM، مسئله Integration، Knowledge، Modularity و تعامل با مدل‌ها را پررنگ می‌کنند. معماری‌های Multi-Agent مسئله Orchestration و تخصصی‌سازی Agentها را مطرح می‌کنند و مطالعات صنعتی نیز نشان می‌دهند که معماری همواره با Trade-off میان ویژگی‌های کیفی مختلف همراه است.بر اساس همین نقاط مشترک، معماری مرجع پیشنهادی تلاش می‌کند یک تصویر یکپارچه از این اجزا ارائه دهد؛ تصویری که در آن LLM دیگر یک «جعبه سیاه در مرکز سیستم» نیست، بلکه یکی از اجزای یک معماری بزرگ‌تر، قابل مدیریت و قابل تکامل است.و شاید مهم‌ترین نتیجه همین باشد:برای ساخت یک سیستم هوشمند قابل اتکا، فقط هوشمند بودن مدل کافی نیست؛ خودِ سیستم نیز باید معماری مناسبی داشته باشد.و در آخر نیاز است بیان شود «اين مطلب، بخشي از تمرينهاي درس معماري نرم‌افزار در دانشگاه شهيدبهشتي است»منابع[1] Bialek, L., Groenboom, R., & Andrikopoulos, V. (2026). Software architecture for machine learning to aid sustainable digital transformation: A systematic mapping study. Information and Software Technology, 190, 107931. DOI: 10.1016/j.infsof.2025.107931.[2] Muccini, H., & Vaidhyanathan, K. (2021). Software Architecture for ML-based Systems: What Exists and What Lies Ahead. Proceedings of the IEEE/ACM Workshop on AI Engineering – Software Engineering for AI (WAIN@ICSE 2021), 121–128. DOI: 10.1109/WAIN52551.2021.00026.[3] Schmid, L., Hey, T., Armbruster, M., Corallo, S., Fuchß, D., Keim, J., Liu, H., & Koziolek, A. (2025). Software Architecture Meets LLMs: A Systematic Literature Review. arXiv:2505.16697.[4] Becattini, M., Verdecchia, R., & Vicario, E. (2025). SALLMA: A Software Architecture for LLM-Based Multi-Agent Systems. IEEE/ACM International Workshop on New Trends in Software Architecture (SATrends@ICSE 2025). DOI: 10.1109/SATRENDS66715.2025.00006.[5] Semerikov, S. O., Zubov, D., Kupin, A., Kosei, M., & Holiver, V. (2024). Models and Technologies for Autoscaling Based on Machine Learning for Microservices Architecture. Proceedings of the 8th International Conference on Computational Linguistics and Intelligent Systems (COLINS 2024), 316–330.[6] Indykov, V., Wohlrab, R., & Strüber, D. (2025). Quality trade-offs in ML-enabled systems: a multiple-case study. Proceedings of the 40th ACM/SIGAPP Symposium on Applied Computing (SAC 2025), 1730–1737. DOI: 10.1145/3672608.3707754.[7] Emanuilov, S., & Dimov, A. (2025). A quantitative framework for evaluating architectural patterns in ML systems. arXiv:2501.11543.[8] Najafabadi, F. A. (2024). Reference Architecture of MLOps Workflows. In A. Ampatzoglou et al. (Eds.), Software Architecture. ECSA 2024 Tracks and Workshops, Lecture Notes in Computer Science, vol. 14937, pp. 49–57. Springer. DOI: 10.1007/978-3-031-71246-3_6.[9] Bucaioni, A., Weyssow, M., He, J., Lyu, Y., & Lo, D. (2025). A Functional Software Reference Architecture for LLM-Integrated Systems. Proceedings of the 22nd IEEE International Conference on Software Architecture (ICSA 2025), pp. 1–5. DOI: 10.1109/ICSA-C65153.2025.00006.Rana GhozatRana GhozatMon, 10 Aug 2026 23:27:33 +0330https://virgool.ir/@m_10634336/مهندسی-نرم-افزار-و-هوش-مصنوعی-در-کنارهم-yloazowkvtkqاین روزها همه‌جا صحبت از هوش‌مصنوعی است. برخی می‌گویند هوش‌مصنوعی جای برنامه‌نویسان را می‌گیرد. برخی دیگر می‌گویند نه. آنچه مسلم است ارتباط هوش‌مصنوعی و مهندسی نرم‌افزار است که به صورت یک رابطه دوطرفه باید لحاظ شود. از یک سو، هوش‌مصنوعی به مهندسان نرم‌افزار کمک می‌کند تا کدنویسی و تست سریع‌تر انجام شود. از سوی دیگر، خود سیستم‌های هوش‌مصنوعی به اصول مهندسی نرم‌افزار نیاز دارند تا قابل اطمینان و مقیاس‌پذیر باشند. در ادامه سه مفهوم کلیدی در این حوزه را بررسی می‌کنیم:AI4SEاستفاده از هوش‌مصنوعی برای کمک به کارهای مهندسی نرم‌افزار. مثلا نوشتن کد، پیدا کردن باگ یا تولید تستبرای مثال فرض کنید قصد دارید تابعی ساده بنویسید، در حالت عادی باید منطق آن را خط به خط بنویسید ولی با AI4SE کافی است منطق کد را توضیح دهید ( برای مثال تابعی که سن را از تاریخ تولد  محاسبه کند) و هوش‌مصنوعی خودش کد را تولید می‌کند. این کد همواره بی‌نقص نیست، اما زمان توسعه را به شدت کاهش می‌دهد. جدا از کدنویسی AI می‌تواند در بازبینی کد هم کمک کند. برای مثال بروز خطا در بخشی از کد را پیش‌بینی کند یا بهینه‌تر شدن بخشی از کد را پیشنهاد دهد. برای تست های نرم‌افزاری هم می‌توان از هوش‌مصنوعی بهره برد. AI می‌تواند سناریوهای مختلف را حدس بزند و تست بنویسد. استفاده از AI به عنوان دستیار برای توسعه دهنده می‌تواند بسیار مفید باشد.SE4AIاین مفهوم دقیقا برعکس مفهوم قبلی است و یعنی استفاده از اصول مهندسی نرم‌افزار برای ساختن سیستم‌های هوش مصنوعی.فرض کنیم یک مدل ساخته‌ایم که کارش تشخیص ایمیل اسپم است. مدل ما با دقت 98% کار میکند. حال میخواهیم این مدل را در یک سرویس ایمیل واقعی به کار گیریم. چه چالش هایی داریم؟ مدل باید در کثری از ثانیه پاسخ دهد و داده هایی که مدل با آنها روزانه مواجه خواهد شد متفاوت از داده‌هایی است که در زمان آموزش دیده است. و چالش بعدی و مهم تر از همه زمانی است که مدل اشتباه کند( ایمیل مهمی را اسپم تشخیص دهد) در این مواقع مهندسی نرم‌افزار وارد می‌شود.SE4AI به مسائلی مثل تست‌پذیری مدل، استقرار مداوم و پایش عملکرد آن در محیط واقعی می‌پردازد.MLOpsاگر DevOps که در پست های قبلی به آن اشاره کردیم را برای یک نرم‌افزار معمولی در نظر بگیرید، MLOps همان مفهوم را برای سیستم‌های یادگیری ماشین تداعی می‌کند. اما در اینجا یک تفاوت مطرح است: در نرم‌افزار معمولی فقط کد تغییر می‌کند، در یادگیری ماشین هم کد هم داده و هم مدل تغییر می‌کنند.مفهوم MLOps از جمع‌آوری داده شروع شده و سپس پاک‌سازی و آماده سازی داده و بعد هم آموزش مدل و ارزیابی آن و در نهایت استقرار آن در محیط تولید را شامل می‌شود. البته کار ادامه خواهد داشت! باید بعد از استقرار هم مدل پایش شود. دقت مدل نباید پایین بیاید و همچنین باید بررسی شود داده های جدید با فرضیات MLOps قبلی همخوانی داشته باشد. اگر مدل افت کرد باید دوباره آموزش داده شود. این کار ها با MLOps خودکار و قابل تکرار طراحی شده و ابزارهایی مانند MLflow و Kubeflow برای همین کاربرد استفاده می‌شوند.این سه مفهوم به سادگی توضیح می‌دهد که هوش‌مصنوعی و مهندسی نرم‌افزار از هم جدا نیستند.منابع: MLflow DocsKubeflow DocsGoogle (Hidden Technical Debt) Rana GhozatRana GhozatMon, 01 Jun 2026 20:24:01 +0330https://virgool.ir/@m_10634336/chaos-engineering-آشوب-کنترل-شده-برای-تاب-آوری-بیشتر-h2lqgnqgqlnlWhat is Chaos Engineering? Benefits and Implementation Strategies - BuildPiperزمانی که یک سرویس آنلاین ناگهان از دسترس خارج می‌شود یا برنامه ای هنگام ثبت سفارش هنگ می‌کند. معمولا تیم فنی این موقعیت ها را "شرایط غیرمنتظره" لحاظ می‌کنند. اما در سیستم‌های مدرن، تعداد حالت‌های خرابی آنقدر زیاد است که هیچ تست سنتی ای نمی‌تواند همه آن ها را پیش از وقوع پیش‌بینی و شبیه‌سازی کند.اینجاست که Chaos Engineering یا مهندسی آشوب به عنوان روشی برای تست تاب‌آوری سیستم در برابر خرابی‌های غیرمنتظره مطرح می‌شود.در تست های سنتی از قبل می‌دانیم چه خطایی می‌خواهد شبیه‌سازی شود. مثلا اگر دیتابیس پاسخ ندهد چه میشود؟ اما در دنیای واقعی خرابی ها به شکل های عجیب و غیرقابل پیش‌بینی ظاهر می‌شوند. شبکه ناگهان کند شده یا سرور بدون هشدار از کار می‌افتد. Chaos Engineering می‌گوید به جای پیش‌بینی همه حالت ها، خرابی را عمدا به وجود بیاور و ببین سیستم چطور رفتار می‌کند.برای مثال شرکت نتفلیکس یک ابزار به نام Chaos Monkey ساخته که این ابزار به طور تصادفی سرویس‌های داخلی را خاموش می‌کند. هدفش این است ببین آیا سیستم بدون دخالت انسان می‌تواند خودش را بازیابی کند یا خیر. اگر با خاموشی یک سیستم کل سیستم از کار بیفتد این نقص معماری است و باید برطرف شود.فرآیند مهندسی آشوب چهار مرحله دارد:مرحله اول: فرضیهفرض می‌کنیم اگر یک سرویس از کار بیفتد، سیستم همچنان ادامه می‌دهد.مرحله دوم: تزریق خطابه صورت کنترل شده و با تاثیر محدود خطا ایجاد می‌کنیممرحله سوم: مشاهدهرفتار سیستم را می‌بینیم. آیا واقعا تاب آورد؟مرحله چهارم: بهبوداگر سیستم تاب نیاورد و مشکل داشت، نقص را پیدا کرده و رفع می‌کنیم. مهندسی آشوب در سیستم‌هایی که اکثر حالت های خرابی آن را از قبل می‌شناسیم کارایی کمی دارد. همچنین اگر در سیستم‌های حساس که کاربران آن حتی برای قطعی هیچ تحملی ندارند هم این روش استفاده شود( مثل سیستم های بیمارستان یا سیستم های فضایی) باید خیلی محتاط بود.Chaos Engineering به ما یادآوری می‌کند خرابی حتمی است و به جای امیدواری که خطایی رخ ندهد بهتر است سیستم را برای روزهای بد آماده کنیم و نقاط ضعف پنهان شده در سیستم را زودتر از موعد پیدا کنیم. منابع:Chaos Mesh Docs Netflix Chaos Monkey Principles of Chaos EngineeringRana GhozatRana GhozatMon, 01 Jun 2026 19:51:11 +0330https://virgool.ir/@m_10634336/ابزارهایی-برای-غیربرنامه-نویسان-و-مدیریت-فرایند-ها-jiggssg5za2uهمه سیستمهای نرمافزاری را برنامهنویسان حرفهای نمیسازند. گاهی یک مدیر محصول، یک تحلیلگر کسب و کار، یا حتی یک کارشناس فروش ایده ای دارد که میخواهد سریع آن را پیاده کند. از آن طرف، در سازمان های بزرگ، فرایندهای پیچیده ای که وجود دارد که مدیریت آنها با کدنویسی خالص گاها دشوار میشود. دو مفهوم زیر به این نیازها پاسخ میدهد:Get the best out of low-code BPMs | Axelor·       Low-code / No-code Platformsبرای مثال فرض کنید یک مدیر بازاریابی میخواهد فرمی بسازد تا اطلاعات مشتریان را جمعآوری کند. یا یک تحلیلگر فروش نیاز به داشبوردی دارد که آمار روزانه را نشان دهد. در روش سنتی، باید درخواست به تیم فنی ارسال میشد و مدت ها انتظار صرف میشد و بعد از پیادهسازی، باز هم تغییرات کوچک....Low-code و No-code این مشکلات را حل میکند. در این سکو ها ، کاربر به جای نوشتن کد با کشیدن و رهاکردن قطعات برنامه را میسازد. تفاوت این دو در میزان انعطاف خواهد بود. No-code کاملا مناسب کاربران غیرفنی است و نیاز به هیچ کدنویسی ای در آن نیست. و Low-code برای توسعه دهنگان مناسب است و در صورت نیاز میتوان کد سفارشی هم نوشت و اضافه کرد. ·       Business Process Management System(BPMS)همان طور که قبل تر گفتیم در سازمان های بزرگ، فرآیندهای زیادی بین بخش های مختلف جریان دارد. برای مثال فرایند "ثبت سفارش تا تحویل کالا" ممکن است شامل این مراحل باشد: تایید اعتبار مشتری، چک کردن موجودی انبار، تخصیص به انباردار، بستهبندی، ارسال و در نهایت ارسال پیامک به مشتری. هر مرحله ممکن است توسط یک نفر یا یک سرویس نرمافزاری انجام شود. اگر همه این منطق با کدنویسی خالص پیادهسازی شود پیچیدگی در حالت های مختلف کار را بسیار پیچیده میکند.BPMS مخفف Business Process Management System است. این سیستم ها با یکسری زبان استاندارد که به آن BPMN گفته میشود کار میکنند و در این زبان فرآیندها به صورت نموداری و گرافیکی مدل شده و قابل استفاده میشوند.مزیت BPMS این است که وقتی کی تسک به پایان رسید، موتور خودکار مرحله بعد را شروع میکند و اگر کل فرآیند تغییر کند (برای مثال یک مرحله به گردش کار اضافه شود) فقط کافی است نمودار عوض شود و بدون نیاز به تغییر کد و استقرار مجدد کل سیستم. این سیستم ها برای سازمانهایی که مدام درحال تغییر فرآیندهایشان هستند بسیار کاربردی و محبوب هستند.  منابع: Get the best out of low-code BPMs | AxelorPower Apps Docs OutSystems Camunda Docs BPMN 2.0 StandardRana GhozatRana GhozatMon, 01 Jun 2026 19:44:21 +0330https://virgool.ir/@m_10634336/devops-و-زیرساخت-از-کد-تا-ابر-hb8l0lzylynwحتما تا به حال برایتان پیش آمده که یک برنامه روی لپ‌تاپ خودتان درست کار کند، اما وقتی می‌خواهید آن را روی سرور اجرا کنید، با هزار خطا مواجه شوید. یا کتابخانه ای نیست، یا نسخه فرق دارد و...  یا مثلا برای راه‌اندازی یک سرویس جدید، باید ساعت‌ها پشت ترمینال بنشینید و دستورات تکراری را یکی یکی تایپ کنید. این مشکلات ریشه در یک چیز دارند: جدا بودن "توسعه" از "زیرساخت". در این نوشته به شش مفهومی می‌پردازیم که این جدایی را از بین می‌برند و اجازه می‌دهند زیرساخت هم مثل کد رفتار کند.در توسعه نرم‌افزار، نوشتن کد فقط نیمی از کار است. نیم دیگر، اجرای آن کد در جایی خارج از لپتاپ توسعه دهنده است. اینجاست که مشکلات بروز می‌کنند. برنامه در محیط توسعه کار می‌کند اما در محیط تولید از کار می‌افتد. راه‌اندازی سرور جدید روزها زمان می‌برد، و با زیادشدن کاربران سیستم پاسخ نمی‎دهد. شش مفهوم زیر هرکدام به نوعی در حل این مشکلات کمک می‌کنند:IaC Infrastructure as Code (IaC)زمانی که زیرساخت نرم‌افزاری مانند سرور، دیتابیس و شبکه به صورت دستی و با کلیک کردن در پنل‌های مختلف راه‌اندازی می‌شود، دو مشکل بزرگ ایجاد می‌گردد: اول، هیچ مستند دقیقی از تنظیمات وجود ندارد. دوم، اگر آن سرور خراب شود، راه‌اندازی مجدد آن ساعت‌ها یا روزها زمان می‌برد.IaC یعنی توصیف تمام زیرساخت به صورت فایل‌های متنی که در سیستم کنترل نسخه مانند گیت ذخیره می‌شوند. در این روش، به جای آن که کسی دستورات را یکی یکی تایپ کند، ابزاری مانند Terraform یا Ansible تنظیمات را از روی همان فایل‌ها اعمال می‌کند.اگر سروری خراب شود، کافی است همان فایل را دوباره اجرا کرد. اگر تیم بزرگ شود، همه می‌توانند ببینند زیرساخت دقیقا چگونه تنظیم شده است. این رویکرد خطای انسانی را نیز کاهش می‌دهد و راه‌اندازی مجدد زیرساخت را از چند روز به چند دقیقه می‌رساند.Docker Containers (Docker)یکی از رایج‌ترین مشکلات در دنیای نرم‌افزار، تفاوت محیط اجراست. برنامه ای که روی لپ‌تاپ توسعه دهنده درست کار می‌کند، روی سرور تولید خطا می‌دهد. دلیل این مشکل معمولا تفاوت نسخه کتابخانه‌ها، سیستم‌عامل یا تنظیمات محیطی است.Containerها این مشکل را حل می‌کنند. یک Container، برنامه و همه وابستگی‌های آن را در یک بسته قابل حمل قرار می‌دهد. این بسته روی هر ماشینی که داکر نصب باشد، دقیقا به همان شکل اجرا می‌شود. تفاوتی که با ماشین مجازی دارد این است که Container ها هسته سیستم‌عامل میزبان را به اشتراک می‌گذارند، در نتیجه بسیار سبک تر هستند و در کسری از ثانیه اجرا می‌شوند. با استفاده از داکر، دیگر بهانه "IT WORKS ON MY MACHINE" قابل قبول نیست. اگر برنامه روی لپ‌تاپ توسعه دهنده کار می‌کند، روی هر سرور دیگری هم کار خواهد کرد.KubernetesContainer Orchestration (Kubernetes)حال فرض کنیم نه فقط یکی بلکه تعداد زیادی ( برای مثال 50 تا) Container داریم. هرکدام باید روی کدام سرور برود؟ اگر یکی از آنها خراب شد چه کسی دوباره راه‌اندازی‌اش میکند؟ اگر ترافیک سایت ناگهان زیاد شد، چه کسی تعداد Containerها را زیاد می‌کند؟Kubernetes دقیقا این کار را انجام می‌دهد. به آن می‌گوییم" سه نسخه از این Container را می‌خواهیم همواره روشن باشد" خودش تصمیم می‌گیرد هر کدام کجا برود. اگر یکی خراب شد بدون اطلاع ما آن را جایگزین می‌کند. اگر ترافیک زیاد شد، تعداد را زیاد می‌کند. Kubernetes مانند یک مدیر خودکار برای Containerها عمل می‌کند. به همین دلیل به استاندارد اجرای برنامه در شرکت های بزرگ تبدیل شده است.Serverless ArchitectureServerless Architectureگاهی پیش می‌آید که قصدمان فقط نوشتن یک تابع ساده است. مثلا تابعی که هرزمان عکسی آپلود شد، اندازه آن را تغییر دهد. برای کار های ساده چرا نیاز به خرید یک سرور کامل است؟ همیشه این هزینه را پرداخت کنیم حتی وقتی هیچ عکسی آپلود نمی‌شود!معماری Serverless این پیچیدگی را از بین می‌برد. در این روش، توسعه‌دهنده فقط کد خود را به صورت صورت یک تابع می‌نویسد و آن را در اختیار ارائه‌دهنده ابر مانند AWS Lambda قرار می‌دهد. ارائه‌دهنده ابر مسئولیت اجرا، مقیاس‌پذیری، و در دسترس‌بودن را برعهده می‌گیرد. هزینه نیز فقط به ازای تعداد دفعات اجرا و مدت زمان اجرا محاسبه می‌شود. اگر تابع یک میلیون بار اجرا شود، هزینه پرداخت می‌شود اگر یک روز اصلا اجرا نشود، هزینه صفر است. نام Serverless به نظرم کمی گمراه کننده است چرا که سرور وجود دارد، فقط توسعه دهنده آن را نمی‌بیند و مدیریت نمی‌کند.Multi-Tenancy Architectureسرویس‌هایی مثل جیمیل را در نظر بگیرید. میلیاردها کاربر از یک نسخه واحد نرم‌افزار استفاده می‌کنند، اما هر کاربر فقط داده‌های خود را می‌بیند. این طراحی همان معماری Multi-Tenancy نام دارد. در این معماری، یک نمونه نرم‌افزار به چندین مشتری سرویس می‌دهد، درحالی که داده‌های آنها کاملا از یکدیگر جدا باقی می‌ماند. سه سطح اصلی برای جداسازی داده ها در پیاده‌سازی چنین سرویس هایی وجود دارد:سطح اول: یک دیتابیس جداگانه برای هر مشتری در نظر گرفته شود. این روش بالاترین امنیت را دارد اما با افزایش تعداد کاربران، تعداد دیتابیس ها بسیار زیاد شده و هزینه نگهداری بالا می‌رود.سطح دوم: اسکیماهای جداگانه در یک دیتابیس مشترک در نظر گرفته شود. این روش تعادل خوبی بین هزینه و ایزوله‌سازی ایجاد می‌کند.سطح سوم: همه مشتریان در یک اسکیما با یک فیلد شناسه مشتری. این روش بیشترین بهره‌وری از منابع را دارد اما اگر در کوئری زدن شرط فیلد شناسه فراموش شود و داده های کاربران با هم قاطی شود خطرناک است.مشخص است که انتخاب سطح مناسب در طراحی سرویس های اشتراکی اهمیت زیادی دارد.Data Migrationهنگامی که شرکتی تصمیم می‌گیرد دیتابیس خود را از سیستمی به سیستم دیگر منتقل کند، یا معماری برنامه را از یک حالت یکپارچه به میکروسرویس تغییر دهد، ناگزیر است داده های قبلی را به یک سیستم جدید انتقال دهد. به این فرایند مهاجرت داده گویند.این کار به آن سادگی که به نظر می‌رسد نیست! چالش هایی در این مسیر وجود دارد. برای مثال تفاوت در فرمت داده ها ( برای مثال داده های تاریخی ممکن است در سیستم های مختلف با فرمت های مختلفی ثبت شده باشند.) همچنین در زمان انتقال ممکن است سایت چند دقیقه از کار بیفتد.در مهاجرت داده هدف این است که در این تغییر( دیتابیس یا معماری) داده های قبلی نباید از بین برود.منابع :Terraform Docs Docker Docs Kubernetes Docs AWS Lambda DocsRana GhozatRana GhozatMon, 01 Jun 2026 19:08:08 +0330https://virgool.ir/@m_10634336/4-مفهوم-معماری-نرم-افزار-برای-درک-بهتر-سیستم-های-مدرن-cgtktipq4slaحتما برای همه ما پیش آمده که در یک فروشگاه اینترنتی سفارشی را ثبت کنیم و بعد از چند ثانیه ایمیلی به ما ارسال شود، بعد از چند دقیقه پیامکی دریافت کنیم و بعد از مدتی موجودی انبار اون کالا کم شود. چطور این اتفاق ها بدون اختلالی انجام می‌شود؟EDAEvent-Driven Architectureیکی از پاسخ‌ها استفاده از معماری رویداد محور است. در این معماری به جای اینکه سرویس سفارش خودش، انبار، ایمیل و بخش مالی پروژه را صدا بزند( که اگر یکی از این سرویس‌ها خراب باشد یا کند کار کند، کل فرایند می‌ایستد!)  فقط اعلام می‌کند که: "سفارش جدید ثبت شد" و باقی سرویس ها به این خبر گوش می‌دهند و هرکدام وظیفه خودشان را انجام می‌دهند . درواقع در این مدل وقتی هر سرویس کاری را انجام می‌دهد یک " رویداد " منتشر می‌کند. در همچین سیستمی اگر برای مثال سرویس ایمیل موقتا کار نکند، وقتی دوباره بالا آمد و آماده کار بود همان رویداد را می‌بیند و ایمیل را ارسال می‌کند. در این روش وابستگی میان سرویس ها کم است و سیستم مقایس‌پذیرتر و در برابر خرابی مقاوم‌تر می‌شود. نتفلیکس و اوبر از جمله شرکت‌هایی هستند که به شکل گسترده از این معماری استفاده می‌کنند.CQRS CQRS (Command Query Responsibility Segregation)حال سوال این است: چطور اطلاعات را طوری مدیریت کنیم که هم نوشتن آنها سریع باشد هم خواندن گزارشات سنگین سیستم را کند نکند؟CQRS یعنی یک مدل برای نوشتن(Command) داشته باشیم و یک مدل جدا برای خواندن(Query). در سیستم‌هایی که از یک دیتابیس یکسان برای هم خواندن هم نوشتن استفاده می‌شود گاها ممکن است این دو عملیات رفتار متفاوتی داشته باشند. برای مثال نوشتن نیاز به اعتبارسنجی دارد و خواندن نیازمند سرعت بالا است. اگر هردو یک جا باشد چه طور این دو هدف با هم محقق شوند؟در CQRS با جداسازی این دو عملیات، این دو هدف همزمان امکان پذیر می‌شود. برای مثال در یک سیستم بانکی عملیات انتقال پول از یک دیتابیس باید سختگیرانه باشد و نمایش موجودی و تراکنش های اخیر از یک دیتابیس دیگر که مخصوص خواندن سریع ساخته شده راحت.این روش در سیستم هایی که تعداد Query در آنها خیلی بیشتر از Command است یا در سیستم هایی که منطق نوشتن باید پیچیده طراحی شود یا زمانی که تیم های جداگانه روی Command و Query کار می‌کنند بسیار مفید است.Event Scourcing Event Sourcingحال سوال مهم‌تر: اگر یک باگ باعث شود موجودی حساب اشتباه محاسبه شود، چطور بفهمیم اشتباه از کجا شروع شده؟ یا اگر یک مشتری ادعا کند که تراکنشی انجام نشده، چطور می‌توانیم دقیقا نشان دهیم چه اتفاقی افتاده است؟Event Sourcing پاسخ این مشکلات است و یعنی به جای ذخیره وضعیت فعلی، همه اتفاقاتی که منجر به وضعیت فعلی است را ذخیره کنیم! در این حالت می‌توانیم هر لحظه تاریخچه کامل و قابلیت امکان برگشت به هرلحظه قبلی را داشته باشیم. این قابلیت در سیستم های بانکی، مالی، سبد خرید و زنجیره تامین بسیار ارزشمند است و البته معایبی هم دارد! وقتی از Event Sourcing استفاده کنیم خطاهای منطقی راحت‌تر پیدا شده ولی حجم داده خیلی زیاد میشود و پیچیدگی هم بیشتر.Message Queue Message Queueرویداد ها چطور از یک سرویس به یک سرویس دیگر میرسند؟ Message Queue مانند یک صندوق پستی عمل می‌کند و نقش یک واسط مطمئن را میان تولید کننده و مصرف کننده پیام دارد. وقتی Message Queue داریم فرستنده پیامش را در صف می‌گذارد و بدون اینکه منتظر بماند به کار خود ادامه می‌دهد. گیرنده نیز هر موقع که آماده بود و توانایی پردازش داشت پیام را از صف برمی‌دارد و پردازش می‌کند. به این نحو تولید کننده و مصرف‌کننده مستقل از هم کار می‌کنند و اگر یکی از آنها خراب شود کار دیگری مختل نمی‌شود.از نمونه ابزار های محبوب که برای Message Queue استفاده می‌شود می‌توانیم به RabbitMQ و Kafka اشاره کنیم. که تفاوت‌هایی نیز با هم دارند. برای مثال RabbitMQ یک صف پیام سنتی است یعنی بعد از خواندن پیام، پیام از صف پاک می‌شود. این ویژگی برای کارهایی که نیاز به فقط یک بار پردازش دارند مناسب است ولی در Kafka ماجرا متفاوت است. پیام ها بعد از خوانده شدن از صف پاک نمی‌شوند و برای مدت معینی نگهداری می‌شوند. مصرف‌کننده می‌تواند هر بار از یک نقطه مشخص پیام‌ها را دوباره بخواند. این ویژگی برای سناریوهایی که نیاز به تاریخچه کامل رویداد داریم (Event Sourcing) عالی است. این تفاوت در این دو نوعMessage Queue در کاربردهای مختلفی حتی ممکن است در کنار هم استفاده شوند. مثلا در یک سیستم ثبت سفارش، وقتی ثبت سفارش انجام می‌شود پیام به یک صف مثل Kafka می‌رود که برای تحلیل های بعدی مثل ارسال به انبار، ارسال ایمیل و ... آماده باشد ولی اگر یک سرویس بخواهد فوری کاری را انجام دهد و جوابی بدهد مثل اعتبارسنجی کارت بانکی میتواند از RabbitMQ استفاده کند. منابع:Kafka Docs RabbitMQ DocsFowler (Event Sourcing, CQRS)Rana GhozatRana GhozatMon, 01 Jun 2026 18:02:33 +0330https://virgool.ir/@m_10634336/وقتی-سیستم-ها-بزرگ-و-پیچیده-می-شوند-byaywvakasknمعماری مدرن و طراحی سیستم:توسعه سیستم‌های نرم‌افزاری همه از یک اپلیکیشن، چند API و یک دیتابیس ساده شروع می‌شود، با گذشت زمان، سیستم رشد می‌کند، کاربران بیشتر می‌شوند و قابلیت های جدید اضافه می‌شود و همینطور کم کم همه چیز پیچیده تر از قبل می‌شود. در این مرحله سیستم دیگر قابل مدیریت نیست. زمانی که تیم‌های مختلف هم‌زمان روی بخش های مختلف کار می‌کنند، سرویس ها زیاد شده و ارتباط میان آن ها به پیچیدگی می‌افزاید. اینجاست که هر تغییر کوچک می‌تواند روی بخش های دیگر اثر بگذارد.در چنین شرایطی فقط نوشتن کد مطرح نیست، بلکه مسئله اصلی "مدیریت پیچیدگی" است. به همین دلیل در معماری نرم‌افزار، مفاهیم مختلفی شکل گرفته که هر یک تلاش می‌کند به نحوی این پیچیدگی را کنترل کند.در ادامه چند مفهوم مهم در معماری نرم‌افزار را بررسی می‌کنیم که هرکدام پاسخی به یکی از این مشکلات در سیستم‌های بزرگ هستند.·       Backend for Frontend (BFF):در سیستم های مدرن کاربران از طریق پلتفرم‌های مختلفی مثل وب‌سایت، اپلیکیشن موبایل یا پنل مدیریت به سیستم متصل می‌شوند و به عبارتی می‌توان گفت: همه کاربران مثل هم نیستند و هر کدام از این Frontendها نیازهای متفاوتی دارند. اگر همه آن‌ها مستقیما از یک Backend مشترک استفاده کنند به مرور سیستم پیچیده شده و مدیریت آن دشوار و دشوارتر. به همین دلیل مفهومی مثل Backend for Frontend یا به اختصار BFF مطرح می‌شود.برای مثال در یک فروشگاه اینترنتی، اپلیکیشن موبایل به داده کمتر ولی پاسخ سریع‌تر نیاز دارد ولی در نسخه وب ممکن است اطلاعات کامل‌تر و جزئیات بیشتری نمایش داده‌شود، اگر هردو از یک Backend استفاده کنند احتمالا داده های اضافی و غیرضروری دریافت می‌شود.در این روش برای هر Frontend یک Backend اختصاصی طراحی می‌شود تا متناسب با نیاز همان بخش عمل کند. این کار باعث می‌شود هر پلتفرم دقیقا چیزی را دریافت کند که نیاز دارد، نه بیشتر و نه کمتر·       API Gateway & Service Mesh:زمانی که سیستم بزرگ می‌شود و به چندین Microservice تقسیم می‌شود، یک چالش جدید ظاهر می‌شود: مدیریت ارتباط میان سرویس‌ها. زمانی که سرویس زیادی وجود دارد مثل سرویس کاربران، سفارش، پرداخت و ارسال. اگر هر Frontend بخواهد مستقیم با این سرویس‌ها ارتباط بگیرد هم امنیت دچار چالش شده هم مدیریت درخواست ها پیچیده می‌شود.در چنین سیستم‌هاییAPI Gateway نقش یک درگاه مرکزی را خواهد داشت و تمام درخواست کاربران ابتدا به آن وارد شده و سپس Gateway تصمیم می‌گیرد هر درخواست باید به کدام سرویس ارسال شود.فرض کنید در یک فروشگاه اینترنتی زمانی که کاربر وارد صفحه سفارش شده، اطلاعاتی از جمله اطلاعات کاربر، لیست کالاها، وضعیت موجودی، قیمت و تخفیف باید جمع آوری شوند. بدون API Gateway اپلیکیشن موبایل باید جداگانه با چندین سرویس مختلف درخواست ارسال کند اما با یک API Gateway فقط یک درخواست ارسال شده و API Gateway  خودش با سرویس های مختلف در ارتباط است و نتیجه نهایی را برمی‌گرداند.Kong ، NGINX ، Spring Cloud Gateway نمونه ابزار های معروف برای API Gateway هستند که استفاده از این ابزار ها باعث می‌شود مدیریت درخواست ها، امنیت و کنترل سرویس ها ساده‌تر انجام شود.Service Mesh اما بیشتر برای مدیریت ارتباطات داخلی بین سرویس ها استفاده می‌شود. برای مثال اگر یکی از سرویس ها موقتا کار نکند Service Mesh می‌تواند درخواست را دوباره ارسال کند و یا درخواست را به نسخه سالم سرویس هدایت کند. یعنی به جای اینکه هر سرویس خودش کنترل ترافیک، امنیت، مانیتورینگ و... را پیاده‌سازی کند Service Mesh این کار را انجام می‌دهد. Istio و Linkerd دو نمونه ابزاری هستند که برای کنترل ارتباط داخلی میان سرویس ها می‌توان از آنها استفاده کرد. ·       API-first Approachزمانی که در پروژه های نرم‌افزاری به ویژه در پروژه های بزرگ ، تیم ها قبل از طراحی API ها شروع به پیاده سازی سیستم می‌کنند پروژه با مشکلاتی همچون ناهماهنگی تیم‌ها و تغییرات زیاد در API ها و دوباره کاری مواجه می‌شود.در رویکرد API-first قبل از پیاده‌سازی بخش های مختلف سیستم، ابتدا API ها طراحی می‌شود. توسعه دهندگان از همان ابتدای کار Endpoint ها را تعیین می‌کنند، ورودی و خروجی‌ها و اینکه داده ها با چه ساختاری بین بخش‌های مختلف رد و بدل می‌شوند را مشخص می‌کنند. برای مثال اگر در توسعه یک اپلیکیشن سفارش غذا ابتدا API‌های مربوط به ثبت سفارش، لیست رستوران ها یا پرداخت را طراحی شوند، تیم‌های Backend و Frontend می‌توانند به صورت هم‌زمان توسعه را آغاز کنند، که باعث هماهنگی بهتر بین تیم ها شده و تغییرات ناگهانی در سیستم کم می‌شود، به طور خلاصه می‌توان گفت توسعه نرم‌افزار منظم تر و ساده‌تر انجام می‌شود. ·       Hexagonal Architectureمشکلی که در بسیاری از سیستم ها دیده می‌شود این است که منطق اصلی برنامه به تکنولوژی‌های بیرونی وابسته می‌شود. برای مثال تغییر دیتابیس یا فریم‌ورک باعث می‌شود بخش های زیادی از سیستم نیاز به تغییر داشته باشند.Hexagonal Architecture رویکردی است که تلاش می‌کند منطق اصلی برنامه(Business Logic)  را از بخش‌های خارجی جدا نگه‌ دارد تا سیستم انعطاف‌پذیرتر شود. در این معماری هسته اصلی برنامه فقط شامل منطق و قوانین اصلی سیستم است و ارتباط بخش‌های خارجی از طریق بخش هایی به نام Port و Adapterها انجام می‌شود.یک فروشگاه اینترنتی را در نظر داشته باشید که امروز از MySQL استفاده می‌کند اما در آینده شاید نیاز باشد Database آن به PostgreSQL تغییر کند. در معماری Hexagonal به دلیل جدابودن منطق اصلی از دیتابیس( و دیگر بخش‌ها) این تغییر راحت‌تر انجام می‌شود. به طور خلاصه می‌توان گفت این معماری باعث کاهش وابستگی بین بخش‌های مختلف سیستم شده و تست و نگهداری نرم‌افزار را ساده تر می‌کند.Hexagonal Architecture·       Domain Driven Design(DDD)مشکل دیگری که در بسیاری از پروژه های نرم‌افزاری دیده می‌شود، تمرکز صرفا روی کدنویسی و ساخت APIها است، نه روی درک مسئله واقعی کسب و کاربرای مثال در یک فروشگاه اینترنتی اینکه یک سفارش دقیقا چه مراحلی دارد، چه زمانی قابل لغو است، تخفیف ها چگونه اعمال می‌شوند یا سبد خرید باید دقیقا چه رفتاری داشته باشد... همه این ها جزو مسائل واقعی کسب وکار لحاظ می‌شوند.Domain Driven Design یا DDD تلاش می‌کند این مشکل را حل کند. در این رویکرد خود مسئله واقعی بررسی و درک می‌شود بعد سیستم را بر اساس آن طراحی می‌کند. در روش DDD مفاهیم اصلی کسب و کار مثل سفارش، پرداخت، سبد خرید یا حتی خود کاربر به عنوان بخش اصلی سیستم لحاظ شده و مدل‌سازی می‌شوند.یکی از نکات مهم در DDD استفاده از یک زبان مشترک بین تیم فنی و کسب وکار است تا همه یک مفهوم را با یک معنی واحد درک کنند. یعنی اگر گفته میشود "Order" همه یک برداشت واحد از آن داشته باشند. در نهایت می‌توان گفت همه این مفاهیم برای یک هدف مشترک پدید آمدند: کنترل پیچیدگی در سیستم های بزرگ. هر رویکرد از یک زاویه به مشکل نگاه می‌کند یکی روی نحوه ارتباط سرویس‌ها تمرکز دارد، یکی روی طراحی APIها، دیگری روی ساختار داخلی سیستم و یکی دیگر روی درک بهتر مسئله واقعی Rana GhozatRana GhozatSun, 31 May 2026 16:54:08 +0330