خواندن ۱۹ دقیقه·۶ روز پیش

آشنایی با ۲۰ مفهوم مهم در معماری نرم‌ افزار مدرن

در معماری نرم افزار، صرفا دانستن برنامه نویسی یا کار با یک زبان خاص کافی نیست چون زمانی که یک سیستم نرم افزاری بزرگتر می شود، موضوعاتی مثل مقیاس پذیری، نگهداری، امنیت، استقرار، ارتباط بین سرویس ها، مدیریت داده، کیفیت سرویس و هماهنگی بین تیم ها و سایر موارد اهمیت زیادی پیدا می کنند. مفاهیمی که در اینجا بررسی می شوند، بیشتر به همین بخش های پیشرفته تر و عملی تر مربوط هستند؛ یعنی جاهایی که نرم افزار از یک برنامه ساده خارج می شود و به یک سیستم واقعی، توزیع شده، قابل توسعه و قابل بهره برداری تبدیل می شود.

هدف از توضیح این مفاهیم این است که یک شناخت اولیه و کاربردی نسبت به اصطلاحاتی داشته باشیم که در پروژه های نرم افزاری مدرن زیاد شنیده می شوند. ممکن است در آینده هنگام طراحی یک سیستم، کار در یک تیم نرم افزاری، مطالعه مستندات فنی یا حتی تحلیل یک معماری موجود، با این واژه ها رو به رو شویم. بنابراین لازم نیست در این مرحله متخصص کامل هر موضوع باشیم، اما باید بتوانیم مفهوم کلی، کاربرد، مزایا، محدودیت ها و جایگاه هر کدام را در معماری نرم افزار درک کنیم. این تمرین کمک می کند دید ما از نرم افزار فقط در سطح کد و پیاده سازی باقی نماند و بتوانیم نرم افزار را به عنوان یک سیستم کامل شامل طراحی، زیرساخت، عملیات، داده و نیازهای کسب و کار ببینیم.

1. Chaos Engineering

اگر بخواهم Chaos Engineering را خیلی ساده توضیح بدهم، می گویم این رویکرد یعنی ما به صورت کنترل شده و آگاهانه به سیستم فشار می آوریم تا بفهمیم در دنیای واقعی چقدر مقاوم است. ایده اصلی این نیست که سیستم را بی هدف خراب کنیم، بلکه هدف این است که با اجرای آزمایش روی یک سامانه توزیع شده، به قابلیت آن برای تحمل شرایط آشفته، غیر منتظره و نامطلوب اعتماد پیدا کنیم.

در این رویکرد، ابتدا باید رفتار پایدار سیستم مشخص شود سپس باید فرضیه ای بسازیم که سیستم در شرایط نامطلوب نیز بتواند همان رفتار پایدار را حفظ کند. بعد از آن، رخداد هایی نزدیک به دنیای واقعی، مانند افزایش تأخیر شبکه، قطع یک وابستگی، از کار افتادن نمونه های اجرایی یا افزایش ناگهانی بار، شبیه سازی می شوند.

در واقع ما عمداً و کنترل شده در سیستم اختلال ایجاد کنیم تا ببینیم سیستم در شرایط خراب و غیر منتظره چقدر مقاوم است.

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

مثلاً فرض کنیم یک فروشگاه اینترنتی داریم. اگر سرویس پرداخت برای چند دقیقه قطع شود، آیا کل سایت از کار می افتد؟ یا فقط بخش پرداخت خطا می دهد و بقیه سایت همچنان کار می کند؟ Chaos Engineering این سناریو ها را بررسی می کند. هدف آن خراب کردن سیستم نیست؛ هدف این است که بفهمیم سیستم در برابر خرابی ها چقدر آماده است.

2. Backend for Frontend

معمولا یک سیستم ممکن است چند نوع فرانت اند داشته باشد؛ مثلا وب سایت، اپلیکیشن موبایل اندروید، اپلیکیشن iOS یا پنل مدیریتی که هر کدام از این ها ممکن است داده ها را به شکل متفاوتی نیاز داشته باشند.

