https://virgool.io/feed/@m_10634336 دانشجوی کارشناسی ارشد IT دانشگاه شهید بهشتی fa 2026-06-07 14:09:36 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@m_10634336 https://virgool.io/@m_10634336/%D9%85%D9%87%D9%86%D8%AF%D8%B3%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D9%88-%D9%87%D9%88%D8%B4-%D9%85%D8%B5%D9%86%D9%88%D8%B9%DB%8C-%D8%AF%D8%B1-%DA%A9%D9%86%D8%A7%D8%B1%D9%87%D9%85-yloazowkvtkq این روزها همه‌جا صحبت از هوش‌مصنوعی است. برخی می‌گویند هوش‌مصنوعی جای برنامه‌نویسان را می‌گیرد. برخی دیگر می‌گویند نه. آنچه مسلم است ارتباط هوش‌مصنوعی و مهندسی نرم‌افزار است که به صورت یک رابطه دوطرفه باید لحاظ شود. از یک سو، هوش‌مصنوعی به مهندسان نرم‌افزار کمک می‌کند تا کدنویسی و تست سریع‌تر انجام شود. از سوی دیگر، خود سیستم‌های هوش‌مصنوعی به اصول مهندسی نرم‌افزار نیاز دارند تا قابل اطمینان و مقیاس‌پذیر باشند. در ادامه سه مفهوم کلیدی در این حوزه را بررسی می‌کنیم:AI4SEاستفاده از هوش‌مصنوعی برای کمک به کارهای مهندسی نرم‌افزار. مثلا نوشتن کد، پیدا کردن باگ یا تولید تستبرای مثال فرض کنید قصد دارید تابعی ساده بنویسید، در حالت عادی باید منطق آن را خط به خط بنویسید ولی با AI4SE کافی است منطق کد را توضیح دهید ( برای مثال تابعی که سن را از تاریخ تولد محاسبه کند) و هوش‌مصنوعی خودش کد را تولید می‌کند. این کد همواره بی‌نقص نیست، اما زمان توسعه را به شدت کاهش می‌دهد. جدا از کدنویسی AI می‌تواند در بازبینی کد هم کمک کند. برای مثال بروز خطا در بخشی از کد را پیش‌بینی کند یا بهینه‌تر شدن بخشی از کد را پیشنهاد دهد. برای تست های نرم‌افزاری هم می‌توان از هوش‌مصنوعی بهره برد. AI می‌تواند سناریوهای مختلف را حدس بزند و تست بنویسد. استفاده از AI به عنوان دستیار برای توسعه دهنده می‌تواند بسیار مفید باشد.SE4AIاین مفهوم دقیقا برعکس مفهوم قبلی است و یعنی استفاده از اصول مهندسی نرم‌افزار برای ساختن سیستم‌های هوش مصنوعی.فرض کنیم یک مدل ساخته‌ایم که کارش تشخیص ایمیل اسپم است. مدل ما با دقت 98% کار میکند. حال میخواهیم این مدل را در یک سرویس ایمیل واقعی به کار گیریم. چه چالش هایی داریم؟ مدل باید در کثری از ثانیه پاسخ دهد و داده هایی که مدل با آنها روزانه مواجه خواهد شد متفاوت از داده‌هایی است که در زمان آموزش دیده است. و چالش بعدی و مهم تر از همه زمانی است که مدل اشتباه کند( ایمیل مهمی را اسپم تشخیص دهد) در این مواقع مهندسی نرم‌افزار وارد می‌شود.SE4AI به مسائلی مثل تست‌پذیری مدل، استقرار مداوم و پایش عملکرد آن در محیط واقعی می‌پردازد.MLOpsاگر DevOps که در پست های قبلی به آن اشاره کردیم را برای یک نرم‌افزار معمولی در نظر بگیرید، MLOps همان مفهوم را برای سیستم‌های یادگیری ماشین تداعی می‌کند. اما در اینجا یک تفاوت مطرح است: در نرم‌افزار معمولی فقط کد تغییر می‌کند، در یادگیری ماشین هم کد هم داده و هم مدل تغییر می‌کنند.مفهوم MLOps از جمع‌آوری داده شروع شده و سپس پاک‌سازی و آماده سازی داده و بعد هم آموزش مدل و ارزیابی آن و در نهایت استقرار آن در محیط تولید را شامل می‌شود. البته کار ادامه خواهد داشت! باید بعد از استقرار هم مدل پایش شود. دقت مدل نباید پایین بیاید و همچنین باید بررسی شود داده های جدید با فرضیات MLOps قبلی همخوانی داشته باشد. اگر مدل افت کرد باید دوباره آموزش داده شود. این کار ها با MLOps خودکار و قابل تکرار طراحی شده و ابزارهایی مانند MLflow و Kubeflow برای همین کاربرد استفاده می‌شوند.این سه مفهوم به سادگی توضیح می‌دهد که هوش‌مصنوعی و مهندسی نرم‌افزار از هم جدا نیستند.منابع: MLflow DocsKubeflow DocsGoogle (Hidden Technical Debt) Rana Ghozat Rana Ghozat Mon, 01 Jun 2026 20:24:01 +0330 https://virgool.io/@m_10634336/chaos-engineering-%D8%A2%D8%B4%D9%88%D8%A8-%DA%A9%D9%86%D8%AA%D8%B1%D9%84-%D8%B4%D8%AF%D9%87-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%AA%D8%A7%D8%A8-%D8%A2%D9%88%D8%B1%DB%8C-%D8%A8%DB%8C%D8%B4%D8%AA%D8%B1-h2lqgnqgqlnl What 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 Engineering Rana Ghozat Rana Ghozat Mon, 01 Jun 2026 19:51:11 +0330 https://virgool.io/@m_10634336/%D8%A7%D8%A8%D8%B2%D8%A7%D8%B1%D9%87%D8%A7%DB%8C%DB%8C-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%BA%DB%8C%D8%B1%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D9%87-%D9%86%D9%88%DB%8C%D8%B3%D8%A7%D9%86-%D9%88-%D9%85%D8%AF%DB%8C%D8%B1%DB%8C%D8%AA-%D9%81%D8%B1%D8%A7%DB%8C%D9%86%D8%AF-%D9%87%D8%A7-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 Standard Rana Ghozat Rana Ghozat Mon, 01 Jun 2026 19:44:21 +0330 https://virgool.io/@m_10634336/devops-%D9%88-%D8%B2%DB%8C%D8%B1%D8%B3%D8%A7%D8%AE%D8%AA-%D8%A7%D8%B2-%DA%A9%D8%AF-%D8%AA%D8%A7-%D8%A7%D8%A8%D8%B1-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 Docs Rana Ghozat Rana Ghozat Mon, 01 Jun 2026 19:08:08 +0330 https://virgool.io/@m_10634336/4-%D9%85%D9%81%D9%87%D9%88%D9%85-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%AF%D8%B1%DA%A9-%D8%A8%D9%87%D8%AA%D8%B1-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D9%87%D8%A7%DB%8C-%D9%85%D8%AF%D8%B1%D9%86-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 Ghozat Rana Ghozat Mon, 01 Jun 2026 18:02:33 +0330 https://virgool.io/@m_10634336/%D9%88%D9%82%D8%AA%DB%8C-%D8%B3%DB%8C%D8%B3%D8%AA%D9%85-%D9%87%D8%A7-%D8%A8%D8%B2%D8%B1%DA%AF-%D9%88-%D9%BE%DB%8C%DA%86%DB%8C%D8%AF%D9%87-%D9%85%DB%8C-%D8%B4%D9%88%D9%86%D8%AF-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 Ghozat Rana Ghozat Sun, 31 May 2026 16:54:08 +0330