طراحی بر اساس دامنه، یکی از رویکردهای درشت‌دانه‌ی معماری نرم افزار است که در آن سعی میکنیم از سطح کسب و کار به سطح کد برسیم، یعنی باتوجه به هر دامنه مورد نیاز در لایه‌ی کسب و کار به لایه های پایین تر و در آخر به لایه ی کد نرم افزار برسیم.
این رویکرد چند هدف مهم دارد که سعی میکند به آنها برسد:
1. تمرکز کردن پروژه روی حوزه ها و دامنه‌ی اصلی؛
2. پایه گذاری طرح های پیچیده بر روی مدلی از دامنه؛
3. همکاری خلاقانه بین متخصصان فنی و حوزه برای اصلاح مکرر و توسعه‌ی یک مدل مفهومی که به مشکلات حوزه خاصی می‌پردازد.
معماری Ports and Adapters که اسم دیگر آن معماری Hexagonal است، معماری است که بر تست پذیری ۱۰۰ درصدی و کامل برنامه بدون وابستگی به Actorهای(اولیه و ثانویه) سیستم تاکید دارد. این معماری جزء معماری‌های مبتنی بر Use-Case می باشد(Use-Case Driven Architecture). به طور خلاصه این معماری قابلیت تست‌پذیری و تغییر در کد را افزایش می‌دهد در نتیجه قابلیت تغییر و یا جایگزینی بخشی از کد، ماژول و یا شئ‌ها را برای برنامه‌نویس ساده‌تر میکند.
برای رسیدن به این هدف، بایستی از ساختارهایی با وابستگی کم (Loosely coupled) استفاده کنیم.
هگزاگونال در واقع یک روش انتزاعی برای توصیف هسته‌ی یک برنامه است که توسط دامین آبجکت‌ها،
Use-Caseهایی که آنها را عملیاتی میکنند و پورت‌های input و output که یک رابط برای دستیابی به دنیای بیرون می‌باشند، است.
در واقع CQRS الگویی است که عملیات خواندن و به روز رسانی را برای یک ذخیره از داده جدا می کند. پیاده سازی CQRS در برنامه می تواند عملکرد، مقیاس پذیری و امنیت آن را به حداکثر برساند. انعطاف‌پذیری ایجاد شده با مهاجرت به CQRS به سیستم اجازه می‌دهد در طول زمان بهتر تکامل یابد و از ایجاد تداخل در ادغام های در سطح دامنه توسط دستورات به‌روزرسانی جلوگیری میکند.
نمونه ای از CQRS را می توان در طول فرآیند سفارش مشتری مشاهده کرد. وقتی مشتری به یک سفارش نگاه می کند، فرآیند نسبتاً ساده است: خواندن از یک پایگاه داده. در عمل، این خوانده شدن می تواند از یک پایگاه داده از جنس Key-Value NoSQL، مانند Redis باشد. این Key-Value تمام اطلاعات سریع الوصول در مورد مشتری را در یک مکان ذخیره میکند. یک میکروسرویس اطلاعات را دریافت می کند و یک صفحه وب آن را نمایش می دهد. قسمت خواندن ساده است و می تواند به طور کامل توسط تیم Redis که با توسعه دهندگان Front-End کار می کند انجام شود. بنابراین، مسئولیت خواندن CQRS از نوشتن جدا می شود.
با این حال، سمت نوشتن عملیات بسیار پیچیده‌تر است و شامل چندین مرحله و وابستگی متفاوت است. به عنوان مثال، اگر سفارشی قبل از ارسال لغو شود، بازگشت باید در حافظه پنهان لغو شود و در منبع اصلی ثبت اطلاعات بازگردانده شود. شرکت هایی که دارای انبار داده هستند باید رکورد را از انبار و همچنین سایر سیستم های کمکی حذف کنند. انبار فیزیکی و حمل و نقل باید برای عدم ارسال کالا مطلع شوند. پیچیدگی‌های دیگر می‌تواند شامل هزینه‌های کارت اعتباری باشد که باید بازگردانده شوند، تعداد موجودی انبار که نیاز به تغییر دارد و سفارش پر کردن مجدد از طرف تامین‌کننده که باید یک‌بار کاهش یابد.
از آنجا که یک تغییر واحد باید در مکان‌های زیادی کپی شود، به‌روزرسانی، حذف و ایجاد سمت عملیات باید با یک گذرگاه خدمات سازمانی (ESB) یا یک کنترل‌کننده فرمان، مانند الگوی saga، تعامل داشته باشد. CQRS مکانی را برای قرار دادن منطق رسیدگی به این تراکنش های پیچیده فراهم می کند.
این الگو توسط مایکروسافت معرفی شد و بعدها مثل MVC به دنیای وب پا گذاشت و استفاده از اون بین فریم‌ورک‌های جاوااسکریپت رایج شد. این الگو از سه بخش تشکیل شده:
Model - View - ViewModel
این سه بخش، برنامه‌ی ما رو به سه بخش اصلی تقسیم می‌کنن. سه بخشی که هر کدوم می‌تونن بصورت جدا توسعه داده بشن تا وابستگی بخش‌ها به هم دیگه کم بشه و همچنین توسعه‌ی موازی قابل اجرا باشه. حالا نوبت بررسی هر بخش هست.
مدل مرکز دیتای برنامه هست. مدل شامل اطلاعات و دیتای برنامه‌ی ماست. مدل جایی هست که فقط اطلاعات نگهداری میشه. برای مثال اطلاعات یک مدل، کاربرها، پست‌ها و دسته‌بندی‌های برنامه‌ست. وظیفه‌ی مدل این نیست که رفتارها و سرویس‌هایی برای ویرایش و دستکاری اطلاعات ارائه بده. همچنین مدل مسئول نحوه‌ی نمایش اطلاعات نیست. وظیفه‌ی مدل نگهداری، حفظ و ارائه اطلاعات مورد نیاز هست. توی یک برنامه اینکه اطلاعات چگونه دریافت بشه و چگونه نمایش داده بشه، بر عهده مدل نیست. مدل مسئول نگهداری اطلاعات تا حد امکان خام هست. چرا خام؟ توی قسمت View به جواب این سوال می‌رسیم.
به ظاهر و پوسته‌ی و جایی که یک کاربر اونها رو می‌بینه و با اون در ارتباط و تعامل هست میگن ویوو. مثلا فرم‌ها، دکمه‌ها، متن‌ها و ... . اینکه اطلاعات مدل چگونه و به چه سبکی نمایش داده بشن، وظیفه ویوو هست. توی قسمت مدل گفتم که اطلاعات مدل تا حد امکان خام هست. برای مثال اطلاعات یک کاربر (اسم، سن، تاریخ ثبت‌نام) رو توی مدل در نظر بگیرین. فرمتی که مدل برای تاریخ ثبت‌نام کاربرا ارائه میده یک تاریخ میلادی یا حتی Unix Time هست. ما توی ویوو آزادانه می‌تونیم به هر فرمتی که دلمون می‌خواد این تاریخ رو نمایش بدیم. مثلا بصورت Y-m-d یا حتی تاریخ جلالی ایرانی. پس مدل نباید اطلاعاتش رو براساس نیاز ویوو تغییر شکل بده.
ویوو شامل رفتارها و سرویس‌هایی (مثل رویدادهای کلیک، لمس) هست که طی اون اطلاعات مدل می‌تونه تغییر کنه. مثلا یک فرم برای ثبت یک کاربر جدید. وقتی کاربر اطلاعاتی رو از طریق فرم ارسال کرد، دستوراتی توی برنامه تعریف شده که این اطلاعات توی مدل ذخیره بشه. با مفهوم دستورات تعریف شده، توی قسمت ویوومدل آشنا می‌شیم.
این قسمت واسط مدل و ویوو هست. یک چیزی شبیه نقش کنترلر توی MVC. ویوومدل اطلاعات مدل، عملکردها و ویژگی‌های ارائه میده که توسط ویوو استفاده میشه و همچنین عملکردهایی (مثل متدها، توابع و ...) که با اونها اطلاعات مدل دستکاری میشه. به بیان ساده‌تر، ویوومدل تبدیل‌کننده اطلاعات هست. می‌تونه اطلاعات رو طوری به ویوو تحویل بده که ویوو می‌خواد. همچنین اطلاعات رو طوری به مدل تحویل میده که مدل می‌خواد. فرض کنیم توی ویوو یک رویداد (مثلا submit فرم کاربر جدید) رخ داده. خب انتظار داریم این اطلاعات توی مدل ثبت بشه. ویوو این اطلاعات رو به متدی می‌فرسته که توی ویوومدل وجود داره. وظیفه‌ی این متد اینه که اطلاعات رو از ویوو بگیره، یک سری کارها (مثلا اعتبارسنجی) انجام بده.
«ثبت و ضبط کردن تمام تغییرات در وضعیت یک اپلیکیشن به طور بهم پیوسته و دنباله دار» را ایونت سورسینگ میگویند.
برای ابزار هم، متناسب با معماری نرم افزار و تکنولوژی هایی که درش بکار رفته، باید تصمیم گرفت که از چه دیتابیسی و با چه مدلی این تغییرات وضعیت نرم افزار رو ثبت کرد. نکته مهم در این حوزه پیوستگی این دیتای ثبت شده است. به این معنی که دیتا باید بگونه ای ثبت شده باشه که شما باید قادر باشید مسیر تغییر رفتارها رو ببینید و تحلیل بکنید.
باید بتونید تشخیص بدید که دقیقا در چه مرحله ای رفتار و عملکرد نرم افزار (یا همون اپلیکیشن) اشتباه و غیر قابل انتظار بوده. ایونت سورسینگ فواید زیادی داره که از جمله مهمترینش میشه به دیباگ کردن منطقی پروژه و کنترل کیفی و رفتاری پروژه اشاره کرد.
به عنوان مثال، در سامانه های مالی که به طور مستقیم با حساب و کتاب پولی ارتباط دارن، پیاده سازی همچین مکانیسمی برای track کردن مقادیر مالی و کشف کسورات پولی در انتهای محاسبات و گزارشات به شدت حائز اهمیت هست. همچنین وقتی شما یک ورژن جدید از پروژه رو ارائه میکنید و طبیعتا انتظار دارید که در بعضی جاهاش که تغییرش دادید، این تغییرات رو در رفتار پروژه هم ببینید که با ایونت سورسینگ و مقایسه با دیتای ضبط شده سابق میشه به این مهم دست یافت.
نگهداری، توسعه، تست و پیاده‌سازی Monolithic frontendها دشوار است. راه‌حل این دشواری micro frontendها هستند.و یک نوع معماری است که می‌تواند اثربخشی و کارایی را در بین تیم‌ها افزایش دهد. در سال‌های اخیر، محبوبیت میکروسرویس‌ها افزایش بسیاری یافته است. بسیاری از سازمان‌ها از این نوع معماری برای جلوگیری از محدودیت‌های بزرگ monolithic backendها استفاده میکنند.
ایده micro frontends این است که مفاهیم میکروسرویس‌ها را به دنیای frontend گسترش دهد. ایده اصلی micro frontends این است که frontend خود را به مجموعه‌ای از اپلیکیشن‌های frontend که به طور مستقل و با loosely coupled (حداقل وابستگی) قابل‌اجرا هستند، تقسیم میکند (micro frontends نامیده می‌شوند). سپس این micro frontendها برای ایجاد یک اپلیکیشن frontend واحد، با هم ادغام شده و باندل می‌شوند.
بر اساس تعریف ویکی‌پدیا، یک «پلتفرم توسعه کم کد» (LCDP) نرم‌افزاری است که یک محیط در اختیار برنامه‌نویس‌ها قرار می‌دهد تا نرم‌افزارهای کاربردی را از طریق رابط‌های کاربری گرافیکی و پیکربندی کردن به جای روش‌های سنتی برنامه‌نویسی رایانه توسعه دهند.
این تعریف تا حدود زیادی گویا است. توسعه کد دقیقاً به همین معنا و به صورت توسعه نرم‌افزار به روش گرافیکی و نوشتن کد کم یا کلاً بدون نوشتن کد در این فرایند است.
پلتفرم‌های توسعه کم کد ابزارهای گرافیکی برای طراحی یک اپلیکیشن یا سیستم را همراه با ورودی‌های مورد نظر، خروجی‌ها، منطق تجاری و دیگر جنبه‌ها فراهم می‌سازند. بسته به قابلیت‌های پلتفرم که مورد استفاده قرار می‌گیرند و الزامات کلی سیستم، توسعه‌دهنده ممکن است طراحی را با مقداری کد به سبک قدیمی خوب ارتقا دهد و یا ممکن است پلتفرم کل راه‌کار را بدون هیچ گونه کد اضافی تولید کند.
این فرایند می‌تواند بسته به نوع پلتفرم کم کد بسیار متفاوت باشد. مانند پلتفرمی که در ادامه بررسی خواهیم کرد، هر پلتفرم بسته به تیمی که آن را توسعه داده است و یا نیازهای تجاری که هر پلتفرم برای رفع آنها توسعه یافته است، می‌تواند متفاوت باشد. با این حال، مفاهیم عمومی یکسان هستند و فرایند به طور کلی شامل نگاشت طراحی‌های رابط کاربری پایگاه‌های داده، API-ها و رفتار اپلیکیشن کلاینت برای تولید مشخصاتی است که پلتفرم برای گردآوری سیستم کاری مورد استفاده قرار می‌دهد.
فهرستی از برخی از پلتفرم‌های مفیدی که موجود هستند :
سیصESB مخفف کلمه Enterprise Service Bus و به معنی گذرگاه سرویس سازمانی است. ESB (گذرگاه سرویس سازمانی) یک میان افزار است که برای ادغام سیستم‌ها و برنامه‌های مختلف سازمان استفاده میشود و جایگزین ارتباط نقطه به نقطه وب سرویس‌های سازمان میشود. به عنوان مثال میتوان به Mule ESB اشاره کرد.
برای ارتباط واحدهای مختلف نرم افزار با یکدیگر به جای ارتباط یک به یک، میتوان از یک ESB مرکزی استفاده کرد که تمام واحدها ابتدا با این ESB ارتباط برقرار کرده و سپس با کمک آن با هم ارتباط برقرار میکنند.
روش بهتری برای تعامل clientها با میکروسرویس‌ها وجود دارد که آن را با نام API Gateway می‌شناسیم. در این روش تنها نقطه ورود برنامه ما یک Gateway است و راه ارتباطی Clientها با microserviceها همین Gateway است. در صورتی که با الگوی facade آشنایی داشته باشید API Gateway عملکردی شبیه به این الگو دارد. در این الگو به جای اینکه برای انجام یک کار با چندین API مختلف تعامل کنیم به سادگی با یک API تعامل میکنیم و پیچیدگی‌ها و معماری داخلی ما از چشم استفاده کننده پنهان می‌ماند. صدا زدن چندین سرویس مختلف و ترکیب نتنیجه و بازگرداندن نتیجه نهایی مواردی است که باید داخل API Gateway ما کپسوله شود و استفاده کننده نهایی به سادگی و با صدا زدن یک API نتیجه دلخواه خود را دریافت کند.
نرم افزاری است که فرایندهای سازمانی را میتوان به صورت شفاف بررسی، تحلیل و دنبال کند.
سیستم مدیریت فرایندهای کسب و کار است (که گاهی هم سرویس مدیریت فرایندهای کسب و کار خوانده میشود). BPMS با استفاده از تحلیل و همچنین اتوماسیون به سازمان شما کمک میکند تا فرایندهای کسب و کار خود را بهبود بخشید. یک BPMS باید این توانمندی را داشته باشد که بتواند تمامی فرایندهای کسب و کار را در سازمان شما مدل نموده، ایجاد کرده، ویرایش و اجرا نماید. همچنین باید بتواند داده‌ها را جمع‌آوری نموده و تجزیه و تحلیل نیز انجام دهد.
قوانین تجاری اساساً بلوک های ساختاری سازمانی خط مشی شرکت هستند که برای دستیابی به اهداف استراتژیک استفاده می شوند. قوانین کسب و کار پارامترهایی را برای نحوه اجرای وظایف و نحوه اجرای عملکردهای سازمانی تعیین می کند. هنگامی که قوانین کسب و کار را ایجاد، مدیریت و خودکار می کنید، در واقع درگیر مدیریت قوانین تجاری با هدف استفاده از منابع کمتر برای دستیابی به اهداف مشابه هستید.
سیستم مدیریت قوانین کسب و کار (BRMS) پلتفرمی است که برای خودکارسازی منطق تصمیم‌گیری به عنوان یک قانون تجاری در بین برنامه‌ها طراحی شده است. به جای ادغام کد منبع بر اساس یک برنامه کاربردی، یک پلت فرم BRMS قوانین تجاری مدیریت را از کد برنامه بیرونی می کند. در نتیجه، چندین برنامه می توانند همزمان از قوانین تجاری تعیین شده استفاده کنند.
دلیل استفاده از BRMS
شرکت ها می توانند از یک پلت فرم BRMS برای حفظ قوانین تجاری خود و تعیین اقدامات از یک مخزن مرکزی استفاده کنند. منطق تصمیم گیری خارج از کد برنامه نویسی است و BRMS را به یک کاتالیزور برای منطق دقیق، کارایی فرآیند، بهبود بهره وری و چابکی تبدیل می کند. می‌توانید در هر زمان و در صورت نیاز، تغییرات سریع‌تری در قوانین کسب‌وکار انجام دهید.
در الگوی ارتباط با روش Message-queuing، Queue ها از نظر زمانی Producer را از Consumer جدا میکنند. چندین Producer می‌توانند به Queue یکسان پیام ارسال کنند. بااین‌حال، هنگامی‌که یک Consumer پیامی را پردازش میکند، آن پیام قفل یا از Queue خارج میشود و دیگر در دسترس نیست. درواقع یک Consumer فقط می‌تواند پیام خاصی را پردازش کند.
اگر Consumer نتواند پیام خاصی را پردازش کند، پلتفرم پیام رسانی معمولاً پیام را به Queue ای که در دسترس سایر Consumer ها قرار گرفته است بر می‌گرداند. علاوه بر جداسازی زمانی، Queue ها به ما اجازه می‌دهند Producer ها و Consumer ها را به‌طور مستقل دسته بندی کنیم. همچنین می‌توانیم درجه‌ای از Fault-tolerance را در برابر خطاهای پردازش فراهم آوریم.
به بیان ساده، داکر (Docker) یک پلتفرم نرم‌افزاری است که عملیات ساخت، اجرا، مدیریت و توزیع اپلیکیشن‌ها را ساده‌تر میکند. داکر این ساده‌سازی فرایند ایجاد اپلیکیشن‌ها را به وسیله مجازی‌سازی سیستم عامل کامپیوتری انجام می‌دهد که اپلیکیشن قرار است روی آن نصب و اجرا شود. در واقع، داکر مجموعه‌ای از محصولات پلتفرم به عنوان یک سرویس (PaaS) است که از مجازی‌سازی در سطح سیستم عامل برای تولید بسته‌های نرم‌افزاری استفاده میکند. اولین نسخه از داکر در سال ۱۳۹۲ خورشیدی (۲۰۱۳ میلادی) منتشر شد.
با کمک داکر و کانتینرها میتوان فرایند استقرار را به حداقل وابستگی به سیستم عامل و سایر تنظیمات محیط استقرار رساند.
کوبرنیتیس حاصل سالها تجربه گوگل در زمینه بار کاری در مقیاس بزرگ تولید است طبق سایت کوبرنیتیس ,کوبرنیتیس یک سیستم منبع باز برای خودکار سازی استقرار ، مقیاس گذاری و مدیریت برنامه های کانتینر شده است. اگر بخواهیم به‌زبان ساده کوبرنتیز را توضیح دهیم باید بگوییم کوبرنتیز اجرا و مدیریت کانتینرهای مختلف را در سرورهای متفاوت که در یک پایگاه داده یا چندین پایگاه قرار گرفته‌اند را بر عهده می‌گیرد. در کوبرنتیز کانتینرهای مختلفی که مشترکاً برنامه کاربردی خاصی را شامل می‌شوند در حالت جداگانه و مستقل تحت عنوان پاد (Pod) دسته‌بندی خواهند شد. این کار فرآیند مدیریت و شناسایی آنها را ساده‌تر میکند.از ویژگی های بارز K8s می توان به auto-scaling,load-balancing,volume management, secret management و web UI اشاره کرد.این ویژگی ها باعث میشود این نوع نسبت به همتاهای خودش کمتر وابسته به ابزار های third-party باشد.
اطلاعات جمع آوری شده برای مانیتورینگ می توانند به صورت آنی فقط برای نمایش لحظه ای مورد استفاده قرار بگیرند. اما در بیشتر مواقع شما نیاز خواهید داشت که اطلاعات جمع آوری شده را برای مدت طولانی نگهداری کنید و بتوانید در هر زمان با سریع ترین روش به آن ها دسترسی پیدا کنید. یکی از روش های ذخیره سازی استفاده از ابزاری با نام elasticsearch خواهد بود که اطلاعات را دریافت، ایندکس و ذخیره سازی می کند و با ارائه فیلتر های مناسب امکان query های مورد نظر شما را فراهم میکند.
این ابزار قابلیت scale شدن به صورت افقی را داشته و می توان از آن در محیط های با پردازش سنگین داده که قابلیت تخصیص منابع یکپارچه در سیستم را ندارند استفاده نمود. به طور کلی قلب elk این ابزار می باشد.
از قابلیت های این ابزار دریافت اطلاعات به صورت داده های خطی یا raw دیتا می باشد که پس از پردازش و تحلیل این خطوط داده آنها را normalize کرده و آن ها را ذخیره سازی میکند. امکانات این ابزار بیشتر در زمان نمایش داده ها نشان داده خواهد شد.
الاستیک سرچ(Elastic Search)هسته اصلی در Elk می باشد. تمام فرایند های ذخیره سازی و ایندکسینگ در این ابزار انجام میپذیرد. نوع ذخیره سازی document-oriented می باشد و ساختار ذخیره سازی به صورت JSON خواهد بود.
برای زیرنظر داشتن منابع ، سرورها ، لینک های ارتباطی ابزارهای زیادی وجود دارد که Prometheus، OPmanager دوتا از آنها هستند.
این ابزارها اطلاعات زیادی از قبیل میزان و درصد استفاده از سخت افزارها مانند cpu , ram و لینک ها (bandwidth) را نشان می دهند.
تجزیه و تحلیل استاتیک که به آن تحلیل کد استاتیک نیز می گویند، روشی برای اشکال زدایی برنامه های کامپیوتری است که با بررسی کد بدون اجرای برنامه انجام می شود. این فرآیند درک ساختار کد را فراهم می کند و می تواند به اطمینان حاصل شود که کد به استانداردهای صنعت پایبند است.
تحویل مداوم کل فرآیند انتشار نرم افزار را خودکار می کند. هر تجدیدنظری که انجام میشود جریان خودکاری را ایجاد میکند که به‌روزرسانی را ایجاد، آزمایش و سپس مرحله‌بندی میکند. تصمیم نهایی برای استقرار در یک محیط تولید زنده توسط توسعه دهنده انجام می شود.
یک روش احراز هویت است که به کاربران امکان می دهد تا با استفاده از یک مجموعه از اعتبارنامه ها به طور ایمن با چندین برنامه و وب سایت احراز هویت کنند.
مش سرویس یک لایه پلت فرم در بالای لایه زیرساخت است که ارتباط مدیریت شده، قابل مشاهده و ایمن را بین خدمات فردی امکان پذیر می کند. این لایه پلت فرم به شرکت ها یا افراد امکان می دهد تا برنامه های کاربردی سازمانی قوی ایجاد کنند که از ریزسرویس های زیادی بر روی یک زیرساخت انتخابی تشکیل شده است.
1.https://en.wikipedia.org/wiki/Domain-driven_design
2.https://sokanacademy.com/blog/%D9%85%D8%B9%D8%B1%D9%81%DB%8C%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-domain-driven-design
3.https://virgool.io/@nejatian/hexagonal-architecture-vsrs66imt2ij
4.http://domaindrivendesign.ir/dddd7-ports-and-adapters-tdd/
5.https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs
6.https://www.techtarget.com/searchapparchitecture/definition/CQRS-command-query-responsibility-segregation
7.https://www.techtarget.com/whatis/definition/Model-View-ViewModel#:~:text=Model%2DView%2DViewModel%20(MVVM)%20is%20a%20software%20design,Ken%20Cooper%20and%20John%20Gossman.
8.https://lamtakam.com/qanda/2520/%D8%A7%DB%8C%D9%88%D9%86%D8%AA-%D8%B3%D9%88%D8%B1%D8%B3%DB%8C%D9%86%DA%AF-event-sourcing-%DA%86%DB%8C%D8%B3%D8%AA-%D9%88-%DA%86%D9%87-%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1%D8%AF%DB%8C-%D8%AF%D8%A7%D8%B1%D8%AF%D8%9F
9.https://bugeto.net/blog/micro-frontends-by-example
10.https://www.dntips.ir/post/3350/%D8%AA%D9%88%D8%B3%D8%B9%D9%87%E2%80%8C%DB%8C-micro-frontends-%D8%A8%D8%A7-webpack
11.https://blog.faradars.org/what-is-low-code-development/
12.https://platco.ir/services/integration-web-services/enterprise-service-bus/
13.https://samix.org/what-is-bpms/
14.https://virgool.io/@faezehmonta1995/%D8%A2%D8%B4%D9%86%D8%A7%D9%8A%D9%8A-%D8%A8%D8%A7-business-rule-management-system-iarquem6t1k1
15.https://mirbozorgi.com/rabbitmq-vs-kafka/
16.https://poshtiban.com/blog/introduction-to-kubernetes-and-orchestration/
17.https://linuxlearn.org/docker-orchestration/
18.https://aws.amazon.com/devops/continuous-delivery/