در روش سنتی، همه این فرانت اند ها به یک بک اند مشترک وصل می شوند که گاهی اوقات اینکار باعث پیچیدگی بیشتر می شود، چون نیازهای موبایل با وب فرق دارد.

الگوی BFF یعنی به جای این که یک بک اند عمومی داشته باشیم که هم زمان بخواهد نیازهای وب، موبایل، پنل مدیریت و هر کلاینت دیگری را پوشش بدهد، برای هر فرانت اند یک بک اند اختصاصی می سازیم.

نتیجه این کار کاهش دریافت بیش از اندازه داده، کاهش کمبود داده در پاسخ ها و کم شدن پیچیدگی سمت کلاینت است. مثلا اپلیکیشن موبایل فقط به اطلاعات خلاصه محصول نیاز دارد، ولی نسخه وب ممکن است توضیحات کامل، نظرات، تصاویر زیاد و پیشنهادهای مرتبط را هم بخواهد. با BFF می توان برای موبایل یک API سبک تر و سریع تر ساخت.

3. AI4SE

AI4SE مخفف Artificial Intelligence for Software Engineering میباشد و به معنی استفاده از هوش مصنوعی برای بهتر انجام دادن فعالیت های مهندسی نرم افزار. در گذشته بسیاری از کارهای برنامه نویسی، تست، نگهداری و تحلیل کد کاملا دستی انجام می شدند. اما امروزه با رشد مدل های یادگیری ماشین و مخصوصاً مدل های زبانی بزرگ، می توان بخشی از این کارها را هوشمند تر یا نیمه خودکار کرد. مثلاً ابزارهای پیشنهاد کد، تولید تست، تشخیص باگ، تحلیل کدهای قدیمی، توضیح کد و حتی کمک در طراحی معماری، نمونه هایی از AI4SE هستند.

اینکار مستقیما روی بهره وری توسعه دهندگان اثر می گذارد به عنوان مثال یک برنامه نویس ممکن است با کمک ابزار هوشمند سریع تر کد بنویسد، ولی همچنان مسئول درک، بررسی و اصلاح خروجی است چون خروجی هوش مصنوعی همیشه درست نیست و ممکن است مشکلات امنیتی، منطقی یا کارایی وجود داشته باشد و به همین دلیل بیشتر به عنوان یک دستیار برای مهندسان نرم افزار عمل میکند.

4. SE4AI

SE4AI (Software Engineering for Artificial Intelligence) به کارگیری اصول مهندسی نرم افزار برای توسعه، استقرار و نگهداری سیستم هایی است که درون خود مؤلفه هوش مصنوعی دارند. در مقابل، AI4SE استفاده از خود هوش مصنوعی برای بهبود فرایندهای مهندسی نرم افزار (مثل کدنویسی خودکار، تست هوشمند) است. اما SE4AI یک پرسش بنیادی دارد: چگونه یک سیستم مبتنی بر AI را چنان مهندسی کنیم که قابل اعتماد، قابل نگهداری، مقیاس پذیر و قابل تست باشد؟

ساخت یک مدل هوش مصنوعی فقط به آموزش مدل خلاصه نمی شود. مراحل کامل آن شامل جمع آوری داده، پاکسازی داده، آموزش مدل، تست، نسخه بندی، استقرار در محیط واقعی و مانیتورینگ پس از اجراست. SE4AI تلاش می کند تا تمام این مراحل را اصولی، مستند، خودکار و قابل تکرار کند تا سیستم نهایی در برابر تغییرات داده و محیط، رفتاری باثبات و قابل پیش بینی داشته باشد.

5. MLOps

MLOps از ترکیب دو مفهوم Machine Learning و DevOps به وجود آمده و هدف اصلی آن مدیریت و بهینه ‌سازی چرخه عمر مدل ‌های یادگیری ماشین است. همان ‌طور که دواپس به دنبال ایجاد هماهنگی بیشتر بین تیم‌ های توسعه و عملیات است، MLOps نیز تلاش می‌کند فرایند های مربوط به ساخت، آزمایش، استقرار و نظارت بر مدل ‌های یادگیری ماشین را استاندارد و قابل تکرار کند.

