https://virgool.io/feed/@aliipakdel98 fa 2026-07-14 09:58:00 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@aliipakdel98 https://virgool.io/@aliipakdel98/%D9%85%D8%B1%D9%88%D8%B1%DB%8C-%D8%A8%D8%B1-%D8%B3%D8%AE%D9%86%D8%B1%D8%A7%D9%86%DB%8C-beyond-durability-database-resilience-and-entropy-reduction-with-write-ahead-logging-at-netflix-hg9j3eop7xh1 سخنرانان: Prudhviraj Karumanchi & Vidhya Arvindرویداد: QCon San Francisco 2024لینک ویدئو: https://www.infoq.com/presentations/netflix-write-ahead-logging/معرفی سخنرانیوقتی سیستمی به ابعاد نتفلیکس می‌رسد که صدها میلیون کاربر، هزاران سرویس و ده‌ها فناوری ذخیره‌سازی مختلف از Cassandra تا کش‌های توزیع‌شده دارد، سوال‌های ساده‌ای مثل «مطمئنیم این داده واقعاً ذخیره شد؟» یا «چرا این دو نسخه از داده با هم نمی‌خوانند؟» به مسائل معماری تمام‌عیار تبدیل می‌شوند. در این ارائه از QCon سان‌فرانسیسکو ۲۰۲۴، پرودویراج کارومانچی و ویدیا آرویند، دو مهندس ارشد پلتفرم داده نتفلیکس، توضیح می‌دهند که چطور با ساختن یک سرویس عمومی «ثبت پیش‌نویس» (Write-Ahead Log یا WAL) در سطح پلتفرم، مجموعه‌ای از دردناک‌ترین مشکلات سیستم‌های توزیع‌شده مانند ازدست‌رفتن داده، واگرایی نسخه‌ها و جهش‌های چندپارتیشنی را یک بار برای همه تیم‌ها حل کرده‌اند. چیزی که این ارائه را خاص می‌کند این است که یک ایده قدیمی و اثبات‌شده از دل پایگاه‌های داده را بیرون کشیده و به‌عنوان یک بلوک معماری مستقل و قابل استفاده مجدد بازآفرینی کرده است.خلاصه و نکات اصلی سخنرانیسخنرانان از صورت‌مسئله شروع می‌کنند: در مقیاس نتفلیکس، خرابی نه استثنا بلکه وضعیت عادی است. نوشتنی که به‌ظاهر موفق بوده ممکن است در یکی از مقصدها گم شود؛ داده‌ای که باید هم در پایگاه داده اصلی و هم در کش و هم در ایندکس ثانویه بنشیند، ممکن است فقط در بعضی از آن‌ها بنشیند؛ و به مرور زمان «آنتروپی» که همان واگرایی خاموش بین نسخه‌های مختلف یک داده است، سیستم را می‌خورد. راه‌حل سنتی این بوده که هر تیم برای خودش منطق retry و صف و ترمیم بنویسد؛ نتیجه، ده‌ها پیاده‌سازی ناسازگار از یک مسئله واحد بود.ایده مرکزی ارائه ساده و قدرتمند است: هر جهش (Mutation) پیش از اعمال، ابتدا در یک لاگ بادوام ثبت شود و سپس از آنجا با تضمین، به مقصد یا مقصدهایش برسد. معماری سرویس WAL از چند جزء تشکیل شده که تفکیک مسئولیت تمیزی دارند: پردازشگر پیام که جهش‌ها را دریافت و در صف بادوام ثبت می‌کند، مصرف‌کننده‌ای که آن‌ها را به مقصدها می‌رساند، و یک Control Plane برای پیکربندی و پایش. نکته معمارانه کلیدی، «مقصدهای اتصال‌پذیر» (Pluggable Targets) است: همان لوله واحد می‌تواند جهش‌ها را به Cassandra، به کش، به ناحیه جغرافیایی دیگر یا به هر ذخیره‌گاه دیگری برساند؛ یعنی WAL از یک ابزار دوام داده، به ستون فقرات تکثیر بین‌سیستمی و بازسازی داده تبدیل می‌شود. بخش قابل‌توجهی از ارائه هم صادقانه به حالت‌های خرابی خود این سیستم می‌پردازد: هجوم ناگهانی ترافیک، مصرف‌کننده‌های کند، پیام‌های سمی و خطاهای ماندگار، و سازوکارهایی مثل صف‌های تأخیری و جداسازی، که برای هر کدام طراحی شده‌اند. بهای این معماری هم پنهان نمی‌شود: سازگاری نهایی به‌جای فوری، کمی تأخیر اضافه و هزینه عملیاتی یک سرویس جدید.برداشت و تحلیل شخصیدو درس از این ارائه برای من پررنگ‌تر از بقیه بود. اول، قدرت «انتزاع در سطح پلتفرم»: نتفلیکس به‌جای آن‌که به صد تیم آموزش بدهد چطور نوشتن مطمئن پیاده کنند، مسئله را یک بار در قالب سرویسی با قرارداد ساده حل کرده است. این همان تفکری است که پشت مفهوم «مسیر هموار» (Paved Path) قرار دارد و به‌گمانم مهم‌ترین الگوی معماری سازمانی دهه اخیر است: پیچیدگی را به داخل پلتفرم ببر تا تیم‌های محصول با ذهنی آزاد کار کنند. دوم، بازیافت ایده‌های کهنه: WAL دهه‌هاست قلب هر پایگاه دادهٔجدی است؛ کاری که نتفلیکس کرده «اختراع» نیست، «تغییر مقیاسِ» یک الگوی اثبات‌شده است — از داخل یک پروسه به کل یک اکوسیستم. این نگاه برای ما هم آموزنده است: قبل از ساختن راه‌حل بدیع، بپرسید کدام الگوی چهل‌ساله دارد همین مسئله را در لایه‌ای دیگر حل می‌کند. اگر بخواهم نقدی هم بکنم، این است که ارائه درباره هزینه نگهداری چنین سرویسی برای سازمان‌های کوچک‌تر کم می‌گوید؛ چیزی که خودشان هم تلویحاً می‌پذیرند این است که این معماری وقتی می‌ارزد که تعداد مصرف‌کننده‌هایش از حدی بگذرد.شاید هیچ‌وقت WAL اختصاصی نسازید، اما الگوهای این ارائه در مقیاس‌های بسیار کوچک‌تر هم کار می‌کنند. اگر جایی در سیستم شما یک نوشتن باید به چند مقصد برسد، به‌جای نوشتن مستقیم و دعاکردن، الگوی مشابهی مثل Transactional Outbox یا یک صف بادوام میانی بگذارید تا تحویل تضمین‌شده و قابل‌تکرار شود. برای بازی‌های آنلاین این سناریو کاملاً ملموس است: رویدادهای اقتصاد درون بازی (خرید، جایزه، ارتقا) دقیقاً همان جهش‌های حساسی هستند که نه باید گم شوند و نه دو بار اعمال شوند؛ ترکیب لاگ بادوام با مصرف‌کننده idempotent همان تضمینی را می‌دهد که نتفلیکس برای داده‌هایش می‌خواهد. الگوی «ترمیم آنتروپی» هم مستقیم قابل استفاده است: یک job دوره‌ای که نسخه‌های مختلف داده را مقایسه و واگرایی‌ها را گزارش یا ترمیم می‌کند، برای هر سیستمی که کش یا ایندکس ثانویه دارد، بیمه‌نامه ارزانی است.جمع‌بندیاین ارائه نمونه خوبی از معماری «بالغ» است: نه شیفته فناوری جدید، نه اسیر پیچیدگی نمایشی؛ فقط بازشناسی یک الگوی کلاسیک و بالابردن آن به سطحی که کل سازمان از آن سود ببرد. درس‌های کلیدی: دوام و سازگاری داده را به امید کد اپلیکیشن رها نکنید و آن را به زیرساختی صریح بسپارید؛ مسائل تکرارشونده را یک بار و در سطح پلتفرم حل کنید؛ برای خرابی مصرف‌کننده‌ها و پیام‌های سمی از روز اول طرح داشته باشید؛ و بین سازگاری فوری و تاب‌آوری، آگاهانه و صریح انتخاب کنید. برای هر مهندسی که با داده‌های حیاتی در سیستم‌های توزیع‌شده سروکار دارد، این پنجاه دقیقه سرمایه‌گذاری پرسودی است.اين مطلب، بخشی از تمرين‌های درس معماری نرم‌افزار در دانشگاه شهيد بهشتی است. علی پاکدل علی پاکدل Sat, 11 Jul 2026 22:55:14 +0330 https://virgool.io/@aliipakdel98/%D9%85%D8%B1%D9%88%D8%B1%DB%8C-%D8%A8%D8%B1-%D8%B3%D8%AE%D9%86%D8%B1%D8%A7%D9%86%DB%8C-an-introduction-to-residuality-theory-xpo2hgzalrvv سخنران: Barry O'Reillyرویداد: NDC London 2024لینک ویدئو: https://www.youtube.com/watch?v=_MPUoiG6w_Uمعرفی سخنرانیدر این سخنرانی، به‌جای معرفی یک ابزار یا الگوی جدید، خود شیوه فکرکردن ما به طراحی را به چالش می‌کشد. «نظریه باقی‌مانده‌ها» (Residuality Theory) از بری اورایلی از این جنس است. اورایلی سال‌ها معمار سیستم‌های سازمانی بزرگ بوده و بعد برای پاسخ به یک سوال آزاردهنده به برگشته است: چرا معماری‌هایی که با دقت طراحی می‌کنیم، در برخورد با واقعیت این‌قدر زود می‌شکنند؟ پاسخ او تلفیقی غیرمنتظره از معماری نرم‌افزار و علم سیستم‌های پیچیده است و این سخنرانی، بهترین نقطه ورود به آن است.خلاصه و نکات اصلی سخنرانیاستدلال اورایلی از یک مشاهده ساده شروع می‌شود: نرم‌افزار، سیستمی «مرتب» (Ordered) است (قطعی و قابل تحلیل) اما در محیطی «پیچیده» (Complex) زندگی می‌کند: بازار، رقبا، قانون‌گذار، کاربران و مدیرانی که رفتارشان پیش‌بینی‌ناپذیر است. او این وضعیت دوگانه را «هایپرلیمینال» می‌نامد. رویکرد سنتی ما فرض می‌کند آینده قابل استخراج از ذی‌نفعان است؛ در حالی که در محیط پیچیده، مهم‌ترین اتفاقات آن‌هایی هستند که هیچ‌کس پیش‌بینی نکرده است.جایگزین پیشنهادی او چنین است: طراحی را با یک «معماری ساده‌لوحانه» شروع کنید؛ همان طرح اولیه‌ای که با دانش امروز می‌کشید. سپس به‌جای افزودن نیازمندی‌های بیشتر، سیستم را زیر رگبار «استرسورها» بگیرید: اگر تأمین‌کننده اصلی ورشکست شود چه؟ اگر بار سیستم ده برابر شود؟ اگر قانون جدیدی مدل درآمد را ممنوع کند؟ اگر رقیبی سرویس را رایگان عرضه کند؟ برای هر استرسور بررسی می‌کنید چه چیزی از معماری «باقی می‌ماند» و طرح را طوری اصلاح می‌کنید که باقی‌مانده کارآمدتری داشته باشد. ابزار عملی این کار «ماتریس وقوع» (Incidence Matrix) است: جدولی از استرسورها در برابر اجزای سیستم که نشان می‌دهد هر شوک به کدام اجزا سرایت می‌کند. این ماتریس ساختار پنهان و اتصال‌های واقعی سیستم را آشکار می‌کند. ادعای جسورانه و جالب اورایلی، که آن را با پژوهش دانشگاهی هم محک زده، این است که تمرین‌دادن معماری با استرسورهای تصادفی، مثل آموزش شبکه عصبی، سیستم را در برابر شوک‌های «دیده‌نشده» هم مقاوم‌تر می‌کند؛ چون آنچه واقعاً بهبود می‌یابد، ساختار اتصالات درونی سیستم است، نه پاسخ به تک‌تک سناریوها.برداشت و تحلیل شخصیاولین بار که این سخنرانی را دیدم، حس کردم کسی بالاخره برای شهودی که هر معمار باتجربه‌ای دارد (این‌که طرح اول همیشه غلط است) یک چارچوب نظری و قابل آموزش ساخته است. زیبایی نظریه باقی‌مانده‌ها این است که عدم قطعیت را نه دشمنی که باید حذف شود، بلکه ماده اولیه طراحی می‌داند. مقایسه آن با رویکردهای رایج هم روشنگر است: تحلیل ریسک سنتی فقط ریسک‌های «محتمل و شناخته‌شده» را می‌بیند، اما استرسورهای اورایلی عمداً تصادفی و حتی نامعقول انتخاب می‌شوند، چون هدف، پیش‌بینی نیست؛ ورزیده‌کردن ساختار است. البته نقدی هم دارم: فرایند کامل آن برای پروژه‌های کوچک شاید سنگین باشد و مهارت تسهیلگری قابل‌توجهی می‌خواهد تا جلسات استرسور به فهرست نگرانی‌های تکراری تبدیل نشود. اما حتی نسخهٔ سبک آن هم از هیچ‌چیز بهتر است.عملی‌ترین کاربرد این ایده‌ها در فاز طراحی اولیه و بازبینی‌های معماری است. می‌توانید کارگاه نیم‌روزه‌ای برگزار کنید: معماری فعلی یا پیشنهادی را روی تخته بکشید، از اعضای تیم (و نه فقط فنی‌ها) بخواهید بیست استرسور بنویسند و سپس ماتریس وقوع را پر کنید. جاهایی که یک استرسور به چندین جزء سرایت می‌کند، اتصال‌های پنهان شماست؛ همان‌جا باید مرز، انتزاع یا افزونگی اضافه کنید. این تمرین به‌خصوص پیش از تصمیم‌های گران‌برگشت (انتخاب پلتفرم، مدل استقرار، وابستگی به یک فروشنده خاص) ارزش واقعی دارد و خروجی‌اش را می‌توان مستقیم به ADRها برد.جمع‌بندینظریه باقی‌مانده‌ها به ما می‌گوید معماری خوب آن نیست که برای نیازمندی‌های امروز بهینه باشد؛ آن است که بعد از شوک‌های فردا، چیز مفیدی از آن باقی بماند. درس‌های کلیدی: به‌جای پیش‌بینی آینده، ساختار را در برابر تصادف ورزیده کنید؛ اتصال‌های پنهان را با استرسور آشکار کنید؛ و طرح اول را همیشه پیش‌نویس بدانید. این سخنرانی برای هر کسی که در محیطی بی‌ثبات نرم‌افزار می‌سازد، دیدنی و شاید ضروری است.اين مطلب، بخشي از تمرين‌های درس معماری نرم‌افزار در دانشگاه شهيد بهشتی است. علی پاکدل علی پاکدل Sat, 11 Jul 2026 22:44:03 +0330 https://virgool.io/@aliipakdel98/%D9%85%D8%B1%D9%88%D8%B1%DB%8C-%D8%A8%D8%B1-%D8%B3%D8%AE%D9%86%D8%B1%D8%A7%D9%86%DB%8C-architectural-decisions-in-modern-software-development-zfhqeephzhxq سخنران: Andrew Harmel-Lawرویداد: Global Software Architecture Summit (GSAS) 2024لینک ویدئو: https://www.youtube.com/watch?v=aMKUr5b8Fnwمعرفی سخنرانیاندرو هارمل‌لا در این سخنرانی در اجلاس جهانی معماری نرم‌افزار در بارسلونا، سراغ موضوعی می‌رود که یکی از مهم‌ترین بخش‌های معماری است: نه «چه تصمیمی بگیریم»، بلکه «چطور و توسط چه کسی تصمیم گرفته شود».خلاصه و نکات اصلی سخنرانیهارمل‌لا از تعریف شروع می‌کند: به قول گریدی بوچ، معماری همان «تصمیم‌های مهم طراحی» است و اهمیت را «هزینه تغییر» می‌سنجد. پس هر جا تصمیمی گران‌برگشت گرفته می‌شود، دارد معماری اتفاق می‌افتد؛ چه معماری رسمی در اتاق باشد چه نباشد. او سپس دو الگوی سنتی تصمیم‌گیری را کالبدشکافی می‌کند. الگوی اول «برج عاج» است: معمار یا کمیته معماری تصمیم می‌گیرد و تیم‌ها اجرا می‌کنند. این الگو گلوگاه می‌سازد، تصمیم‌ها را از واقعیت کد دور می‌کند و توسعه‌دهندگان را به مجریان بی‌انگیزه تبدیل می‌کند. الگوی دوم واگذاری کامل به تیم‌های خودمختار است که در عمل به ناسازگاری، دوباره‌کاری و ازدست‌رفتن تصویر کلان می‌انجامد. نکته ظریف سخنرانی این است که هر دو الگو در یک چیز مشترک‌اند: جریان یادگیری و اطلاعات را قطع می‌کنند.پیشنهاد او «فرایند مشورت» است با یک قاعده ساده اما رادیکال: هر کسی می‌تواند تصمیم معماری بگیرد، به شرط آن‌که پیش از تصمیم، با دو گروه مشورت کند — کسانی که از تصمیم اثر می‌پذیرند و کسانی که در آن موضوع تخصص دارند. مشورت الزامی است اما تبعیت از آن نه؛ تصمیم‌گیرنده پس از شنیدن، خودش تصمیم می‌گیرد و مسئولیتش را می‌پذیرد. این فرایند با چند سازوکار پشتیبان کامل می‌شود: ثبت تصمیم‌ها در قالب ADR (سوابق تصمیم معماری)، جلسه هفتگی «انجمن مشورتی معماری» برای گفت‌وگوی شفاف، و اصول فنی تیم‌محور که چارچوب تصمیم‌ها را می‌سازند. هارمل‌لا تأکید می‌کند که هدف، تصمیمِ «بی‌نقص» نیست؛ هدف تصمیم‌گیری سریع، برگشت‌پذیر و یادگیرنده است، چون در سیستم‌های اجتماعی‌فنی، بازخورد سریع از کمال‌گرایی ارزشمندتر است.برداشت و تحلیل شخصیچیزی که این سخنرانی را از یک بحث فرایندی خشک نجات می‌دهد، درک عمیق هارمل‌لا از روان‌شناسی سازمان است. او صادقانه می‌گوید سخت‌ترین بخش این تحول، فنی نیست؛ ترس توسعه‌دهنده از پذیرش مسئولیت و ترس معمار از واگذاری قدرت است. به نظرم این دقیق‌ترین توصیف از وضعیت بسیاری از سازمان‌های ماست، جایی که «تأیید معماری» به آیینی زمان‌بر تبدیل شده که نه کیفیت می‌آورد و نه چابکی. نکته دیگری که برایم جالب بود، پیوند این ایده با مفهوم جریان (Flow) است: در دنیایی که تحویل مداوم و تیم‌های محصول‌محور استاندارد شده‌اند، تصمیم‌گیری متمرکز آخرین گلوگاه باقی‌مانده است. هارمل‌لا در واقع می‌گوید معماری هم باید مثل استقرار، «توزیع‌شده» شود؛ و معمار به‌جای دروازه‌بان، باید تسهیلگر و باغبان زمینه تصمیم‌گیری باشد.پیاده‌سازی این ایده‌ها لازم نیست انقلابی باشد. قدم اول که همین امروز قابل اجراست، جدی‌گرفتن ADRهاست: هر تصمیم مهم، در یک سند کوتاه با زمینه، گزینه‌ها و نتیجه ثبت شود و در مخزن کد کنار خود کد زندگی کند. قدم دوم، راه‌اندازی یک جلسه مشورتی دوهفتگی است که در آن تصمیم‌های در جریان مطرح می‌شوند؛ نه برای تأییدگرفتن، بلکه برای شنیدن دیدگاه‌ها. برای تیم‌هایی که اغلب ساختارهای سلسله‌مراتبی دارند، شاید شروع تدریجی بهتر جواب بدهد: ابتدا دامنه مشخصی از تصمیم‌ها (مثلاً انتخاب کتابخانه‌ها و طراحی APIهای داخلی) به تیم‌ها واگذار شود و با بلوغ فرهنگ مشورت، دامنه گسترش یابد. تجربهٔ سازمان‌هایی که این مسیر را رفته‌اند نشان می‌دهد کیفیت تصمیم‌ها نه‌تنها افت نمی‌کند، بلکه به‌خاطر نزدیکی تصمیم‌گیرنده به مسئله، بهتر هم می‌شود.جمع‌بندیاین سخنرانی یادآوری می‌کند که معماری نرم‌افزار پیش از آن‌که مجموعه‌ای از دیاگرام‌ها باشد، مجموعه‌ای از تصمیم‌هاست؛ و کیفیت یک سیستم در بلندمدت، تابع کیفیتِ «فرایند» تصمیم‌گیری آن است. درس کلیدی: تصمیم‌گیری را به نزدیک‌ترین نقطه به مسئله ببرید، مشورت را اجباری و اطاعت را اختیاری کنید، و همه‌چیز را شفاف ثبت کنید. برای هر معمار یا مدیر فنی که حس می‌کند خودش گلوگاه سازمانش شده، این ویدیو می‌تواند نقطهٔ شروع یک تغییر جدی باشد.اين مطلب، بخشی از تمرين‌های درس معماری نرم‌افزار در دانشگاه شهيد بهشتی است. علی پاکدل علی پاکدل Sat, 11 Jul 2026 22:36:59 +0330 https://virgool.io/@aliipakdel98/%D9%85%D8%B1%D9%88%D8%B1%DB%8C-%D8%A8%D8%B1-%D8%B3%D8%AE%D9%86%D8%B1%D8%A7%D9%86%DB%8C-complexity-is-the-gotcha-of-event-driven-architecture-zekjeu3ftlac سخنران: David Boyneرویداد: GOTO EDA Day London 2024لینک ویدئو: https://www.youtube.com/watch?v=VLUvfIm9wnQمعرفی سخنرانیمعماری رویدادمحور (Event-Driven Architecture) در چند سال اخیر به یکی از پرطرفدارترین سبک‌های معماری تبدیل شده است؛ وعده‌اش هم وسوسه‌کننده است: سرویس‌هایی مستقل که به‌جای فراخوانی مستقیم یکدیگر، فقط رویداد منتشر می‌کنند و هر مصرف‌کننده‌ای آزاد است هر طور می‌خواهد واکنش نشان دهد. اما دیوید در این سخنرانی در رویداد تخصصی GOTO EDA Day لندن، روی دیگر سکه را نشان می‌دهد: همان جادویی که سیستم شما را منعطف می‌کند، اگر مهارش نکنید، آن را به کلافی سردرگم از رویدادهای بی‌صاحب و جریان‌های نامرئی تبدیل می‌کند. بوین سال‌ها تجربه کار با تیم‌های واقعی را دارد و همین باعث شده حرف‌هایش کمتر شبیه تبلیغ و بیشتر شبیه گزارشی صادقانه از میدان باشد.خلاصه و نکات اصلی سخنرانیبوین بحث را از جذابیت‌های واقعی EDA شروع می‌کند: جداسازی زمانی و مکانی سرویس‌ها، مقیاس‌پذیری مستقل، امکان افزودن مصرف‌کننده جدید بدون دست‌زدن به تولیدکننده، و هم‌راستایی طبیعی با رویدادهای دنیای کسب‌وکار. اما بلافاصله سراغ نکته اصلی می‌رود: پیچیدگی در EDA ناگهانی نمی‌آید، بلکه آرام‌آرام و رویداد به رویداد انباشته می‌شود. تیمی که با ده رویداد شروع کرده، دو سال بعد با صدها نوع رویداد روبه‌روست که هیچ‌کس فهرست کاملشان را ندارد: رویدادهایی با نام‌های ناسازگار، اسکیماهای مستندنشده، رویدادهای تکراری که چند تیم بی‌خبر از هم منتشر می‌کنند، و مصرف‌کنندگانی که کسی نمی‌داند به چه چیزی وابسته‌اند. جریان کنترل که در سیستم همزمان با یک پشته فراخوانی قابل ردیابی بود، حالا در دل بروکرها و صف‌ها پخش شده و پاسخ به ساده‌ترین سوال «اگر این رویداد را تغییر بدهم چه می‌شکند؟» به تحقیقی چندروزه تبدیل می‌شود.هسته پیشنهادی سخنرانی این است که رویدادها را باید مثل API عمومی و به‌عنوان «قرارداد» جدی بگیریم، نه پیام‌هایی درجه‌دو. این یعنی چند تمرین مشخص: طراحی آگاهانه رویدادها (تصمیم صریح بین رویداد لاغر صرفاً اعلانی و رویداد چاق حامل وضعیت، چون هر کدام نوع متفاوتی از وابستگی می‌سازد)، قراردادهای اسکیمای صریح و نسخه‌بندی‌شده، قواعد نام‌گذاری سراسری، و مهم‌تر از همه، مالکیت روشن: هر رویداد باید تیم صاحب و پاسخ‌گو داشته باشد. بوین روی «کشف‌پذیری» تأکید ویژه دارد (مصرف‌کننده بالقوه باید بتواند بفهمد چه رویدادهایی وجود دارند، چه معنایی دارند و اسکیمایشان چیست) و اینجاست که ابزارهایی مثل EventCatalog و رجیستری اسکیما از «امکانات لوکس» به زیرساخت حیاتی تبدیل می‌شوند. پیام پایانی او درباره حاکمیت (Governance) است: نه کمیته‌های سنگین، بلکه گاردریل‌های سبک و خودکار (استانداردها، قالب‌ها و بررسی‌های خودکار در CI) که بگذارند تیم‌ها سریع بمانند اما آشوب تولید نکنند. برداشت و تحلیل شخصیچیزی که این سخنرانی را برای من ارزشمند می‌کند، جابه‌جاکردن محل بحث است: بیشتر محتوای آموزشی EDA درباره «ساختن» است مانند بروکر کدام باشد و الگوی Saga چطور پیاده شود اما بوین درباره «زیستن» با EDA حرف می‌زند؛ درباره سال دوم و سوم، وقتی هیجان اولیه فروکش کرده و هزینه واقعی خودش را نشان می‌دهد. بوین نشان می‌دهد این پیچیدگی جابه‌جاشده دقیقاً کجا می‌نشیند (در دانش سازمانی). در سیستم رویدادمحور، معماری واقعی نه در کد که در مجموعه قراردادهای بین تیم‌هاست، و اگر این قراردادها مستند و مدیریت نشوند، شما عملاً معماری‌ای دارید که فقط در ذهن چند نفر وجود دارد. به نظرم درس بزرگ‌تر این است که مستندسازی در EDA برخلاف تصور رایج، یک کار «بعداً انجام می‌دهیم» نیست؛ بخشی از خود معماری است.اگر همین حالا سیستم رویدادمحور دارید یا در حال طراحی آن هستید، چند اقدام مشخص از دل این سخنرانی درمی‌آید. اول، قبل از نوشتن حتی یک رویداد جدید، سند کوتاهی از قواعد نام‌گذاری و ساختار رویدادها بنویسید و آن را در قالب یک قالب آماده (Template) به تیم‌ها بدهید؛ هزینه‌اش یک روز است و جلوی سال‌ها ناسازگاری را می‌گیرد. دوم، یک کاتالوگ رویداد راه بیندازید که برای هر رویداد، مالک، اسکیما، نسخه و مصرف‌کنندگان شناخته‌شده را ثبت کند و به‌روزماندنش را در فرایند بازبینی کد اجباری کنید. سوم، برای تغییر اسکیماها از همان ابتدا سیاست نسخه‌بندی تعیین کنید؛ تجربه نشان داده «فعلاً نسخه نمی‌خواهیم» گران‌ترین جمله EDA است. در پروژه‌هایی مثل بازی‌های آنلاین که رویدادهای حیاتی فراوانی دارند این نظم از روز اول تعیین می‌کند که دو سال بعد می‌توانید ویژگی جدید را در یک هفته اضافه کنید یا باید یک ماه باستان‌شناسی رویدادها انجام دهید.جمع‌بندیسخنرانی بوین یادآوری به‌موقعی است برای همه ما که فریفته زیبایی معماری رویدادمحور شده‌ایم: EDA پیچیدگی را از لحظه استقرار به دوران بهره‌برداری منتقل می‌کند و اگر برای آن دوران برنامه نداشته باشید، بدهی فنی‌تان به‌جای کد، در نقشه ذهنی سازمان انباشته می‌شود. درس‌های کلیدی: رویداد یعنی قرارداد عمومی، پس مثل API با آن رفتار کنید؛ کشف‌پذیری و مالکیت را از روز اول بسازید؛ و حاکمیت را نه با کمیته، که با گاردریل‌های خودکار اعمال کنید. برای هر تیمی که بیش از ده‌ها نوع رویداد در تولید دارد، این ویدیو کمتر از یک ساعت وقت می‌گیرد و احتمالاً ماه‌ها دردسر آینده را کم می‌کند.اين مطلب، بخشی از تمرين‌های درس معماری نرم‌افزار در دانشگاه شهيد بهشتی است. علی پاکدل علی پاکدل Sat, 11 Jul 2026 22:30:10 +0330 https://virgool.io/@aliipakdel98/%D9%85%D8%B1%D9%88%D8%B1%DB%8C-%D8%A8%D8%B1-%D8%B3%D8%AE%D9%86%D8%B1%D8%A7%D9%86%DB%8C-microservices-where-did-it-all-go-wrong-jxu0jaturh7d سخنران: Ian Cooperرویداد: GOTO Copenhagen 2024لینک ویدئو: https://www.youtube.com/watch?v=j2AQ9eTZ3-0معرفی سخنرانیاگر در ده سال گذشته در صنعت نرم‌افزار کار کرده باشید، تقریباً غیرممکن است که با موج میکروسرویس‌ها برخورد نکرده باشید؛ موجی که با وعده استقلال تیم‌ها، استقرار مستقل و مقیاس‌پذیری بی‌پایان شروع شد و در بسیاری از سازمان‌ها به سیستم‌هایی پیچیده، کند و شکننده ختم شد. یان کوپر در این سخنرانی سراغ سوالی می‌رود که خیلی از ما جرئت پرسیدنش را نداشتیم: کجای راه را اشتباه رفتیم؟ نکته جذاب این است که کوپر مخالف میکروسرویس نیست؛ او مدافع نسخه «درست» این ایده است و دقیقاً به همین دلیل نقدش شنیدنی از آب درآمده است.خلاصه و نکات اصلی سخنرانیکوپر بحث را با تاریخچه شروع می‌کند و نشان می‌دهد میکروسرویس‌ها از خلأ نیامده‌اند؛ ریشه آن‌ها در SOA، در ایده Bounded Context از طراحی دامنه‌محور (DDD) و در نیاز سازمان‌های بزرگی مثل آمازون و نتفلیکس به مقیاس‌دادن «سازمان» است، نه صرفاً نرم‌افزار. تعریف کلاسیک جیمز لوئیس و مارتین فاولر هم همین را می‌گوید: سرویس‌هایی که حول قابلیت‌های کسب‌وکار شکل می‌گیرند و به‌طور مستقل قابل استقرارند. مشکل از جایی شروع شد که صنعت این «چرا» را فراموش کرد و فقط «چطور» را کپی کرد.به روایت کوپر، بزرگ‌ترین خطای رایج، تفسیر واژه «میکرو» به‌معنای «هرچه کوچک‌تر بهتر» بود. تیم‌ها به‌جای تقسیم سیستم بر اساس مرزهای دامنه، آن را بر اساس موجودیت‌های داده‌ای (Entity Service) خرد کردند: سرویس مشتری، سرویس سفارش، سرویس محصول؛ سرویس‌هایی بی‌رفتار و صرفاً CRUD که برای انجام هر کار معناداری باید با هم صحبت کنند. نتیجه این کار همان چیزی است که کوپر و دیگران «مونولیت توزیع‌شده» می‌نامند: سیستمی که همه اتصالات و وابستگی‌های یک مونولیت را دارد، اما به‌جای فراخوانی تابع در حافظه، از شبکه با همه خطاها، تأخیرها و پیچیدگی‌هایش عبور می‌کند. به تعبیر خود او، ما پیچیدگی را حذف نکردیم؛ فقط آن را از داخل کد به بین سرویس‌ها منتقل کردیم، جایی که دیدن و دیباگ‌کردنش به‌مراتب سخت‌تر است.نکته کلیدی دیگر سخنرانی، هزینه عملیاتی این سبک معماری است: زیرساخت مشاهده‌پذیری، ردیابی توزیع‌شده، سازگاری نهایی (Eventual Consistency)، تراکنش‌های توزیع‌شده و بار شناختی سنگینی که روی تیم‌ها می‌گذارد. راه‌حل پیشنهادی کوپر بازگشت به اصول است: سرویس‌ها را حول Bounded Contextها طراحی کنید، از دانه‌بندی درشت‌تر شروع کنید و اگر مقیاس سازمانی‌تان ایجاب نمی‌کند، اصلاً با یک مونولیت ماژولار شروع کنید که مرزهای داخلی تمیزی دارد و در آینده قابل تفکیک است.برداشت و تحلیل شخصیچیزی که این سخنرانی را برای من متمایز می‌کند، صداقت تاریخی آن است. کوپر نمی‌گوید میکروسرویس بد است، بلکه می‌گوید میکروسرویس پاسخ به یک مسئله مشخص است: وقتی تعداد تیم‌ها آن‌قدر زیاد شده که هماهنگی برای استقرار مشترک، گلوگاه سازمان شده است. اگر این مسئله را ندارید، دارید هزینه راه‌حل مسئله دیگران را می‌پردازید. به نظرم عمیق‌ترین درس سخنرانی این است که معماری پیش از آن‌که تصمیمی فنی باشد، تصمیمی سازمانی است؛ همان چیزی که قانون کانوی سال‌هاست به ما یادآوری می‌کند. تجربه خودم هم همین را تأیید می‌کند: تیم‌های پنج‌نفره‌ای که بیست سرویس را نگهداری می‌کنند، عملاً بیشتر وقتشان صرف زیرساخت می‌شود تا ارزش کسب‌وکار.این سخنرانی برای دو گروه کاربرد مستقیم دارد. گروه اول تیم‌هایی هستند که در آستانه شروع پروژه جدیدند: پیش از انتخاب میکروسرویس، صادقانه بپرسید چند تیم دارید، چند بار در روز نیاز به استقرار مستقل دارید و آیا زیرساخت مشاهده‌پذیری و CI/CD بالغی دارید یا نه. اگر پاسخ‌ها منفی است، مونولیت ماژولار با مرزهای دامنه‌ای روشن (مثلاً به‌کمک تفکیک ماژول‌ها و قراردادهای داخلی صریح) انتخاب عاقلانه‌تری است. گروه دوم سازمان‌هایی هستند که الان در باتلاق مونولیت توزیع‌شده گیر کرده‌اند: مسیر پیشنهادی، ادغام سرویس‌های ریز و پرگفت‌وگو در واحدهای درشت‌تر هم‌راستا با دامنه است؛ حرکتی که برخلاف تصور، معمولاً هم کارایی را بهتر می‌کند و هم سرعت توسعه را.جمع‌بندی«Microservices, Where Did It All Go Wrong» یک تسویه‌حساب صادقانه با پرهیاهوترین ترند معماری دههٔ اخیر است. درس‌های کلیدی آن روشن‌اند: میکروسرویس ابزار مقیاس‌دادن سازمان است نه مد روز؛ مرز سرویس باید مرز دامنه باشد نه مرز جدول پایگاه داده؛ و کوچک‌بودن به‌خودی‌خود فضیلت نیست، استقلال در تغییر و استقرار فضیلت است. اگر فقط یک ویدیو دربارهٔ میکروسرویس می‌خواهید ببینید، بگذارید همین باشد؛ چون به‌جای فروختن رؤیا، به شما یاد می‌دهد چه سؤال‌هایی بپرسید.اين مطلب، بخشی از تمرين‌های درس معماری نرم‌افزار در دانشگاه شهيد بهشتی است. علی پاکدل علی پاکدل Sat, 11 Jul 2026 22:16:14 +0330 https://virgool.io/@aliipakdel98/%D8%AA%D8%AC%D8%B1%D8%A8%D9%87-%D9%85%D8%B7%D8%A7%D9%84%D8%B9%D9%87-%DA%A9%D8%AA%D8%A7%D8%A8-game-programming-patterns-d1wipwuqbcje این مطلب مربوط به تجربه مطالعه کتاب Game Programming Patterns نوشته‌ی رابرت نایستروم می‌باشد. این کتاب یکی از شناخته‌شده‌ترین کتاب‌ها در حوزه معماری و طراحی نرم‌افزار برای بازی‌های ویدیویی است و با استفاده از مثال‌های واقعی از توسعه بازی، الگوهای طراحی مختلف را معرفی می‌کند.دلیل انتخاب این کتاب، علاقه و فعالیت اصلی من در حوزه بازی‌سازی بود. بیشتر تجربه برنامه‌نویسی من مربوط به توسعه بازی و پیاده‌سازی سیستم‌های Gameplay و هوش مصنوعی است. به همین دلیل، احساس می‌کردم مطالعه کتابی که مستقیماً از مسائل واقعی توسعه بازی صحبت می‌کند، برایم مفیدتر از مطالعه کتاب‌های معماری عمومی خواهد بود. علاوه بر این، بارها نام این کتاب را در بین برنامه‌نویسان بازی شنیده بودم و مدت زیادی بود که قصد خواندن آن را داشتم.از این کتاب فصل‌های Architecture, Performance, and Games، Component، Event Queue، Observer، Command، State، Service Locator و Object Pool را مطالعه کردم.تجربه خواندن این کتاب برای من با بسیاری از کتاب‌های فنی دیگر متفاوت بود. معمولاً هنگام خواندن کتاب‌های معماری نرم‌افزار، مثال‌ها مربوط به سیستم‌های بانکی، فروشگاه‌های اینترنتی یا نرم‌افزارهای سازمانی هستند و گاهی ارتباط دادن آن‌ها به بازی‌سازی دشوار است. اما در این کتاب تقریباً هر مثال به مشکلی اشاره می‌کند که یک برنامه‌نویس بازی احتمالاً با آن مواجه شده است؛ از کنترل شخصیت و مدیریت انیمیشن‌ها گرفته تا سیستم صوتی، مدیریت حافظه و طراحی رفتار دشمنان.در همان فصل ابتدایی، بخشی که بیش از همه توجه من را جلب کرد، تأکید نویسنده بر سادگی بود. به عنوان یک برنامه‌نویس، بارها وسوسه شده‌ام که از همان ابتدا سیستم‌ها را بسیار انعطاف‌پذیر و عمومی طراحی کنم تا برای هر نیاز احتمالی آینده آماده باشند. اما نویسنده بارها تأکید می‌کند که معماری بیش از حد می‌تواند به اندازه نداشتن معماری مضر باشد. این بخش باعث شد به برخی تصمیم‌های گذشته خودم در پروژه‌های بازی فکر کنم؛ پروژه‌هایی که در آن‌ها زمان زیادی صرف طراحی سیستم‌های بسیار عمومی کرده بودم، در حالی که شاید هنوز نیازی به آن پیچیدگی وجود نداشت.هنگام مطالعه فصل Component، بارها به سیستم‌هایی که در پروژه‌های خودم نوشته‌ام فکر می‌کردم. توصیف کلاس‌های بزرگ و چند هزار خطی که به مرور مسئولیت‌های مختلف را به خود جذب می‌کنند، برایم کاملاً آشنا بود. احساس می‌کردم نویسنده دقیقاً مشکلاتی را توصیف می‌کند که هر برنامه‌نویس بازی بعد از مدتی با آن‌ها مواجه می‌شود. این موضوع باعث شد فصل Component را با دقت بیشتری بخوانم و حتی بعد از پایان فصل، مدتی به ساختار برخی از سیستم‌های فعلی پروژه خودم فکر کنم.در فصل Event Queue، چیزی که برایم جالب بود این بود که نویسنده فقط درباره تمیزتر شدن معماری صحبت نمی‌کند، بلکه دائماً محدودیت‌های واقعی توسعه بازی را نیز در نظر می‌گیرد؛ محدودیت‌هایی مانند عملکرد، استفاده از Threadهای مختلف و هزینه‌های مدیریت حافظه. همین نگاه عملی باعث شد احساس کنم کتاب توسط کسی نوشته شده که واقعاً سال‌ها در صنعت بازی کار کرده است، نه صرفاً یک نویسنده دانشگاهی.فصل Observer نیز تجربه مشابهی داشت. هنگام خواندن مثال سیستم Achievement، بلافاصله به سیستم‌هایی که خودم در بازی‌ها پیاده‌سازی کرده‌ام فکر کردم؛ سیستم‌هایی که به مرور وابستگی‌های زیادی پیدا می‌کنند و تغییر آن‌ها دشوار می‌شود. جالب‌ترین بخش این فصل برای من، توضیح مشکلات و معایب الگو بود. در بسیاری از منابع آموزشی، الگوهای طراحی تقریباً بدون ایراد معرفی می‌شوند، اما این کتاب دائماً تأکید می‌کند که هر راه‌حل جدید، مشکلات جدیدی نیز به همراه می‌آورد.از بین تمام فصل‌هایی که مطالعه کردم، فصل State بیش از همه برایم جذاب بود. احتمالاً دلیل آن این است که در بازی‌سازی دائماً با طراحی رفتار کاراکترها و دشمنان سر و کار داریم. هنگام خواندن مثال Heroine و اضافه شدن تدریجی قابلیت‌های جدید، بارها به یاد کدهایی افتادم که با اضافه شدن ویژگی‌های جدید، به مرور پر از شرط‌ها و حالت‌های مختلف شده بودند. احساس می‌کردم مثال‌های کتاب صرفاً مثال‌های آموزشی نیستند، بلکه از مشکلات واقعی و تجربه‌های عملی نویسنده به وجود آمده‌اند.فصل Service Locator نیز برایم جالب بود، زیرا برخلاف بسیاری از مطالب اینترنتی که این الگو را یا کاملاً خوب و یا کاملاً بد معرفی می‌کنند، نویسنده دیدگاه متعادل‌تری دارد. او نشان می‌دهد که چرا این الگو به وجود آمده، چه مزایایی دارد و در عین حال در چه شرایطی می‌تواند به یک متغیر سراسری پنهان تبدیل شود. این رویکرد واقع‌گرایانه تقریباً در تمام کتاب دیده می‌شود.در نهایت، فصل Object Pool یکی از فصل‌هایی بود که بیشترین ارتباط را با تجربه‌های شخصی من داشت. در توسعه بازی، مخصوصاً در سیستم‌هایی مانند افکت‌ها، پرتابه‌ها و ذرات، موضوع مدیریت حافظه و ایجاد و حذف مداوم اشیاء اهمیت زیادی دارد. هنگام خواندن این فصل، چند بار به پیاده‌سازی‌هایی که قبلاً انجام داده بودم فکر کردم و متوجه شدم چرا بسیاری از موتورهای بازی تا این اندازه روی استفاده مجدد از اشیاء تأکید می‌کنند.به طور کلی، تجربه خواندن این کتاب برای من بیشتر از آنکه شبیه یاد گرفتن چند الگوی طراحی جدید باشد، شبیه گفت‌وگو با یک برنامه‌نویس باتجربه بازی بود که مشکلات واقعی توسعه بازی را توضیح می‌دهد و تجربه‌های خود را در قالب الگوهای مختلف به اشتراک می‌گذارد. چیزی که بیش از همه از این کتاب در ذهنم باقی ماند، خود الگوها نبودند، بلکه شیوه فکر کردن نویسنده درباره طراحی نرم‌افزار بود؛ اینکه هر تصمیم معماری یک هزینه دارد، هیچ راه‌حل کاملی وجود ندارد و سادگی و عمل‌گرایی در بسیاری از مواقع ارزش بیشتری از پیچیدگی و انتزاع بیش از حد دارند.اين مطلب، بخشی از تمرين‌های درس معماری نرم‌افزار در دانشگاه شهيد بهشتی است. علی پاکدل علی پاکدل Sat, 11 Jul 2026 15:44:31 +0330 https://virgool.io/@aliipakdel98/sa-hw1-l5oa5tctzjik ۱. مهندسی آشوب (Chaos Engineering)امروزه بسیاری از نرم‌افزارها و سرویس‌های آنلاین روی سیستم‌های پیچیده و توزیع‌شده اجرا می‌شوند. در چنین سیستم‌هایی ممکن است مشکلاتی مانند قطعی سرور، اختلال شبکه، افزایش ناگهانی کاربران یا خرابی بخشی از سیستم رخ دهد. مهندسی آشوب (Chaos Engineering) روشی است که به کمک آن این نوع خرابی‌ها به‌صورت عمدی و کنترل‌شده شبیه‌سازی می‌شوند تا مشخص شود سیستم در شرایط بحرانی چگونه عمل می‌کند.فرض کنید یک ماشین جدید ساخته‌اید. به جای اینکه منتظر بمانید تا در جاده و حین رانندگی تصادف کند، خودتان در پیست آزمایش با پتک به بدنه آن می‌کوبید یا ترمزها را دست‌کاری می‌کنید تا ببینید چقدر محکم است!مهندسی آشوب دقیقاً همین است. یعنی ما عمداً و در یک محیط کنترل‌شده، خرابکاری‌هایی (مثل قطع کردن یک سرور، شبیه‌سازی قطع اینترنت و یا پر کردن حافظه CPU) را وارد سیستم نرم‌افزاری خودمان می‌کنیم تا ببینیم آیا سیستم می‌تواند گلیم خودش را از آب بیرون بکشد و به کارش ادامه دهد یا کلاً منفجر می‌شود! هدف ما خرابکاری نیست، بلکه پیشگیری پیش‌دستانه (Proactive) از فاجعه است.به طور کلی، مهندسی آشوب به تیم‌های نرم‌افزاری کمک می‌کند تا قبل از وقوع بحران‌های واقعی، نقاط ضعف سیستم را شناسایی کرده و قابلیت اطمینان و تاب‌آوری نرم‌افزار را افزایش دهند.۲. بک‌اند برای فرانت‌اند (Backend for Frontend)Backend for Frontend یا به اختصار BFF یک الگوی معماری نرم‌افزار است که در آن برای هر نوع رابط کاربری یک بک‌اند اختصاصی در نظر گرفته می‌شود. ایده اصلی این است که نیازهای یک وب‌سایت، اپلیکیشن موبایل یا حتی یک دستگاه هوشمند با یکدیگر متفاوت هستند؛ بنابراین بهتر است هر کدام یک لایه بک‌اند مخصوص خود داشته باشند.در معماری‌های سنتی، همه فرانت‌اند‌ها مستقیماً با یک بک‌اند مشترک ارتباط برقرار می‌کنند. این موضوع باعث می‌شود بک‌اند مجبور باشد نیازهای مختلف و گاهی متناقض چندین نوع کاربر را پوشش دهد. در الگوی BFF، بین فرنت‌اند و سرویس‌های اصلی سیستم یک بک‌اند اختصاصی قرار می‌گیرد که فقط برای همان فرانت‌اند طراحی شده است.BFF یعنی ما به جای اینکه یک بک‌‌اند غول‌آسا داشته باشیم که سعی کند همه را راضی نگه دارد، برای هر کلاینت یک لایه بک‌‌اند اختصاصی و کوچک می‌سازیم. این لایه مانند یک «مترجم» عمل می‌کند که داده‌های خام را از میکروسرویس‌های اصلی می‌گیرد، آن‌ها را به شکلی که آن کلاینت خاص نیاز دارد فیلتر یا ترکیب می‌کند و تحویل می‌دهد.۳. هوش‌مصنوعی برای مهندسی نرم‌افزار (AI4SE)با پیچیده‌تر شدن سیستم‌های امروزی و کم شدن زمان عرضه به بازار، مهندسان نیاز به ابزارهای کمکی دارند. در اینجا اصطلاح AI4SE (مخفف AI for Systems Engineering) متولد می‌شود. به زبان ساده، در AI4SE از ابزارها و تکنیک‌های هوش مصنوعی (مثل یادگیری ماشین و پردازش داده‌ها) استفاده می‌شود تا فرآیند طراحی، ساخت، تست و نگهداری سیستم‌های پیچیده نرم‌افزاری را بهبود، سرعت و بهینه‌سازی ببخشد.در AI4SE از هوش مصنوعی برای انجام یا تسهیل کارهایی مانند تولید کد، یافتن خطاها، تولید تست، تحلیل نیازمندی‌ها و پیش‌بینی مشکلات احتمالی استفاده می‌شود. به این ترتیب، بخشی از کارهایی که قبلاً به‌صورت دستی انجام می‌شد، می‌تواند به کمک ابزارهای هوشمند سریع‌تر و دقیق‌تر انجام شود.۴. مهندسی‌ سیستم برای هوش‌مصنوعی (SE4AI)اگر در موضوع قبلی (AI4SE) از هوش مصنوعی به عنوان دستیار استفاده می‌کردیم، در SE4AI (مخفف Systems Engineering for AI) ورق کاملاً برمی‌گردد. در اینجا ما می‌خواهیم یک سیستم نرم‌افزاری بسازیم که خودش یک بخش هوش مصنوعی یا یادگیری ماشین در دلش دارد؛ مثلاً یک ماشین خودران، یک سیستم تشخیص پزشکی یا ابزار هوشمند بورس.سیستم‌های هوش مصنوعی معمولاً پیچیده‌تر از نرم‌افزارهای سنتی هستند؛ زیرا علاوه بر کد، شامل داده‌ها، مدل‌های یادگیری ماشین و فرآیندهای آموزش و به‌روزرسانی نیز می‌شوند. به همین دلیل، برای اطمینان از کیفیت، امنیت، قابلیت اطمینان و عملکرد صحیح این سیستم‌ها، باید از اصول مهندسی نرم‌افزار استفاده شود.تفاوت SE4AI با AI4SE در این است که در AI4SE، هوش مصنوعی به مهندسی نرم‌افزار کمک می‌کند؛ اما در SE4AI، مهندسی نرم‌افزار به ساخت و مدیریت سیستم‌های هوش مصنوعی کمک می‌کند.۵. عملیات یادگیری ماشین (MLOps)در دنیای مهندسی نرم‌افزار، ما سال‌هاست که از DevOps استفاده می‌کنیم تا فرآیند نوشتن کد و قرار دادن آن روی سرور را خودکار و سریع کنیم. اما وقتی پای یادگیری ماشین (Machine Learning) به میان می‌آید، قضیه خیلی پیچیده‌تر می‌شود؛ چون ما اینجا فقط با «کد» سروکار نداریم، بلکه با «کد + داده‌ها + مدل ریاضی» طرف هستیم.MLOps (مخفف Machine Learning Operations) مجموعه‌ای از روش‌ها و ابزارهاست که فرهنگ DevOps را وارد دنیای یادگیری ماشین می‌کند. هدف MLOps این است که چرخه حیات یک مدل هوش مصنوعی (از آماده‌سازی داده‌ها و آموزش مدل گرفته تا تست، ارزیابی، مستقر کردن روی سرور و پایش آن) را کاملاً خودکار و استاندارد کند تا مدل‌ها سریع‌تر و با خطای کمتر به دست کاربران برسند.در پروژه‌های یادگیری ماشین، تنها ساخت مدل کافی نیست. داده‌ها باید جمع‌آوری و آماده شوند، مدل آموزش ببیند، آزمایش شود، در محیط واقعی مستقر گردد و عملکرد آن به‌طور مداوم پایش شود. انجام دستی این مراحل زمان‌بر و پرخطا است. MLOps با استفاده از خودکارسازی، کنترل نسخه، CI/CD و پایش مداوم، این فرآیندها را ساده‌تر و قابل اعتمادتر می‌کند. از مهم‌ترین مزایای MLOps می‌توان به کاهش زمان استقرار مدل، افزایش همکاری بین تیم‌های داده و توسعه، بهبود کیفیت مدل‌ها و کاهش هزینه‌های نگهداری اشاره کرد.۶. زیرساخت به عنوان کد (IaC)Infrastructure as Code یا IaC روشی برای مدیریت و پیکربندی زیرساخت‌های فناوری اطلاعات از طریق کد است. در این رویکرد، به جای اینکه سرورها، شبکه‌ها، پایگاه‌های داده و سایر منابع به‌صورت دستی تنظیم شوند، تمام تنظیمات و مشخصات زیرساخت در قالب فایل‌های کد تعریف می‌شوند.IaC به زبان ساده‌تر می‌گوید که به جای کارهای دستی، بیایید کل ساختار زیرساخت (مثل سرورها، شبکه‌ها، لود بالانسرها و دیتابیس‌ها) را در قالب فایل‌های متنی و کد بنویسیم. ابزارهای IaC این کدها را می‌خوانند و خودکار در چند دقیقه دقیقاً همان محیطی که خواسته‌ایم را در کلود (مثل AWS یا سرورهای محلی) برای ما می‌سازند. با این کار، مدیریت زیرساخت دقیقاً مثل مدیریت کدهای یک نرم‌افزار می‌شود.مهم‌ترین مزیت IaC ایجاد یکپارچگی و تکرارپذیری است. وقتی زیرساخت از طریق کد تعریف شود، محیط‌های توسعه، تست و عملیاتی دقیقاً مشابه یکدیگر خواهند بود و مشکل «تفاوت محیط‌ها» به حداقل می‌رسد. همچنین استفاده از کنترل نسخه (Version Control) باعث می‌شود تغییرات زیرساخت قابل پیگیری و بازگشت باشند.۷. API Gateway & Service Meshدر معماری Microservices، دو فناوری مهم برای مدیریت ارتباطات وجود دارند: API Gateway و Service Mesh. این دو مفهوم گاهی شبیه به هم به نظر می‌رسند، اما وظایف متفاوتی دارند و معمولاً در کنار یکدیگر استفاده می‌شوند. وقتی یک معماری یکپارچه (Monolith) را می‌شکنیم و به کلی میکروسرویس کوچک تبدیل می‌شود، دو چالش بزرگ ارتباطی داریم:۱. کلاینت‌های بیرونی (مثل اپلیکیشن موبایل کاربر) چطور باید با این همه سرویس داخلی صحبت کنند؟۲. این میکروسرویس‌های داخلی چطور خودشان با یکدیگر امن و سریع ارتباط برقرار کنند؟برای حل این دو چالش، دو تکنولوژی متفاوت اما مکمل داریم: API Gateway و Service Mesh.API Gateway در ورودی سیستم قرار می‌گیرد و تمام درخواست‌های کاربران یا سیستم‌های خارجی را دریافت می‌کند. این لایه وظایفی مانند مسیریابی درخواست‌ها، احراز هویت، محدودسازی تعداد درخواست‌ها (Rate Limiting)، مدیریت نسخه‌های API و نظارت بر ترافیک را انجام می‌دهد. به بیان ساده، API Gateway دروازه ورود به سیستم است.در مقابل، Service Mesh برای مدیریت ارتباط بین سرویس‌های داخلی یک معماری میکروسرویسی استفاده می‌شود. این فناوری ارتباط سرویس‌ها با یکدیگر را کنترل می‌کند و قابلیت‌هایی مانند کشف سرویس‌ها، توازن بار (Load Balancing)، رمزنگاری ارتباطات، مانیتورینگ و مدیریت خطاها را فراهم می‌کند.۸. تفکیک مسئولیت دستور و پرس‌وجو (CQRS)CQRS (مخفف Command Query Responsibility Segregation) یا تفکیک مسئولیت فرمان و پرس‌وجو یک الگوی معماری نرم‌افزار است که عملیات خواندن اطلاعات (Query) را از عملیات نوشتن و تغییر اطلاعات (Command) جدا می‌کند. در این الگو، به جای استفاده از یک مدل مشترک برای خواندن و نوشتن داده‌ها، برای هر کدام مدل یا حتی پایگاه داده جداگانه در نظر گرفته می‌شود.در معماری‌های سنتی (CRUD)، یک مدل واحد هم برای خواندن و هم برای تغییر داده‌ها استفاده می‌شود. اما در سیستم‌های پیچیده، نیازهای بخش خواندن و نوشتن معمولاً متفاوت هستند. برای مثال، در یک فروشگاه اینترنتی، ممکن است ثبت سفارش (نوشتن) نیاز به پردازش تراکنش سنگین داشته باشد، اما کاربران هم‌زمان هزاران بار لیست محصولات (خواندن) را لود کنند. استفاده از یک مدل برای هر دو کار، کارایی سیستم را پایین می‌آورد.مزیت اصلی CQRS افزایش کارایی، مقیاس‌پذیری و انعطاف‌پذیری سیستم است. با این حال، پیاده‌سازی آن پیچیدگی بیشتری نسبت به معماری‌های معمولی دارد و معمولاً برای سیستم‌های بزرگ و پیچیده توصیه می‌شود.۹.معماری رویداد-محور (EDA)EDA (مخفف Event-Driven Architecture) یا معماری رویدادمحور یک الگوی معماری نرم‌افزار است که در آن اجزای سیستم از طریق رویدادها (Events) با یکدیگر ارتباط برقرار می‌کنند. رویداد به هر اتفاق مهمی در سیستم گفته می‌شود؛ مانند ثبت سفارش، پرداخت موفق، ورود کاربر یا تغییر وضعیت یک محصول.در معماری‌های سنتی، سیستم‌ها به صورت هم‌گام (Synchronous) با هم صحبت می‌کنند؛ یعنی سیستم A به سیستم B زنگ می‌زند و منتظر می‌ماند تا جواب را بگیرد. اگر سیستم B قطع باشد، کار سیستم A هم لنگ می‌ماند.اما معماری رویداد-محور (EDA) می‌گوید: سیستم‌ها باید به صورت ناهم‌گام (Asynchronous) و بر پایه رویدادها با هم ارتباط داشته باشند. رویداد یعنی «یک اتفاق مهم که در سیستم رخ داده و تمام شده است»؛ مثلاً: «کاربر دکمه خرید را زد»، «دمای سنسور به ۱۸۰ درجه رسید» یا «پرداخت موفقیت‌آمیز بود».در این معماری، فرستنده (Producer) رویداد کاری ندارد که چه کسی قرار است این پیام را بگیرد؛ او فقط رویداد را داخل یک تالار گفتگو ارسال می‌کند. گیرندگان رویداد (Consumers) که گوش‌به‌زنگ نشسته‌اند، هر زمان که آمادگی داشتند این پیام را برمی‌دارند و کار خودشان را انجام می‌دهند. فرستنده و گیرنده اصلاً همدیگر را نمی‌شناسند.۱۰. معماری بدون سرور (Serverless Architecture)Serverless Architecture یک سبک معماری است که در آن توسعه‌دهندگان بدون مدیریت مستقیم سرورها، برنامه‌های خود را توسعه و اجرا می‌کنند. در این مدل، تأمین، نگهداری، مقیاس‌پذیری و مدیریت زیرساخت بر عهده ارائه‌دهنده خدمات ابری است و توسعه‌دهندگان تنها روی منطق و کدنویسی برنامه تمرکز می‌کنند.بزرگ‌ترین اشتباه در کلمه Serverless این است که فکر کنیم «هیچ سروری در کار نیست!». در واقع، سرورها وجود دارند، اما دلیل این نام‌گذاری این است که شما به عنوان یک توسعه‌دهنده یا معمار نرم‌افزار، هیچ نیازی به دیدن، مدیریت، آپدیت یا خرید سرورها ندارید. در معماری سنتی، شما باید یک سرور مجازی اجاره می‌کردید، سیستم‌عاملش را آپدیت می‌کردید و نگران می‌شدید که اگر ترافیک بالا رفت سرور کرش نکند. اما در معماری بدون سرور، کل این دردسرها به عهده شرکت ارائه‌دهنده خدمات ابری (مثل آمازون، گوگل یا مایکروسافت) است. شما فقط کد خود را می‌نویسید و آپلود می‌کنید؛ سیستم ابری خودش به ازای هر درخواستی که سمت برنامه می‌آید، موقتاً یک سرور روشن می‌کند، کد شما را اجرا می‌کند، جواب کاربر را می‌دهد و بعد سرور را خاموش می‌کند!مزایای اصلی Serverless شامل کاهش پیچیدگی مدیریت زیرساخت، افزایش سرعت توسعه، مقیاس‌پذیری خودکار و کاهش هزینه‌های عملیاتی است. با این حال، چالش‌هایی مانند وابستگی به ارائه‌دهنده سرویس، محدودیت منابع و تأخیر اولیه اجرای سرویس‌ها (Cold Start) نیز وجود دارد.۱۱. API-First ApproachAPI-First یک رویکرد توسعه نرم‌افزار است که در آن طراحی و تعریف APIها پیش از پیاده‌سازی سایر بخش‌های سیستم انجام می‌شود. در این رویکرد، APIها به‌عنوان اجزای اصلی و پایه‌ای سیستم در نظر گرفته می‌شوند و سایر بخش‌ها مانند وب‌سایت، اپلیکیشن موبایل یا سرویس‌های دیگر بر اساس آن‌ها توسعه می‌یابند.در روش‌های سنتی، وقتی می‌خواستیم یک نرم‌افزار بسازیم، اول دیتابیس و کدهای بک‌اند را می‌نوشتیم، ظاهر برنامه را طراحی می‌کردیم و در آخر به سراغ APIها می‌رفتیم.اما رویکرد API-First دقیقاً برعکس است . این رویکرد می‌گوید: قبل از اینکه حتی یک خط کد برای برنامه بنویسید، اول باید روی طراحی، مستندسازی و ساختار مشخص API توافق کنید. در این مدل، API به عنوان یک «شهروند درجه یک» و پایه و اساس کل پروژه در نظر گرفته می‌شود. ما ابتدا یک «قرارداد» (Contract) با ابزارهایی مثل OpenAPI/Swagger می‌سازیم که می‌گوید سیستم قرار است چه ورودی و خروجی‌هایی داشته باشد، سپس همه تیم‌ها کارشان را بر اساس این قرارداد شروع می‌کنند.مزایای اصلی این رویکرد شامل توسعه سریع‌تر، قابلیت استفاده مجدد از سرویس‌ها، یکپارچگی بهتر بین سیستم‌ها، بهبود تجربه توسعه‌دهندگان و پشتیبانی مناسب از معماری‌های مدرن مانند میکروسرویس‌ها است. به همین دلیل API-First به یکی از رویکردهای رایج در توسعه سامانه‌های مدرن تبدیل شده است.۱۲. طراحی دامنه‌محور (Domain-Driven Design)Domain-Driven Design یا DDD یک رویکرد طراحی نرم‌افزار است که تمرکز اصلی آن بر درک عمیق حوزه کسب‌وکار (Domain) و مدل‌سازی نرم‌افزار بر اساس مفاهیم و قوانین آن حوزه است. در این رویکرد، توسعه‌دهندگان و متخصصان کسب‌وکار با استفاده از یک زبان مشترک (Ubiquitous Language) همکاری می‌کنند تا نرم‌افزار بیشترین تطابق را با نیازهای واقعی سازمان داشته باشد.بسیاری از پروژه‌های نرم‌افزاری به این دلیل شکست می‌خورند که برنامه‌نویسان بهترین تکنولوژی‌ها را استفاده کرده‌اند، اما دقیقاً نفهمیده‌اند که بیزینس یا همان دامنه کارفرما چطور کار می‌کند! به عنوان مثال شما نمی‌توانید یک سیستم بانکی عالی بسازید، مگر اینکه اول محاسبات پیچیده بانکی و قوانین آن را عمیقاً درک کنید.DDD می‌گوید که قلب فرآیند توسعه باید مدل‌سازی دقیق فرآیندها، قوانین و نیازمند‌ی‌های بیزینس باشد، نه مسائل فنی و دیتابیس. در این روش، برنامه‌نویسان و متخصصان بیزینس کنار هم می‌نشینند و یک زبان مشترک خلق می‌کنند. یعنی کلماتی که در کد استفاده می‌شود (مثل نام متغیرها و کلاس‌ها) باید دقیقاً همان کلماتی باشد که کارفرما در دنیای واقعی استفاده می‌کند.۱۳. معماری شش‌ضلعی (Hexagonal Architecture)معماری شش‌ضلعی یا Hexagonal Architecture یک روش طراحی نرم‌افزار است که هدفش جدا کردن منطق اصلی برنامه (Business Logic) از جزئیات فنی مثل دیتابیس، رابط کاربری و سرویس‌های بیرونی است. در این مدل، هسته‌ی برنامه در مرکز قرار دارد و همه چیز از طریق «پورت‌ها» و «آداپتورها» به آن وصل می‌شود.در معماری‌های سنتی (۳ لایه)، لایه بیزینس مستقیماً به لایه دیتابیس وصل است. این یعنی اگر بخواهید دیتابیس را عوض کنید یا پکیج جدیدی نص کنید، احتمالاً کدهای اصلی بیزینس شما دستخوش تغییر و باگ می‌شوند.اما معماری شش‌ضلعی می‌گوید: هسته اصلی برنامه باید مثل یک جزیره کاملاً مستقل در مرکز قرار بگیرد و هیچ ابزار خارجی (مثل دیتابیس، پنل وب، تلگرام بوت، یا APIهای دیگر) نباید به درون آن نفوذ کنند. هسته برنامه فقط تعدادی پورت (که در کد همان Interfaceها یا قراردادها هستند) معرفی می‌کند. ابزارهای بیرونی، آداپتور مخصوص خود را می‌نویسند تا به این پورت‌ها وصل شوند؛ درست مثل لپ‌تاپ شما که یک پورت USB (مستقل از تکنولوژی) دارد و شما می‌توانید هم موس، هم کیبورد و هم هارد اکسترنال را با آداپتورهایشان به آن وصل کنید، بدون اینکه ساختار داخلی لپ‌تاپ تغییر کند.۱۴. Event SourcingEvent Sourcing یک سبک معماری است که به جای اینکه فقط «وضعیت فعلی» سیستم را ذخیره کنیم، تمام تغییراتی که روی سیستم اتفاق می‌افتد را به شکل «رویداد» ذخیره می‌کند. یعنی به جای اینکه فقط بدانیم الان وضعیت چیست، دقیقاً می‌دانیم چه اتفاق‌هایی افتاده که ما را به این وضعیت رسانده است.در دیتابیس‌های سنتی (CRUD)، ما همیشه آخرین وضعیت یک داده را ذخیره می‌کنیم. مثلاً اگر موجودی حساب شما ۱۰۰ هزار تومان باشد و ۵۰ هزار تومان واریز کنید، عدد ۱۰۰ به ۱۵۰ تبدیل می‌شود. اگر کسی بپرسد «این ۱۵۰ هزار تومان چطور به دست آمده؟»، دیتابیس سنتی چیزی برای گفتن ندارد، مگر اینکه یک سیستم لاگ‌گیری جداگانه ساخته باشید.الگوی Event Sourcing می‌گوید: ما اصلاً وضعیت فعلی را ذخیره نمی‌کنیم؛ بلکه تمام اتفاقات و رویدادهایی که منجر به این وضعیت شده‌اند را به صورت یک زنجیره متوالی ذخیره می‌کنیم. در این معماری، دیتابیس ما یک بانک اطلاعاتی فقط‌افزودنی (Append-only) به نام Event Store است. برای به دست آوردن موجودی فعلی حساب، سیستم از نقطه صفر شروع می‌کند و تمام رویدادهای واریز و برداشت را از ابتدا تا انتها روی حساب بازیانی (Replay) می‌کند تا به عدد نهایی برسد. سیستم کنترل نسخه (مثل Git) یا دفتر کل حسابداری بهترین مثال‌های ملموس برای این الگو هستند؛ گیت کدهای نهایی را ذخیره نمی‌کند، بلکه تغییرات را نگه می‌دارد.مزیت مهم این روش این است که علاوه بر وضعیت فعلی، تاریخچه کامل هم داریم. بنابراین می‌توانیم بفهمیم چه زمانی چه اتفاقی افتاده، یا حتی وضعیت سیستم را در یک زمان خاص بازسازی کنیم. البته در عوض، طراحی و پیاده‌سازی آن پیچیده‌تر و سنگین‌تر از روش‌های سنتی است.۱۵. پلتفرم‌های Low-code/No-codeپلتفرم‌های Low-code و No-code ابزارهایی هستند که ساخت نرم‌افزار را خیلی ساده‌تر و سریع‌تر می‌کنند، طوری که لازم نیست مثل روش‌های سنتی همه‌چیز را خط‌به‌خط کدنویسی کنیم.این پلتفرم‌ها به کمک واسط‌های کاربری گرافیکی، ابزارهای کشیدن و رها کردن (Drag-and-Drop) و مدل‌سازی بصری به کاربران اجازه می‌دهند بدون درگیر شدن با پیچیدگی‌های کدنویسی، برنامه بسازند:No-Code: مخصوص افرادی است که اصلاً دانش برنامه‌نویسی ندارند. آن‌ها به کمک ابزارهای کاملاً بصری، کارهای خود را جلو می‌برند.Low-Code: به کمی دانش پایه برنامه‌نویسی نیاز دارد و به توسعه‌دهندگان حرفه‌ای کمک می‌کند تا کارهای تکراری (مثل ساخت فرم‌ها یا اتصال به دیتابیس) را با سرعت بالا (تا ۹۰٪ سریع‌تر) انجام دهند و فقط بخش‌های بسیار خاص را کدنویسی کنند.البته این ابزارها بیشتر برای اپلیکیشن‌های ساده تا متوسط مناسب‌اند (مثل داشبوردها، فرم‌ها یا اتوماسیون‌های ساده). برای سیستم‌های خیلی پیچیده هنوز به توسعه سنتی (Pro-code) نیاز داریم. به همین دلیل معمولاً این دو روش در کنار هم استفاده می‌شوند: Low-code برای سرعت، و Pro-code برای انعطاف و قدرت بیشتر.۱۶. سیستم‌های مدیریت فرآیند کسب‌وکار (BPMS)BPMS (مخفف Business Process Management Systems) یک نوع پلتفرم نرم‌افزاری است که کمک می‌کند فرآیندهای کاری یک سازمان را طراحی، اجرا، پایش و بهینه‌سازی کنیم. یعنی به جای اینکه کارها به‌صورت پراکنده و دستی انجام شوند، همه چیز به شکل یک جریان مشخص و قابل کنترل مدیریت می‌شود.در واقع BPM خودش «روش فکر کردن به فرآیندها» است، اما BPMS ابزار اجرایی آن است. این سیستم‌ها به سازمان کمک می‌کنند بفهمند کارها دقیقاً چطور انجام می‌شوند، کجاها گلوگاه وجود دارد و چطور می‌توان آن‌ها را بهتر کرد.BPMS معمولاً شامل طراحی فرآیند (Process Design)، اجرای گردش‌کار (Workflow Automation)، مانیتورینگ و تحلیل عملکرد است. بعضی نسخه‌های پیشرفته حتی اجازه می‌دهند فرآیندها قبل از اجرا شبیه‌سازی شوند تا مشکلات احتمالی دیده شود. مثلاً در یک شرکت، درخواست مرخصی، تأیید مدیر، ثبت در سیستم منابع انسانی و آرشیو شدن همه می‌تواند به صورت یک فرآیند در BPMS تعریف شود و سیستم خودش این مسیر را مدیریت کند.مزیت مهم BPMS این است که باعث شفافیت، کاهش کارهای تکراری، افزایش سرعت و کنترل بهتر روی فرآیندهای سازمانی می‌شود. در عین حال، چون همه چیز را ساختارمند می‌کند، سازمان راحت‌تر می‌تواند رشد کند و فرآیندها را توسعه دهد یا تغییر دهد.۱۷. Message QueueMessage Queue، یکی از ابزارهای مهم در معماری نرم‌افزارهای مدرن است که برای ارتباط غیرهم‌زمان بین بخش‌های مختلف سیستم استفاده می‌شود. ایده اصلی این است که به جای اینکه یک سرویس مستقیم منتظر پاسخ سرویس دیگر بماند، پیام‌ها را در یک صف قرار می‌دهد تا بعداً توسط سرویس‌های دیگر پردازش شوند.در این مدل، سه بخش اصلی داریم: فرستنده پیام (Producer) که کار یا درخواست را تولید می‌کند، صف پیام (Broker) که پیام‌ها را نگه‌داری و مدیریت می‌کند، و دریافت‌کننده (Consumer) که پیام‌ها را برداشته و پردازش می‌کند. ابزارهایی مثل Apache Kafka و RabbitMQ از معروف‌ترین نمونه‌ها هستند.به طور خلاصه، Message Queue مثل یک «ایستگاه پست دیجیتال» است که پیام‌ها را نگه می‌دارد تا هر سرویس در زمان مناسب آن‌ها را بردارد و پردازش کند، بدون اینکه همه چیز به هم وابسته باشد.۱۸. Containers and Container orchestrationکانتینرها یکی از مهم‌ترین فناوری‌های دنیای نرم‌افزار مدرن هستند که کمک می‌کنند برنامه‌ها همراه با تمام وابستگی‌هایشان (مثل کتابخانه‌ها و تنظیمات سیستم) در یک بسته‌ی مستقل اجرا شوند. این کار باعث می‌شود برنامه در هر سیستمی دقیقاً به یک شکل اجرا شود، بدون اینکه مشکل «روی سیستم من کار می‌کند ولی روی سیستم تو نه» پیش بیاید. Docker یکی از معروف‌ترین ابزارها برای ساخت و اجرای کانتینرها است. Docker به توسعه‌دهنده اجازه می‌دهد یک برنامه را داخل یک «ایمیج» بسته‌بندی کند و آن را روی هر سیستم اجرا کند.اما وقتی تعداد کانتینرها زیاد می‌شود (مثلاً صدها یا هزاران سرویس)، مدیریت آن‌ها سخت می‌شود. اینجاست که ابزارهایی مثل Kubernetes وارد می‌شوند. Kubernetes وظیفه دارد کانتینرها را در مقیاس بزرگ مدیریت کند، آن‌ها را بین سرورها پخش کند، در صورت خرابی دوباره اجرا کند و به صورت خودکار مقیاس (scale) سیستم را تنظیم کند.به زبان ساده:Docker = ساخت و اجرای کانتینرهاKubernetes = مدیریت و کنترل تعداد زیاد کانتینرها در یک سیستم بزرگبرای مثال، Docker مثل این است که یک «جعبه غذای آماده» درست کنیم، اما Kubernetes مثل سیستم مدیریت رستورانی است که هزاران سفارش را بین آشپزها تقسیم می‌کند، اگر یکی از آشپزها خراب شد جایگزین می‌آورد و در ساعات شلوغی تعداد آشپزها را زیاد می‌کند.در عمل، این دو معمولاً با هم استفاده می‌شوند: Docker برای ساخت و اجرای برنامه، و Kubernetes برای مدیریت آن در سطح بزرگ و حرفه‌ای.۱۹. معماری چندمستاجری (Multi-Tenancy Architecture)معماری Multi-Tenancy یا چندمستاجری به حالتی از طراحی نرم‌افزار گفته می‌شود که در آن یک نسخه (instance) از یک اپلیکیشن، به‌طور هم‌زمان به چندین مشتری یا گروه کاربری (tenant) سرویس می‌دهد. هر tenant می‌تواند یک فرد، یک شرکت یا یک سازمان باشد، اما نکته مهم این است که داده‌ها و تنظیمات هر کدام از هم جدا و ایزوله نگه داشته می‌شوند. فرض کنید یک مجتمع مسکونی بزرگ دارید. در این مجتمع، تمام ساکنین (مستاجرین) از یک زیرساخت مشترک (مثل اسکلت ساختمان، لوله‌کشی اصلی آب، آسانسور و ورودی مجتمع) استفاده می‌کنند، اما هر کدام واحد، کلید و حریم خصوصی کاملاً مستقل خود را دارند.در این معماری، همه کاربران از یک زیرساخت و یک اپلیکیشن مشترک استفاده می‌کنند، اما سیستم طوری طراحی شده که داده‌های هر tenant برای دیگران قابل مشاهده نیست. این موضوع هم باعث صرفه‌جویی در هزینه‌ها می‌شود و هم مدیریت سیستم را ساده‌تر می‌کند.اگر بخواهیم ساده بگوییم:در حالت Single-Tenant هر مشتری یک نسخه جدا از نرم‌افزار دارددر حالت Multi-Tenant همه مشتری‌ها روی یک نسخه مشترک هستند، اما از هم جدا نگه داشته می‌شوندمزیت مهم این مدل، کاهش هزینه، به‌روزرسانی ساده‌تر و مقیاس‌پذیری بهتر است. چون وقتی یک آپدیت داده می‌شود، برای همه مشتری‌ها هم‌زمان اعمال می‌شود.۲۰. مهاجرت داده‌ (Data Migration)Data Migration یا مهاجرت داده به فرآیند انتقال داده‌ها از یک سیستم به سیستم دیگر گفته می‌شود. این انتقال می‌تواند بین دیتابیس‌ها، نرم‌افزارها، سرورها، محیط‌های ابری یا حتی فرمت‌های مختلف فایل انجام شود. هدف اصلی این کار این است که داده‌ها به یک محیط جدید منتقل شوند بدون اینکه دقت، کامل بودن یا سازگاری آن‌ها از بین برود. وقتی یک سازمان تصمیم می‌گیرد سیستم‌های قدیمی خود را به‌روز کند، دیتابیس سنتی خود (مثلا SQL Server) را به ابر منتقل کند (مثلا روی Cloud)، یا دو شرکت با هم ادغام می‌شوند، نیاز به جابجایی داده‌ها دارند.در یک پروژه مهاجرت داده معمولاً سه مرحله اصلی داریم:اول انتخاب و آماده‌سازی داده‌ها (بررسی اینکه چه داده‌ای داریم و چه کیفیتی دارد)، دوم انتقال داده‌ها (جابجایی از سیستم قدیمی به جدید)، و سوم اعتبارسنجی (اطمینان از اینکه داده‌ها درست و کامل منتقل شده‌اند).چالش اصلی در Data Migration این است که داده‌ها معمولاً بسیار بزرگ، حساس و وابسته به سیستم‌های مختلف هستند. اگر کوچک‌ترین خطا در انتقال رخ دهد، ممکن است اطلاعات از بین برود یا سیستم جدید درست کار نکند. علی پاکدل علی پاکدل Mon, 01 Jun 2026 23:26:11 +0330 https://virgool.io/@aliipakdel98/%D9%85%D9%81%D8%A7%D9%87%DB%8C%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-isogzagydmqj ۱. مهندسی آشوب (Chaos Engineering)امروزه بسیاری از نرم‌افزارها و سرویس‌های آنلاین روی سیستم‌های پیچیده و توزیع‌شده اجرا می‌شوند. در چنین سیستم‌هایی ممکن است مشکلاتی مانند قطعی سرور، اختلال شبکه، افزایش ناگهانی کاربران یا خرابی بخشی از سیستم رخ دهد. مهندسی آشوب (Chaos Engineering) روشی است که به کمک آن این نوع خرابی‌ها به‌صورت عمدی و کنترل‌شده شبیه‌سازی می‌شوند تا مشخص شود سیستم در شرایط بحرانی چگونه عمل می‌کند.فرض کنید یک ماشین جدید ساخته‌اید. به جای اینکه منتظر بمانید تا در جاده و حین رانندگی تصادف کند، خودتان در پیست آزمایش با پتک به بدنه آن می‌کوبید یا ترمزها را دست‌کاری می‌کنید تا ببینید چقدر محکم است!مهندسی آشوب دقیقاً همین است. یعنی ما عمداً و در یک محیط کنترل‌شده، خرابکاری‌هایی (مثل قطع کردن یک سرور، شبیه‌سازی قطع اینترنت و یا پر کردن حافظه CPU) را وارد سیستم نرم‌افزاری خودمان می‌کنیم تا ببینیم آیا سیستم می‌تواند گلیم خودش را از آب بیرون بکشد و به کارش ادامه دهد یا کلاً منفجر می‌شود! هدف ما خرابکاری نیست، بلکه پیشگیری پیش‌دستانه (Proactive) از فاجعه است.به طور کلی، مهندسی آشوب به تیم‌های نرم‌افزاری کمک می‌کند تا قبل از وقوع بحران‌های واقعی، نقاط ضعف سیستم را شناسایی کرده و قابلیت اطمینان و تاب‌آوری نرم‌افزار را افزایش دهند.۲. بک‌اند برای فرانت‌اند (Backend for Frontend)Backend for Frontend یا به اختصار BFF یک الگوی معماری نرم‌افزار است که در آن برای هر نوع رابط کاربری یک بک‌اند اختصاصی در نظر گرفته می‌شود. ایده اصلی این است که نیازهای یک وب‌سایت، اپلیکیشن موبایل یا حتی یک دستگاه هوشمند با یکدیگر متفاوت هستند؛ بنابراین بهتر است هر کدام یک لایه بک‌اند مخصوص خود داشته باشند.در معماری‌های سنتی، همه فرانت‌اند‌ها مستقیماً با یک بک‌اند مشترک ارتباط برقرار می‌کنند. این موضوع باعث می‌شود بک‌اند مجبور باشد نیازهای مختلف و گاهی متناقض چندین نوع کاربر را پوشش دهد. در الگوی BFF، بین فرنت‌اند و سرویس‌های اصلی سیستم یک بک‌اند اختصاصی قرار می‌گیرد که فقط برای همان فرانت‌اند طراحی شده است.BFF یعنی ما به جای اینکه یک بک‌‌اند غول‌آسا داشته باشیم که سعی کند همه را راضی نگه دارد، برای هر کلاینت یک لایه بک‌‌اند اختصاصی و کوچک می‌سازیم. این لایه مانند یک «مترجم» عمل می‌کند که داده‌های خام را از میکروسرویس‌های اصلی می‌گیرد، آن‌ها را به شکلی که آن کلاینت خاص نیاز دارد فیلتر یا ترکیب می‌کند و تحویل می‌دهد.۳. هوش‌مصنوعی برای مهندسی نرم‌افزار (AI4SE)با پیچیده‌تر شدن سیستم‌های امروزی و کم شدن زمان عرضه به بازار، مهندسان نیاز به ابزارهای کمکی دارند. در اینجا اصطلاح AI4SE (مخفف AI for Systems Engineering) متولد می‌شود. به زبان ساده، در AI4SE از ابزارها و تکنیک‌های هوش مصنوعی (مثل یادگیری ماشین و پردازش داده‌ها) استفاده می‌شود تا فرآیند طراحی، ساخت، تست و نگهداری سیستم‌های پیچیده نرم‌افزاری را بهبود، سرعت و بهینه‌سازی ببخشد.در AI4SE از هوش مصنوعی برای انجام یا تسهیل کارهایی مانند تولید کد، یافتن خطاها، تولید تست، تحلیل نیازمندی‌ها و پیش‌بینی مشکلات احتمالی استفاده می‌شود. به این ترتیب، بخشی از کارهایی که قبلاً به‌صورت دستی انجام می‌شد، می‌تواند به کمک ابزارهای هوشمند سریع‌تر و دقیق‌تر انجام شود.۴. مهندسی‌ سیستم برای هوش‌مصنوعی (SE4AI)اگر در موضوع قبلی (AI4SE) از هوش مصنوعی به عنوان دستیار استفاده می‌کردیم، در SE4AI (مخفف Systems Engineering for AI) ورق کاملاً برمی‌گردد. در اینجا ما می‌خواهیم یک سیستم نرم‌افزاری بسازیم که خودش یک بخش هوش مصنوعی یا یادگیری ماشین در دلش دارد؛ مثلاً یک ماشین خودران، یک سیستم تشخیص پزشکی یا ابزار هوشمند بورس.سیستم‌های هوش مصنوعی معمولاً پیچیده‌تر از نرم‌افزارهای سنتی هستند؛ زیرا علاوه بر کد، شامل داده‌ها، مدل‌های یادگیری ماشین و فرآیندهای آموزش و به‌روزرسانی نیز می‌شوند. به همین دلیل، برای اطمینان از کیفیت، امنیت، قابلیت اطمینان و عملکرد صحیح این سیستم‌ها، باید از اصول مهندسی نرم‌افزار استفاده شود.تفاوت SE4AI با AI4SE در این است که در AI4SE، هوش مصنوعی به مهندسی نرم‌افزار کمک می‌کند؛ اما در SE4AI، مهندسی نرم‌افزار به ساخت و مدیریت سیستم‌های هوش مصنوعی کمک می‌کند.۵. عملیات یادگیری ماشین (MLOps)در دنیای مهندسی نرم‌افزار، ما سال‌هاست که از DevOps استفاده می‌کنیم تا فرآیند نوشتن کد و قرار دادن آن روی سرور را خودکار و سریع کنیم. اما وقتی پای یادگیری ماشین (Machine Learning) به میان می‌آید، قضیه خیلی پیچیده‌تر می‌شود؛ چون ما اینجا فقط با «کد» سروکار نداریم، بلکه با «کد + داده‌ها + مدل ریاضی» طرف هستیم.MLOps (مخفف Machine Learning Operations) مجموعه‌ای از روش‌ها و ابزارهاست که فرهنگ DevOps را وارد دنیای یادگیری ماشین می‌کند. هدف MLOps این است که چرخه حیات یک مدل هوش مصنوعی (از آماده‌سازی داده‌ها و آموزش مدل گرفته تا تست، ارزیابی، مستقر کردن روی سرور و پایش آن) را کاملاً خودکار و استاندارد کند تا مدل‌ها سریع‌تر و با خطای کمتر به دست کاربران برسند.در پروژه‌های یادگیری ماشین، تنها ساخت مدل کافی نیست. داده‌ها باید جمع‌آوری و آماده شوند، مدل آموزش ببیند، آزمایش شود، در محیط واقعی مستقر گردد و عملکرد آن به‌طور مداوم پایش شود. انجام دستی این مراحل زمان‌بر و پرخطا است. MLOps با استفاده از خودکارسازی، کنترل نسخه، CI/CD و پایش مداوم، این فرآیندها را ساده‌تر و قابل اعتمادتر می‌کند. از مهم‌ترین مزایای MLOps می‌توان به کاهش زمان استقرار مدل، افزایش همکاری بین تیم‌های داده و توسعه، بهبود کیفیت مدل‌ها و کاهش هزینه‌های نگهداری اشاره کرد.۶. زیرساخت به عنوان کد (IaC)Infrastructure as Code یا IaC روشی برای مدیریت و پیکربندی زیرساخت‌های فناوری اطلاعات از طریق کد است. در این رویکرد، به جای اینکه سرورها، شبکه‌ها، پایگاه‌های داده و سایر منابع به‌صورت دستی تنظیم شوند، تمام تنظیمات و مشخصات زیرساخت در قالب فایل‌های کد تعریف می‌شوند.IaC به زبان ساده‌تر می‌گوید که به جای کارهای دستی، بیایید کل ساختار زیرساخت (مثل سرورها، شبکه‌ها، لود بالانسرها و دیتابیس‌ها) را در قالب فایل‌های متنی و کد بنویسیم. ابزارهای IaC این کدها را می‌خوانند و خودکار در چند دقیقه دقیقاً همان محیطی که خواسته‌ایم را در کلود (مثل AWS یا سرورهای محلی) برای ما می‌سازند. با این کار، مدیریت زیرساخت دقیقاً مثل مدیریت کدهای یک نرم‌افزار می‌شود.مهم‌ترین مزیت IaC ایجاد یکپارچگی و تکرارپذیری است. وقتی زیرساخت از طریق کد تعریف شود، محیط‌های توسعه، تست و عملیاتی دقیقاً مشابه یکدیگر خواهند بود و مشکل «تفاوت محیط‌ها» به حداقل می‌رسد. همچنین استفاده از کنترل نسخه (Version Control) باعث می‌شود تغییرات زیرساخت قابل پیگیری و بازگشت باشند.۷. API Gateway & Service Meshدر معماری Microservices، دو فناوری مهم برای مدیریت ارتباطات وجود دارند: API Gateway و Service Mesh. این دو مفهوم گاهی شبیه به هم به نظر می‌رسند، اما وظایف متفاوتی دارند و معمولاً در کنار یکدیگر استفاده می‌شوند. وقتی یک معماری یکپارچه (Monolith) را می‌شکنیم و به کلی میکروسرویس کوچک تبدیل می‌شود، دو چالش بزرگ ارتباطی داریم:۱. کلاینت‌های بیرونی (مثل اپلیکیشن موبایل کاربر) چطور باید با این همه سرویس داخلی صحبت کنند؟۲. این میکروسرویس‌های داخلی چطور خودشان با یکدیگر امن و سریع ارتباط برقرار کنند؟برای حل این دو چالش، دو تکنولوژی متفاوت اما مکمل داریم: API Gateway و Service Mesh.API Gateway در ورودی سیستم قرار می‌گیرد و تمام درخواست‌های کاربران یا سیستم‌های خارجی را دریافت می‌کند. این لایه وظایفی مانند مسیریابی درخواست‌ها، احراز هویت، محدودسازی تعداد درخواست‌ها (Rate Limiting)، مدیریت نسخه‌های API و نظارت بر ترافیک را انجام می‌دهد. به بیان ساده، API Gateway دروازه ورود به سیستم است.در مقابل، Service Mesh برای مدیریت ارتباط بین سرویس‌های داخلی یک معماری میکروسرویسی استفاده می‌شود. این فناوری ارتباط سرویس‌ها با یکدیگر را کنترل می‌کند و قابلیت‌هایی مانند کشف سرویس‌ها، توازن بار (Load Balancing)، رمزنگاری ارتباطات، مانیتورینگ و مدیریت خطاها را فراهم می‌کند.۸. تفکیک مسئولیت دستور و پرس‌وجو (CQRS)CQRS (مخفف Command Query Responsibility Segregation) یا تفکیک مسئولیت فرمان و پرس‌وجو یک الگوی معماری نرم‌افزار است که عملیات خواندن اطلاعات (Query) را از عملیات نوشتن و تغییر اطلاعات (Command) جدا می‌کند. در این الگو، به جای استفاده از یک مدل مشترک برای خواندن و نوشتن داده‌ها، برای هر کدام مدل یا حتی پایگاه داده جداگانه در نظر گرفته می‌شود.در معماری‌های سنتی (CRUD)، یک مدل واحد هم برای خواندن و هم برای تغییر داده‌ها استفاده می‌شود. اما در سیستم‌های پیچیده، نیازهای بخش خواندن و نوشتن معمولاً متفاوت هستند. برای مثال، در یک فروشگاه اینترنتی، ممکن است ثبت سفارش (نوشتن) نیاز به پردازش تراکنش سنگین داشته باشد، اما کاربران هم‌زمان هزاران بار لیست محصولات (خواندن) را لود کنند. استفاده از یک مدل برای هر دو کار، کارایی سیستم را پایین می‌آورد.مزیت اصلی CQRS افزایش کارایی، مقیاس‌پذیری و انعطاف‌پذیری سیستم است. با این حال، پیاده‌سازی آن پیچیدگی بیشتری نسبت به معماری‌های معمولی دارد و معمولاً برای سیستم‌های بزرگ و پیچیده توصیه می‌شود.۹.معماری رویداد-محور (EDA)EDA (مخفف Event-Driven Architecture) یا معماری رویدادمحور یک الگوی معماری نرم‌افزار است که در آن اجزای سیستم از طریق رویدادها (Events) با یکدیگر ارتباط برقرار می‌کنند. رویداد به هر اتفاق مهمی در سیستم گفته می‌شود؛ مانند ثبت سفارش، پرداخت موفق، ورود کاربر یا تغییر وضعیت یک محصول.در معماری‌های سنتی، سیستم‌ها به صورت هم‌گام (Synchronous) با هم صحبت می‌کنند؛ یعنی سیستم A به سیستم B زنگ می‌زند و منتظر می‌ماند تا جواب را بگیرد. اگر سیستم B قطع باشد، کار سیستم A هم لنگ می‌ماند.اما معماری رویداد-محور (EDA) می‌گوید: سیستم‌ها باید به صورت ناهم‌گام (Asynchronous) و بر پایه رویدادها با هم ارتباط داشته باشند. رویداد یعنی «یک اتفاق مهم که در سیستم رخ داده و تمام شده است»؛ مثلاً: «کاربر دکمه خرید را زد»، «دمای سنسور به ۱۸۰ درجه رسید» یا «پرداخت موفقیت‌آمیز بود».در این معماری، فرستنده (Producer) رویداد کاری ندارد که چه کسی قرار است این پیام را بگیرد؛ او فقط رویداد را داخل یک تالار گفتگو ارسال می‌کند. گیرندگان رویداد (Consumers) که گوش‌به‌زنگ نشسته‌اند، هر زمان که آمادگی داشتند این پیام را برمی‌دارند و کار خودشان را انجام می‌دهند. فرستنده و گیرنده اصلاً همدیگر را نمی‌شناسند.۱۰. معماری بدون سرور (Serverless Architecture)Serverless Architecture یک سبک معماری است که در آن توسعه‌دهندگان بدون مدیریت مستقیم سرورها، برنامه‌های خود را توسعه و اجرا می‌کنند. در این مدل، تأمین، نگهداری، مقیاس‌پذیری و مدیریت زیرساخت بر عهده ارائه‌دهنده خدمات ابری است و توسعه‌دهندگان تنها روی منطق و کدنویسی برنامه تمرکز می‌کنند.بزرگ‌ترین اشتباه در کلمه Serverless این است که فکر کنیم «هیچ سروری در کار نیست!». در واقع، سرورها وجود دارند، اما دلیل این نام‌گذاری این است که شما به عنوان یک توسعه‌دهنده یا معمار نرم‌افزار، هیچ نیازی به دیدن، مدیریت، آپدیت یا خرید سرورها ندارید. در معماری سنتی، شما باید یک سرور مجازی اجاره می‌کردید، سیستم‌عاملش را آپدیت می‌کردید و نگران می‌شدید که اگر ترافیک بالا رفت سرور کرش نکند. اما در معماری بدون سرور، کل این دردسرها به عهده شرکت ارائه‌دهنده خدمات ابری (مثل آمازون، گوگل یا مایکروسافت) است. شما فقط کد خود را می‌نویسید و آپلود می‌کنید؛ سیستم ابری خودش به ازای هر درخواستی که سمت برنامه می‌آید، موقتاً یک سرور روشن می‌کند، کد شما را اجرا می‌کند، جواب کاربر را می‌دهد و بعد سرور را خاموش می‌کند!مزایای اصلی Serverless شامل کاهش پیچیدگی مدیریت زیرساخت، افزایش سرعت توسعه، مقیاس‌پذیری خودکار و کاهش هزینه‌های عملیاتی است. با این حال، چالش‌هایی مانند وابستگی به ارائه‌دهنده سرویس، محدودیت منابع و تأخیر اولیه اجرای سرویس‌ها (Cold Start) نیز وجود دارد.۱۱. API-First ApproachAPI-First یک رویکرد توسعه نرم‌افزار است که در آن طراحی و تعریف APIها پیش از پیاده‌سازی سایر بخش‌های سیستم انجام می‌شود. در این رویکرد، APIها به‌عنوان اجزای اصلی و پایه‌ای سیستم در نظر گرفته می‌شوند و سایر بخش‌ها مانند وب‌سایت، اپلیکیشن موبایل یا سرویس‌های دیگر بر اساس آن‌ها توسعه می‌یابند.در روش‌های سنتی، وقتی می‌خواستیم یک نرم‌افزار بسازیم، اول دیتابیس و کدهای بک‌اند را می‌نوشتیم، ظاهر برنامه را طراحی می‌کردیم و در آخر به سراغ APIها می‌رفتیم.اما رویکرد API-First دقیقاً برعکس است . این رویکرد می‌گوید: قبل از اینکه حتی یک خط کد برای برنامه بنویسید، اول باید روی طراحی، مستندسازی و ساختار مشخص API توافق کنید. در این مدل، API به عنوان یک «شهروند درجه یک» و پایه و اساس کل پروژه در نظر گرفته می‌شود. ما ابتدا یک «قرارداد» (Contract) با ابزارهایی مثل OpenAPI/Swagger می‌سازیم که می‌گوید سیستم قرار است چه ورودی و خروجی‌هایی داشته باشد، سپس همه تیم‌ها کارشان را بر اساس این قرارداد شروع می‌کنند.مزایای اصلی این رویکرد شامل توسعه سریع‌تر، قابلیت استفاده مجدد از سرویس‌ها، یکپارچگی بهتر بین سیستم‌ها، بهبود تجربه توسعه‌دهندگان و پشتیبانی مناسب از معماری‌های مدرن مانند میکروسرویس‌ها است. به همین دلیل API-First به یکی از رویکردهای رایج در توسعه سامانه‌های مدرن تبدیل شده است.۱۲. طراحی دامنه‌محور (Domain-Driven Design)Domain-Driven Design یا DDD یک رویکرد طراحی نرم‌افزار است که تمرکز اصلی آن بر درک عمیق حوزه کسب‌وکار (Domain) و مدل‌سازی نرم‌افزار بر اساس مفاهیم و قوانین آن حوزه است. در این رویکرد، توسعه‌دهندگان و متخصصان کسب‌وکار با استفاده از یک زبان مشترک (Ubiquitous Language) همکاری می‌کنند تا نرم‌افزار بیشترین تطابق را با نیازهای واقعی سازمان داشته باشد.بسیاری از پروژه‌های نرم‌افزاری به این دلیل شکست می‌خورند که برنامه‌نویسان بهترین تکنولوژی‌ها را استفاده کرده‌اند، اما دقیقاً نفهمیده‌اند که بیزینس یا همان دامنه کارفرما چطور کار می‌کند! به عنوان مثال شما نمی‌توانید یک سیستم بانکی عالی بسازید، مگر اینکه اول محاسبات پیچیده بانکی و قوانین آن را عمیقاً درک کنید.DDD می‌گوید که قلب فرآیند توسعه باید مدل‌سازی دقیق فرآیندها، قوانین و نیازمند‌ی‌های بیزینس باشد، نه مسائل فنی و دیتابیس. در این روش، برنامه‌نویسان و متخصصان بیزینس کنار هم می‌نشینند و یک زبان مشترک خلق می‌کنند. یعنی کلماتی که در کد استفاده می‌شود (مثل نام متغیرها و کلاس‌ها) باید دقیقاً همان کلماتی باشد که کارفرما در دنیای واقعی استفاده می‌کند.۱۳. معماری شش‌ضلعی (Hexagonal Architecture)معماری شش‌ضلعی یا Hexagonal Architecture یک روش طراحی نرم‌افزار است که هدفش جدا کردن منطق اصلی برنامه (Business Logic) از جزئیات فنی مثل دیتابیس، رابط کاربری و سرویس‌های بیرونی است. در این مدل، هسته‌ی برنامه در مرکز قرار دارد و همه چیز از طریق «پورت‌ها» و «آداپتورها» به آن وصل می‌شود.در معماری‌های سنتی (۳ لایه)، لایه بیزینس مستقیماً به لایه دیتابیس وصل است. این یعنی اگر بخواهید دیتابیس را عوض کنید یا پکیج جدیدی نص کنید، احتمالاً کدهای اصلی بیزینس شما دستخوش تغییر و باگ می‌شوند.اما معماری شش‌ضلعی می‌گوید: هسته اصلی برنامه باید مثل یک جزیره کاملاً مستقل در مرکز قرار بگیرد و هیچ ابزار خارجی (مثل دیتابیس، پنل وب، تلگرام بوت، یا APIهای دیگر) نباید به درون آن نفوذ کنند. هسته برنامه فقط تعدادی پورت (که در کد همان Interfaceها یا قراردادها هستند) معرفی می‌کند. ابزارهای بیرونی، آداپتور مخصوص خود را می‌نویسند تا به این پورت‌ها وصل شوند؛ درست مثل لپ‌تاپ شما که یک پورت USB (مستقل از تکنولوژی) دارد و شما می‌توانید هم موس، هم کیبورد و هم هارد اکسترنال را با آداپتورهایشان به آن وصل کنید، بدون اینکه ساختار داخلی لپ‌تاپ تغییر کند.۱۴. Event SourcingEvent Sourcing یک سبک معماری است که به جای اینکه فقط «وضعیت فعلی» سیستم را ذخیره کنیم، تمام تغییراتی که روی سیستم اتفاق می‌افتد را به شکل «رویداد» ذخیره می‌کند. یعنی به جای اینکه فقط بدانیم الان وضعیت چیست، دقیقاً می‌دانیم چه اتفاق‌هایی افتاده که ما را به این وضعیت رسانده است.در دیتابیس‌های سنتی (CRUD)، ما همیشه آخرین وضعیت یک داده را ذخیره می‌کنیم. مثلاً اگر موجودی حساب شما ۱۰۰ هزار تومان باشد و ۵۰ هزار تومان واریز کنید، عدد ۱۰۰ به ۱۵۰ تبدیل می‌شود. اگر کسی بپرسد «این ۱۵۰ هزار تومان چطور به دست آمده؟»، دیتابیس سنتی چیزی برای گفتن ندارد، مگر اینکه یک سیستم لاگ‌گیری جداگانه ساخته باشید.الگوی Event Sourcing می‌گوید: ما اصلاً وضعیت فعلی را ذخیره نمی‌کنیم؛ بلکه تمام اتفاقات و رویدادهایی که منجر به این وضعیت شده‌اند را به صورت یک زنجیره متوالی ذخیره می‌کنیم. در این معماری، دیتابیس ما یک بانک اطلاعاتی فقط‌افزودنی (Append-only) به نام Event Store است. برای به دست آوردن موجودی فعلی حساب، سیستم از نقطه صفر شروع می‌کند و تمام رویدادهای واریز و برداشت را از ابتدا تا انتها روی حساب بازیانی (Replay) می‌کند تا به عدد نهایی برسد. سیستم کنترل نسخه (مثل Git) یا دفتر کل حسابداری بهترین مثال‌های ملموس برای این الگو هستند؛ گیت کدهای نهایی را ذخیره نمی‌کند، بلکه تغییرات را نگه می‌دارد.مزیت مهم این روش این است که علاوه بر وضعیت فعلی، تاریخچه کامل هم داریم. بنابراین می‌توانیم بفهمیم چه زمانی چه اتفاقی افتاده، یا حتی وضعیت سیستم را در یک زمان خاص بازسازی کنیم. البته در عوض، طراحی و پیاده‌سازی آن پیچیده‌تر و سنگین‌تر از روش‌های سنتی است.۱۵. پلتفرم‌های Low-code/No-codeپلتفرم‌های Low-code و No-code ابزارهایی هستند که ساخت نرم‌افزار را خیلی ساده‌تر و سریع‌تر می‌کنند، طوری که لازم نیست مثل روش‌های سنتی همه‌چیز را خط‌به‌خط کدنویسی کنیم.این پلتفرم‌ها به کمک واسط‌های کاربری گرافیکی، ابزارهای کشیدن و رها کردن (Drag-and-Drop) و مدل‌سازی بصری به کاربران اجازه می‌دهند بدون درگیر شدن با پیچیدگی‌های کدنویسی، برنامه بسازند:No-Code: مخصوص افرادی است که اصلاً دانش برنامه‌نویسی ندارند. آن‌ها به کمک ابزارهای کاملاً بصری، کارهای خود را جلو می‌برند.Low-Code: به کمی دانش پایه برنامه‌نویسی نیاز دارد و به توسعه‌دهندگان حرفه‌ای کمک می‌کند تا کارهای تکراری (مثل ساخت فرم‌ها یا اتصال به دیتابیس) را با سرعت بالا (تا ۹۰٪ سریع‌تر) انجام دهند و فقط بخش‌های بسیار خاص را کدنویسی کنند.البته این ابزارها بیشتر برای اپلیکیشن‌های ساده تا متوسط مناسب‌اند (مثل داشبوردها، فرم‌ها یا اتوماسیون‌های ساده). برای سیستم‌های خیلی پیچیده هنوز به توسعه سنتی (Pro-code) نیاز داریم. به همین دلیل معمولاً این دو روش در کنار هم استفاده می‌شوند: Low-code برای سرعت، و Pro-code برای انعطاف و قدرت بیشتر.۱۶. سیستم‌های مدیریت فرآیند کسب‌وکار (BPMS)BPMS (مخفف Business Process Management Systems) یک نوع پلتفرم نرم‌افزاری است که کمک می‌کند فرآیندهای کاری یک سازمان را طراحی، اجرا، پایش و بهینه‌سازی کنیم. یعنی به جای اینکه کارها به‌صورت پراکنده و دستی انجام شوند، همه چیز به شکل یک جریان مشخص و قابل کنترل مدیریت می‌شود.در واقع BPM خودش «روش فکر کردن به فرآیندها» است، اما BPMS ابزار اجرایی آن است. این سیستم‌ها به سازمان کمک می‌کنند بفهمند کارها دقیقاً چطور انجام می‌شوند، کجاها گلوگاه وجود دارد و چطور می‌توان آن‌ها را بهتر کرد.BPMS معمولاً شامل طراحی فرآیند (Process Design)، اجرای گردش‌کار (Workflow Automation)، مانیتورینگ و تحلیل عملکرد است. بعضی نسخه‌های پیشرفته حتی اجازه می‌دهند فرآیندها قبل از اجرا شبیه‌سازی شوند تا مشکلات احتمالی دیده شود. مثلاً در یک شرکت، درخواست مرخصی، تأیید مدیر، ثبت در سیستم منابع انسانی و آرشیو شدن همه می‌تواند به صورت یک فرآیند در BPMS تعریف شود و سیستم خودش این مسیر را مدیریت کند.مزیت مهم BPMS این است که باعث شفافیت، کاهش کارهای تکراری، افزایش سرعت و کنترل بهتر روی فرآیندهای سازمانی می‌شود. در عین حال، چون همه چیز را ساختارمند می‌کند، سازمان راحت‌تر می‌تواند رشد کند و فرآیندها را توسعه دهد یا تغییر دهد.۱۷. Message QueueMessage Queue، یکی از ابزارهای مهم در معماری نرم‌افزارهای مدرن است که برای ارتباط غیرهم‌زمان بین بخش‌های مختلف سیستم استفاده می‌شود. ایده اصلی این است که به جای اینکه یک سرویس مستقیم منتظر پاسخ سرویس دیگر بماند، پیام‌ها را در یک صف قرار می‌دهد تا بعداً توسط سرویس‌های دیگر پردازش شوند.در این مدل، سه بخش اصلی داریم: فرستنده پیام (Producer) که کار یا درخواست را تولید می‌کند، صف پیام (Broker) که پیام‌ها را نگه‌داری و مدیریت می‌کند، و دریافت‌کننده (Consumer) که پیام‌ها را برداشته و پردازش می‌کند. ابزارهایی مثل Apache Kafka و RabbitMQ از معروف‌ترین نمونه‌ها هستند.به طور خلاصه، Message Queue مثل یک «ایستگاه پست دیجیتال» است که پیام‌ها را نگه می‌دارد تا هر سرویس در زمان مناسب آن‌ها را بردارد و پردازش کند، بدون اینکه همه چیز به هم وابسته باشد.۱۸. Containers and Container orchestrationکانتینرها یکی از مهم‌ترین فناوری‌های دنیای نرم‌افزار مدرن هستند که کمک می‌کنند برنامه‌ها همراه با تمام وابستگی‌هایشان (مثل کتابخانه‌ها و تنظیمات سیستم) در یک بسته‌ی مستقل اجرا شوند. این کار باعث می‌شود برنامه در هر سیستمی دقیقاً به یک شکل اجرا شود، بدون اینکه مشکل «روی سیستم من کار می‌کند ولی روی سیستم تو نه» پیش بیاید. Docker یکی از معروف‌ترین ابزارها برای ساخت و اجرای کانتینرها است. Docker به توسعه‌دهنده اجازه می‌دهد یک برنامه را داخل یک «ایمیج» بسته‌بندی کند و آن را روی هر سیستم اجرا کند.اما وقتی تعداد کانتینرها زیاد می‌شود (مثلاً صدها یا هزاران سرویس)، مدیریت آن‌ها سخت می‌شود. اینجاست که ابزارهایی مثل Kubernetes وارد می‌شوند. Kubernetes وظیفه دارد کانتینرها را در مقیاس بزرگ مدیریت کند، آن‌ها را بین سرورها پخش کند، در صورت خرابی دوباره اجرا کند و به صورت خودکار مقیاس (scale) سیستم را تنظیم کند.به زبان ساده:Docker = ساخت و اجرای کانتینرهاKubernetes = مدیریت و کنترل تعداد زیاد کانتینرها در یک سیستم بزرگبرای مثال، Docker مثل این است که یک «جعبه غذای آماده» درست کنیم، اما Kubernetes مثل سیستم مدیریت رستورانی است که هزاران سفارش را بین آشپزها تقسیم می‌کند، اگر یکی از آشپزها خراب شد جایگزین می‌آورد و در ساعات شلوغی تعداد آشپزها را زیاد می‌کند.در عمل، این دو معمولاً با هم استفاده می‌شوند: Docker برای ساخت و اجرای برنامه، و Kubernetes برای مدیریت آن در سطح بزرگ و حرفه‌ای.۱۹. معماری چندمستاجری (Multi-Tenancy Architecture)معماری Multi-Tenancy یا چندمستاجری به حالتی از طراحی نرم‌افزار گفته می‌شود که در آن یک نسخه (instance) از یک اپلیکیشن، به‌طور هم‌زمان به چندین مشتری یا گروه کاربری (tenant) سرویس می‌دهد. هر tenant می‌تواند یک فرد، یک شرکت یا یک سازمان باشد، اما نکته مهم این است که داده‌ها و تنظیمات هر کدام از هم جدا و ایزوله نگه داشته می‌شوند. فرض کنید یک مجتمع مسکونی بزرگ دارید. در این مجتمع، تمام ساکنین (مستاجرین) از یک زیرساخت مشترک (مثل اسکلت ساختمان، لوله‌کشی اصلی آب، آسانسور و ورودی مجتمع) استفاده می‌کنند، اما هر کدام واحد، کلید و حریم خصوصی کاملاً مستقل خود را دارند.در این معماری، همه کاربران از یک زیرساخت و یک اپلیکیشن مشترک استفاده می‌کنند، اما سیستم طوری طراحی شده که داده‌های هر tenant برای دیگران قابل مشاهده نیست. این موضوع هم باعث صرفه‌جویی در هزینه‌ها می‌شود و هم مدیریت سیستم را ساده‌تر می‌کند.اگر بخواهیم ساده بگوییم:در حالت Single-Tenant هر مشتری یک نسخه جدا از نرم‌افزار دارددر حالت Multi-Tenant همه مشتری‌ها روی یک نسخه مشترک هستند، اما از هم جدا نگه داشته می‌شوندمزیت مهم این مدل، کاهش هزینه، به‌روزرسانی ساده‌تر و مقیاس‌پذیری بهتر است. چون وقتی یک آپدیت داده می‌شود، برای همه مشتری‌ها هم‌زمان اعمال می‌شود.۲۰. مهاجرت داده‌ (Data Migration)Data Migration یا مهاجرت داده به فرآیند انتقال داده‌ها از یک سیستم به سیستم دیگر گفته می‌شود. این انتقال می‌تواند بین دیتابیس‌ها، نرم‌افزارها، سرورها، محیط‌های ابری یا حتی فرمت‌های مختلف فایل انجام شود. هدف اصلی این کار این است که داده‌ها به یک محیط جدید منتقل شوند بدون اینکه دقت، کامل بودن یا سازگاری آن‌ها از بین برود. وقتی یک سازمان تصمیم می‌گیرد سیستم‌های قدیمی خود را به‌روز کند، دیتابیس سنتی خود (مثلا SQL Server) را به ابر منتقل کند (مثلا روی Cloud)، یا دو شرکت با هم ادغام می‌شوند، نیاز به جابجایی داده‌ها دارند.در یک پروژه مهاجرت داده معمولاً سه مرحله اصلی داریم:اول انتخاب و آماده‌سازی داده‌ها (بررسی اینکه چه داده‌ای داریم و چه کیفیتی دارد)، دوم انتقال داده‌ها (جابجایی از سیستم قدیمی به جدید)، و سوم اعتبارسنجی (اطمینان از اینکه داده‌ها درست و کامل منتقل شده‌اند).چالش اصلی در Data Migration این است که داده‌ها معمولاً بسیار بزرگ، حساس و وابسته به سیستم‌های مختلف هستند. اگر کوچک‌ترین خطا در انتقال رخ دهد، ممکن است اطلاعات از بین برود یا سیستم جدید درست کار نکند. علی پاکدل علی پاکدل Mon, 01 Jun 2026 23:20:49 +0330