به نظر من MLOps برای جلوگیری از آشفتگی در پروژه‌ های هوش مصنوعی ضروری است چون در این پروژه‌ ها علاوه بر کد، داده و مدل هم دارایی اصلی هستند. اگر نسخه داده مشخص نباشد یا ندانیم یک مدل با چه تنظیماتی آموزش دیده، باز تولید نتیجه تقریباً غیرممکن می‌شود. علاوه بر این، مدل‌ های هوش مصنوعی برخلاف نرم‌ افزارهای سنتی ممکن است با تغییر داده‌ های ورودی به مرور زمان دچار افت عملکرد شوند و به همین دلیل، بررسی مداوم مدل‌ ها و مدیریت صحیح فرایند های مرتبط با انها از طریق MLOps می‌تواند به حفظ کیفیت و پایداری سیستم کمک کند.

6. Infrastructure as Code (IaC)

IaC یعنی به جای اینکه تنظیمات سرورها و زیر ساخت را به صورت دستی انجام بدیم، همه چیز را در قالب کد و فایل بنویسیم. در روش قدیمی، یک مدیر سیستم باید خودش وارد پنل شود و سرورها، شبکه، پایگاه داده و تنظیمات مختلف را یکی‌یکی ایجاد کند. این کار هم زمان‌بر است و هم ممکن است باعث اشتباه شود.

در IaC همه این تنظیمات به صورت کد نوشته می‌شوند و در مخزن‌هایی مثل Git ذخیره می‌شوند و به این ترتیب هر زمان که بخواهیم می‌توانیم همان زیرساخت را دوباره و بدون دردسر ایجاد کنیم.

به نظر من مهم‌ترین مزیت IaC این است که چون همه تغییرات ثبت می‌شوند مدیریت زیرساخت را ساده‌تر می‌کند و می‌توان تغییرات را بررسی کرد یا در صورت نیاز به نسخه قبلی برگشت. همچنین ساخت محیط‌های مشابه برای تست یا اجرا خیلی راحت‌تر می‌شود.

7. API Gateway & Service Mesh

این دو مورد برای مدیریت ارتباطات میکروسرویس در سیستم های مدرن استفاده می‌شوند، اما کاربردشان با هم متفاوت است که در ادامه بررسی میکنیم.

API Gateway در واقع در ورودی سیستم قرار می‌گیرد یعنی وقتی کاربر از طریق سایت یا اپلیکیشن درخواستی ارسال می‌کند، ابتدا این درخواست به API Gateway می‌رسد و بررسی میشود که کاربر مجاز است یا نه، سپس درخواست را به سرویس مناسب می‌فرستد و گاهی اطلاعات لازم را جمع‌آوری و مدیریت می‌کند. به زبان ساده، API Gateway مثل درب ورودی یک ساختمان است که همه باید از آن عبور کنند.

اما Service Mesh داخل سیستم کار می‌کند، در معماری مایکروسرویس، سرویس‌های مختلف دائماً با یکدیگر در ارتباط هستند. Service Mesh کمک می‌کند این ارتباطات به شکل امن‌تر و منظم‌تر انجام شوند. همچنین کارهایی مثل مدیریت خطاها، توزیع ترافیک و نظارت بر ارتباط بین سرویس‌ها را ساده‌تر می‌کند.

به نظر من تفاوت اصلی این دو در این است که API Gateway درخواست‌های ورودی از کاربران را مدیریت می‌کند، اما Service Mesh ارتباط بین سرویس‌های داخلی را کنترل می‌کند. در پروژه‌های کوچک شاید نیازی به استفاده از این ابزارها نباشد، اما در سیستم‌های بزرگ و پیچیده استفاده از آن‌ها باعث می‌شود مدیریت و نگهداری سیستم بسیار راحت‌تر شود.

8. CQRS (Command Query Responsibility Segregation)

CQRS یک روش طراحی نرم‌افزار است که در آن عملیات ثبت و تغییر اطلاعات از عملیات نمایش و خواندن اطلاعات جدا می‌شود. در بسیاری از برنامه‌ ها یک بخش هم داده‌ها را ذخیره و ویرایش می‌کند و هم آن‌ها را نمایش می‌دهد، اما در CQRS این دو کار از هم تفکیک می‌شوند. برای مثال در یک سیستم دانشگاهی، ثبت نمره دانشجو نیاز به دقت، قوانین مشخص و بررسی‌ های مختلف دارد، اما دیدن نمرات یا لیست واحدهای ارائه‌ شده باید سریع و ساده باشد. به همین دلیل می‌توان بخش ثبت و تغییر اطلاعات (مثل وارد کردن نمره یا ثبت‌نام دانشجو) را جدا از بخش نمایش اطلاعات طراحی کرد تا هر کدام بهتر و بهینه‌تر کار کنند.

این روش می‌تواند سرعت و مقیاس‌پذیری سیستم را افزایش دهد، چون بخش خواندن و بخش نوشتن به صورت مستقل مدیریت و بهینه می‌شوند. البته CQRS برای همه پروژه‌ها مناسب نیست. در پروژه‌های کوچک معمولاً استفاده از آن فقط باعث پیچیده‌تر شدن سیستم می‌شود. همچنین چون اطلاعات از دو مسیر جدا مدیریت می‌شوند، ممکن است گاهی نمایش اطلاعات با کمی تأخیر به‌روزرسانی شود. به نظر من CQRS بیشتر برای سیستم‌های بزرگ و پرکاربرد مفید است؛ جایی که تعداد درخواست‌ها زیاد است و نیازهای بخش خواندن و نوشتن تفاوت زیادی با هم دارند.

9. Event-Driven Architecture (EDA)

معماری EDA یعنی اجزای یک سیستم به جای اینکه مستقیم همدیگر را صدا بزنند، با رویدادها با هم ارتباط برقرار می‌کنند. رویداد یعنی یک اتفاق که در سیستم رخ داده؛ مثل اینکه کاربر ثبت‌نام کرد، سفارش ثبت شد یا پرداخت انجام شد. در این روش، یک بخش سیستم این اتفاق را اعلام می‌کند و بقیه بخش‌ها اگر لازم داشته باشند به آن واکنش نشان می‌دهند.

برای مثال وقتی یک سفارش ثبت می‌شود، سیستم سفارش فقط اعلام می‌کند که سفارش ثبت شده است. بعد از آن بخش‌های دیگر مثل ارسال ایمیل، مدیریت انبار یا تحلیل داده‌ها، هرکدام جداگانه کار خودشان را انجام می‌دهند. این باعث می‌شود بخش‌های سیستم وابستگی کمتری به هم داشته باشند و راحت‌تر بتوان آن‌ها را تغییر یا گسترش داد.

البته این روش همیشه ساده نیست چون دیگر همه چیز پشت سر هم و خطی نیست، فهمیدن اینکه دقیقاً چه اتفاقی در سیستم افتاده سخت‌تر می‌شود. همچنین باید دقت کرد پیام‌ها گم نشوند، دوباره تکرار نشوند و ترتیبشان درست باشد.

10. Serverless Architecture

معماری Serverless یعنی اینکه لازم نیست خودت درگیر مدیریت سرورها بشوید سرورها هنوز وجود دارند، اما همه کارهای سختش مثل راه‌اندازی، نگهداری، آپدیت و افزایش ظرفیتشون رو شرکت‌های ابری انجام میدهند.

یکی از مزیت‌های مهم این روش اینه که برای کارهایی که گاهی اجرا می‌شن خیلی به‌صرفه‌ست. چون فقط وقتی استفاده می‌کنی هزینه می‌دی و لازم نیست همیشه سرور روشن نگه داری. همچنین سیستم خودش می‌تونه با افزایش درخواست‌ها بزرگ‌تر بشه و نیاز به تنظیم دستی نداره.

البته Serverless بی‌نقص نیست. بعضی وقت‌ها اجرای کد با کمی تأخیر شروع می‌شه، محدودیت زمانی برای اجرای هر تابع وجود داره و کنترل روی محیط اجرا کمتره. همچنین پیدا کردن خطاها یا تست کردن برنامه ممکنه سخت‌تر باشه. به طور خلاصه، Serverless برای کارهای سبک، API های ساده یا کارهایی که گاهی اجرا می‌شن خیلی خوبه، اما برای سیستم‌های خیلی سنگین یا پیچیده همیشه بهترین انتخاب نیست.

11. API-first Approach

رویکرد API-first یعنی قبل از اینکه شروع کنیم کل برنامه را بسازیم اول مشخص می‌کنیم برنامه چطور با بخش‌های دیگر ارتباط می‌گیرد یعنی API را از اول به عنوان بخش اصلی کار در نظر می‌گیریم نه چیزی که آخر کار اضافه شود.

در این روش قبل از نوشتن کد مشخص می‌شود چه درخواست‌هایی داریم، چه اطلاعاتی باید بفرستیم و چه جوابی برگردد. حتی چیزهایی مثل خطاها، ورود و خروج داده‌ها و نسخه‌های مختلف API هم از قبل طراحی می‌شوند.

این کار باعث می‌شود تیم‌ها راحت‌تر با هم کار کنند مثلاً تیم فرانت‌اند می‌تواند بدون داشتن بک‌اند کامل، با داده‌های فرضی کار کند. تیم بک‌اند هم جداگانه روی پیاده‌سازی کار می‌کند. این موضوع سرعت توسعه را بالا می‌برد و هماهنگی را ساده‌تر می‌کند.

یکی دیگر از مزیت‌های API-first این است که طراحی API تمیزتر و بهتر می‌شود، چون از ابتدا با فکر و برنامه‌ریزی ساخته می‌شود، نه اینکه بعداً از روی اجبار به کد اضافه شود. البته این روش نیاز به دقت و هماهنگی دارد. اگر API مدام تغییر کند، بقیه تیم‌ها دچار مشکل می‌شوند. برای همین مستندسازی و مدیریت نسخه‌ها خیلی مهم است.

12. Domain Driven Design

DDD یعنی طراحی نرم ‌افزار را بر اساس موضوع اصلی کسب‌وکار انجام بدهیم، نه فقط بر اساس کد و تکنولوژی. منظور از دامنه همان حوزه‌ای است که نرم‌افزار برای آن ساخته می‌شود؛ مثل آموزش، بانک، فروشگاه یا بیمه. ایده اصلی این است که بیشتر پیچیدگی نرم‌افزار از فهم درست کارهای واقعی کسب‌وکار می‌آید، نه از خود برنامه‌نویسی.

در این روش تلاش می‌شود همه افراد تیم، یعنی برنامه‌نویس‌ها و افراد بیزنسی، از یک زبان مشترک استفاده کنند. مثلاً وقتی می‌گویند سفارش، پرداخت یا مرجوعی، همه دقیقاً یک معنی یکسان از آن داشته باشند و همین مفاهیم هم در کد استفاده شود و این کار باعث می‌شود فهم سیستم ساده ‌تر و اشتباهات کمتر شود.

یک نکته مهم دیگر در DDD این است که یک کلمه ممکن است در بخش‌های مختلف سیستم معنی متفاوتی داشته باشد برای همین سیستم به بخش‌های جدا تقسیم می‌شود تا هر بخش معنی خودش را از مفاهیم داشته باشد و همه‌چیز قاطی نشود. به طور کلی، DDD کمک می‌کند نرم‌افزار شبیه دنیای واقعی کسب‌وکار ساخته شود، نه فقط شبیه یک ساختار فنی.

13. Hexagonal architecture

معماری شش‌ضلعی یا Hexagonal Architecture یعنی اینکه بخش اصلی برنامه را از چیزهای بیرونی مثل دیتابیس، رابط کاربری یا سرویس‌های دیگر جدا کنیم. ایده اصلی این است که منطق اصلی برنامه که همان قوانین کسب‌وکار است، نباید به هیچ تکنولوژی خاصی وابسته باشد.

در این روش، برنامه یک هسته مرکزی دارد که کار اصلی را انجام می‌دهد. اطراف این هسته پورت و آداپتر قرار می‌گیرند که پورت‌ها در واقع مثل یک قرارداد هستند که مشخص می‌کنند برنامه چه ورودی و خروجی‌هایی دارد و آداپترها هم وظیفه دارند این قراردادها را به دنیای واقعی وصل کنند مثلاً یک آداپتر می‌تواند داده‌ها را در دیتابیس ذخیره کند و یک آداپتر دیگر می‌تواند فقط برای تست، اطلاعات را داخل حافظه نگه دارد.

مزیت این روش این است که هسته اصلی برنامه دست ‌نخورده باقی می‌ماند و اگر بخواهیم دیتابیس یا فریمورک را عوض کنیم، فقط آداپترها تغییر می‌کنند. این موضوع باعث می‌شود تست کردن برنامه هم راحت‌تر شود، چون می‌توان بدون وابستگی به دیتابیس یا ابزارهای خارجی، منطق اصلی را بررسی کرد.

به طور کلی، این معماری می‌گوید بخش مهم برنامه باید مستقل از ابزارها باشد و ابزارها فقط نقش کمک‌کننده داشته باشند، نه اینکه هسته اصلی سیستم را تشکیل دهند. این روش بیشتر برای پروژه‌های متوسط و بزرگ مناسب است، چون در پروژه‌های کوچک ممکن است بیش از حد پیچیده به نظر برسد.

14. Event Sourcing

Event Sourcing یعنی به جای اینکه فقط وضعیت فعلی یک سیستم را ذخیره کنیم، همه اتفاق‌هایی که باعث تغییر آن شده‌اند را نگه می‌داریم. برای مثال در یک حساب بانکی، به جای اینکه فقط بگوییم الان موجودی چقدر است، همه تراکنش‌ها را ذخیره می‌کنیم؛ مثل اینکه پول واریز شده، برداشت انجام شده یا کارمزدی کم شده است. بعد اگر بخواهیم موجودی فعلی را بدانیم، همه این اتفاق‌ها را از اول حساب می‌کنیم و به نتیجه می‌رسیم.

ایده ساده این است که به جای دیدن فقط نتیجه نهایی، کل مسیر اتفاق‌ها را هم داشته باشیم که این کار کمک می‌کند بفهمیم سیستم دقیقاً چه روندی را طی کرده و در صورت مشکل، راحت ‌تر بتوانیم ریشه آن را پیدا کنیم. همچنین برای بررسی تاریخچه یا گزارش‌گیری خیلی مفید است، مخصوصاً در سیستم‌هایی مثل مالی که جزئیات تغییرات مهم هستند.

15. Low-code/No-code platforms

پلتفرم‌های Low-code و No-code ابزارهایی هستند که کمک می‌کنند نرم‌افزار را خیلی سریع‌تر و ساده‌تر بسازیم. در Low-code هنوز کمی کدنویسی لازم است، اما بیشتر کارها با ابزارهای آماده و تصویری انجام می‌شود. در No-code حتی نیازی به کدنویسی نیست و افراد معمولی هم می‌توانند با کشیدن و رها کردن اجزا، یک برنامه ساده بسازند.

دلیل محبوب شدن این ابزارها این است که خیلی از بخش‌های یک سازمان نیاز به برنامه‌ های ساده دارند، اما همیشه زمان و منابع تیم برنامه‌نویسی کافی نیست. برای همین این ابزارها کمک می‌کنند خود تیم‌های غیر فنی هم بتوانند کارهای ساده‌شان را سریع انجام دهند، بدون اینکه منتظر تیم توسعه بمانند.

البته این روش‌ها محدودیت دارند. اگر پروژه پیچیده باشد یا نیاز به کنترل دقیق و عملکرد بالا داشته باشد، این ابزارها کافی نیستند. همچنین اگر بدون نظارت استفاده شوند، ممکن است هر بخش سازمان یک برنامه جدا بسازد و بعداً مدیریت و هماهنگ کردن آن‌ها سخت شود.

16. Business Process Management Systems (BPMS)

BPMS یا سیستم مدیریت فرایند کسب‌ و کار ابزاری است که کمک می‌کند کارهای داخل یک سازمان به شکل منظم ‌تر و قابل‌ پیگیری انجام شوند. منظور از فرایند، یک سری کار پشت سر هم است که برای رسیدن به یک هدف انجام می‌شود؛ مثل استخدام یک کارمند، بررسی درخواست وام یا تأیید مرخصی. در این سیستم، اول کل فرایند مشخص و طراحی می‌شود یعنی گفته می‌شود چه مراحلی دارد، چه کسانی در هر مرحله نقش دارند و تصمیم‌ها بر چه اساسی گرفته می‌شود. بعد از آن، سیستم این فرایند را اجرا می‌کند و کارها را مرحله به مرحله جلو می‌برد. مثلاً یک درخواست را به فرد درست ارسال می‌کند، زمان انجام کار را ثبت می‌کند و اگر کاری دیر شود، هشدار می‌دهد.

مزیت اصلی BPMS این است که همه چیز شفاف می‌شود و مدیر می‌تواند ببیند هر کار در چه مرحله‌ای است و اگر مشکلی وجود دارد، آن را راحت‌تر پیدا کند اما اگر خود فرایند از اول درست طراحی نشده باشد، استفاده از این سیستم فقط باعث می‌شود همان مشکلات سریع‌تر و منظم‌تر تکرار شوند.

17. Message Queue (such as Kafka and RabbitMQ)

Message Queue یا صف پیام یعنی یک روش برای اینکه بخش‌های مختلف یک سیستم بدون اینکه مستقیم منتظر هم بمانند با هم کار کنند.

در حالت معمول اگر یک بخش بخواهد کاری انجام دهد، باید صبر کند بخش دیگر جواب بدهد. اما در صف پیام اینطور نیست. یک بخش پیام را داخل یک صف می‌گذارد و بعداً بخش دیگر آن را برمی‌دارد و انجام می‌دهد. این باعث می‌شود سیستم سریع‌تر و منظم‌تر کار کند و بخش‌ها وابسته به هم نباشند.

ابزارهایی مثل RabbitMQ و Kafka برای این کار استفاده می‌شوند. RabbitMQ بیشتر برای ارسال و دریافت پیام‌ های معمولی استفاده می‌شود، اما Kafka برای حجم خیلی زیاد داده و رویدادهای پشت سر هم مناسب‌تر است.

البته استفاده از صف پیام همیشه هم ساده نیست و باید مراقب باشیم پیام ‌ها دوبار پردازش نشوند، ترتیبشان به هم نریزد و اگر خطایی رخ داد سیستم بتواند دوباره تلاش کند. با این حال این روش در سیستم‌های بزرگ خیلی مفید است چون باعث می‌شود سیستم قابل‌اعتمادتر و مقیاس‌پذیرتر باشد.

18. Containers (eg., Docker) and Container orchestration (e.g., Kubernetes)

کانتینر یعنی یک جور بسته‌بندی کردن برنامه به همراه همه چیزهایی که لازم دارد تا اجرا شود. مثلاً اگر یک برنامه برای اجرا به یک نسخه خاص از Node.js، چند کتابخانه و تنظیمات مشخص نیاز داشته باشد، همه این‌ها داخل یک بسته قرار می‌گیرند تا برنامه در هر سیستمی تقریباً به یک شکل اجرا شود.

ابزار داکر یکی از معروف‌ترین ابزارها برای ساخت و اجرای این کانتینرها است و مزیت مهم این روش این است که مشکل معروف روی سیستم من کار می‌کند ولی روی سیستم تو نه تا حد زیادی حل می‌شود، چون همه چیز داخل یک بسته ثابت قرار دارد.

اما وقتی تعداد کانتینرها زیاد می‌شود، مدیریت آن‌ها سخت می‌شود مثلاً باید مشخص شود هر کانتینر کجا اجرا شود، اگر از کار افتاد دوباره بالا بیاید، اگر فشار زیاد شد چند نسخه جدید ساخته شود و ارتباط بین آن‌ها چطور باشد.

برای حل این مشکل از ابزارهایی مثل کوبرنتیز استفاده می‌شود که کمک می‌کند کانتینرها به صورت خودکار مدیریت شوند، مقیاس پیدا کنند و در صورت خرابی دوباره اجرا شوند.

19. Multi-Tenancy Architecture

معماری Multi-Tenancy یعنی اینکه یک نرم‌ افزار واحد به چند مشتری یا سازمان مختلف سرویس بدهد، اما هر کدام از آن‌ها داده‌ ها و اطلاعات جداگانه خودشان را داشته باشند که به هر مشتری در این مدل tenant گفته می‌شود.

برای مثال فرض کنید یک سامانه آموزشی توسط چند دانشگاه مختلف استفاده می‌شود. همه دانشگاه‌ها از یک نرم‌افزار مشترک استفاده می‌کنند، اما هر دانشگاه فقط به اطلاعات دانشجویان، اساتید، دروس و نمرات خودش دسترسی دارد و نمی‌تواند اطلاعات دانشگاه‌های دیگر را مشاهده کند.

مزیت این روش این است که هزینه نگهداری و توسعه نرم‌افزار کمتر می‌شود، چون به جای ساخت و مدیریت چند سامانه جداگانه، فقط یک سیستم مشترک وجود دارد. همچنین به‌روزرسانی‌ها و قابلیت‌های جدید یک‌بار روی سیستم اعمال می‌شوند و همه دانشگاه‌ها از آن بهره‌مند می‌شوند. البته مهم‌ترین چالش این معماری حفظ جداسازی اطلاعات است و سیستم باید طوری طراحی شود که اطلاعات هر دانشگاه کاملا مستقل و امن باشد و به هیچ عنوان با اطلاعات دانشگاه‌های دیگر مخلوط نشود.

20. Data Migration

Data Migration یعنی انتقال اطلاعات از یک سیستم یا پایگاه داده به یک سیستم جدید. این کار معمولاً زمانی انجام می‌شود که یک سازمان بخواهد نرم‌افزار خود را عوض کند، دیتابیس را ارتقا دهد یا از یک سیستم قدیمی به سیستم جدید منتقل شود.

برای مثال، فرض کنید یک دانشگاه سال‌ها از یک سامانه آموزشی قدیمی استفاده کرده و حالا می‌خواهد سامانه جدیدی راه‌اندازی کند. در این حالت اطلاعات دانشجویان، اساتید، نمرات و انتخاب واحدها باید از سیستم قدیمی به سیستم جدید منتقل شوند. مهم‌ترین بخش مهاجرت داده این است که قبل از شروع، همه چیز به‌خوبی برنامه‌ریزی شود، باید مشخص شود چه اطلاعاتی منتقل می‌شوند، اطلاعات تکراری یا اشتباه چگونه اصلاح می‌شوند و بعد از انتقال چطور مطمئن شویم همه داده‌ها درست منتقل شده‌اند.

گاهی برای انجام این کار، سیستم قدیمی برای مدتی از دسترس خارج می‌شود تا انتقال انجام شود اما در بعضی موارد، سیستم قدیمی و جدید مدتی همزمان کار می‌کنند تا اطلاعات به‌تدریج منتقل شوند و کاربران کمتر دچار مشکل شوند.

به طور کلی Data Migration یعنی جا به ‌جایی امن و صحیح اطلاعات از یک سیستم به سیستم دیگر و چون داده‌ها بسیار ارزشمند هستند، اگر این کار به‌درستی انجام نشود ممکن است اطلاعات از بین بروند یا مشکلات زیادی برای کاربران ایجاد شود.

لیست منابع