<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های نیوشا محمودی</title>
        <link>https://virgool.io/feed/@mahmoudi.nioosha</link>
        <description>دانشجوی کارشناسی ارشد فناوری اطلاعات دانشگاه شهید بهشتی</description>
        <language>fa</language>
        <pubDate>2026-06-16 15:14:33</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/1909382/avatar/L79l1c.jpg?height=120&amp;width=120</url>
            <title>نیوشا محمودی</title>
            <link>https://virgool.io/@mahmoudi.nioosha</link>
        </image>

                    <item>
                <title>معماری نرم افزار در نرم افزارهای پردازش داده های حجیم</title>
                <link>https://virgool.io/@mahmoudi.nioosha/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%AF%D8%B1-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1%D9%87%D8%A7%DB%8C-%D9%BE%D8%B1%D8%AF%D8%A7%D8%B2%D8%B4-%D8%AF%D8%A7%D8%AF%D9%87-%D9%87%D8%A7%DB%8C-%D8%AD%D8%AC%DB%8C%D9%85-wum1xhfqxcvx</link>
                <description>چکیدهامروزه با زیاد شدن اطلاعات و حجم داده های نرم افزاری، مبحث داده های حجیم (Big Data) و پردازش آن ها به یکی از مباحث روز صنعت نرم افزار تبدیل شده است. مبحث داده های حجیم از بخش های مختلفی مانند: چگونگی استخراج اطلاعات، نحوه ذخیره سازی داده ها، پیش پردازش و پردازش داده ها، تجزیه و تحلیل داده ­ها و ... تشکیل شده است. در واقع این سیستم ها نیازمندی‌های متفاوتی با سایر سیستم ها دارند و به همین دلیل است که معماری به کار برده شده در آن ها نیز با معماری به کار گرفته شده سایر نرم افزار ها متفاوت است. لذا توسعه این نوع نرم افزار ها نیازمند رعایت یک سری چارچوب و قوانین و به طور کلی استفاده از معماری های اصولی می باشد. ما در این تحقیق قصد داریم تا ابتدا به طور کلی با مفهوم داده های حجیم و نحوه پردازش آن ها آشنا شویم. سپس نقش و اهمیت معماری نرم افزار در نرم افزارهایی که وظیفه شان پردازش این اطلاعات و داده های حجیم است را بررسی کرده و نهایتا معماری های موجود در این زمینه را طبقه بندی خواهیم کرد.کلمات کلیدی: معماری نرم افزار، داده های حجیم، پردازش داده، الگوی طراحی1- مقدمهدر این بخش قصد داریم تا به طور کلی با مفاهیم داده های حجیم و نحوه پردازش آن ها آشنا شویم. امروزه در دنیای دیجیتال پیرامون ما، در یک مدت زمان کوتاه، حجم بسیار زیادی داده تولید و ذخیره شده است. این رشد سریع حجم داده ها، چالش های زیادی را ایجاد کرده است. در ادامه این فصل با مفهوم داده های حجیم و ویژگی آنان و همچنین روش هایی که برای پردازش آن ها وجود دارد آشنا خواهیم شد.1.1- مفهوم داده های حجیم:داده های حجیم تعاریف مختلف و گوناگونی دارد. اما یک تعریف مناسب برای داده های حجیم که در مرجع [15] ذکر شده است به شرح زیر می باشد:داده های حجیم داده هایی هستند که بیش از اندازه بزرگ و پیچیده هستند و نمی توان با روش های سنتی پردازش داده آن ها را پردازش کرد. همچنین بسیاری از دانشمندان داده و مراجع، از جمله مرجع [12]، سه ویژگی: حجم، سرعت و تنوع را به داده های حجیم نسبت می دهند:سه ویژگی اصلی داده های حجیم حجم (Volume): همانطور که از نام داده های حجیم نیز پیداست، اصلی ترین ویژگی داده های حجیم این است که اندازه شان بسیار زیاد است. روزانه مقدار بسیار زیادی داده از میلیون ها دستگاه و برنامه مانند ICT، تلفن های هوشمند، کدهای محصولات، شبکه های اجتماعی، حسگرها، گزارش ها و ... تولید می شود. سرعت (Velocity): سرعت در این جا به معنی سریع بودن رشد تعداد داده ها می باشد. سرعت رشد داده های حجیم بسیار زیاد است و به صورت مداوم تولید می شوند. به عنوان مثال در والمارت (یک فروشگاه زنجیره ای بین المللی) در هر ساعت، حدود 1 میلیون مشتری باعث تولید بیش از 2.5 پتابایت (هر پتابایت معادل 1000 ترابایت) داده غیر ساختار یافته می شوند.  تنوع (Variety): داده های حجیم از منابع مختلف توزیع شده و در قالب های مختلف (به عنوان مثال، فیلم ها، اسناد، نظرات، گزارش ها) تولید می شوند. داده های حجیم می توانند ساختار یافته یا بدون ساختار، عمومی یا خصوصی، محلی یا دور، مشترک یا محرمانه، کامل یا ناقص و ... باشند.2.1- پردازش داده های حجیم:برای پردازش و استخراج دانش از داده های حجیم، مدل ها، برنامه ها، نرم افزارها، سخت افزارها و فناوری های مختلفی طراحی و پیشنهاد شده است. در مرجع [14] پردازش داده های حجیم به این صورت تعریف شده است: به طور کلی پردازش داده های حجیم، شامل فناوری ها و مدل های برنامه نویسی ای می باشد که اطلاعات مفید را داده های حجیم استخراج کرده و به فرآیند تصمیم گیری کمک می کنند. در واقع پردازش داده به معنی استخراج اطلاعات مفید (Information) از داده های خام (raw data) می باشد. آن چه باید به آن توجه کرد این است که روش های پردازش داده های حجیم با روش های معمول پردازش داده تفاوت دارد و چالش های زیادی دارد، چرا که همانطور که در فصل قبل دیدیم، داده های حجیم ویژگی هایی دارد که آن را از سایر داده ها متمایز می کند. مثلا ممکن است فرمت داده ها با یکدیگر کاملا متفاوت باشد، در این صورت نمی توان صرفا به استفاده از یک روش بسنده کرد. لذا همانطور که در مرجع [16] بیان شده است، پردازش داده های حجیم به طور کلی شامل مراحل و قدم های زیر می شود: (سه گام نخست به ETL نیز معروف هستند)استخراج داده: اولین گام در پردازش داده های حجیم استخراج آنهاست. داده های حجیم از منابع مختلف و گوناگونی استخراج می شوند که فرمت های مختلفی نیز دارند. این منابع می توانند انواع وبسایت یا اپلیکیشن یا پایگاه داده یا ... باشند.تبدیل داده: دومین گام در پردازش داده های حجیم تبدیل داده های استخراج شده به فرمت مورد نظر است. در این گام داده ها ضمت حفظ مفهوم خود، به فرمت و ساختار مورد نظر تغییر می یابند.بارگذاری داده: سومین گام در پردازش داده های بارگذاری داده ها در یک مرکز جهت انجام مراحل بعدی می باشد. داده هایی که در مراحل قبل استخراج شدند و فرمتشان تغییر کرد، حال در یک مکان مشخص (مانند پایگاه داده) ذخیره و بارگذاری می شوند.مصور سازی و تحلیل داده: چهارمین گام در پردازش داده های حجیم مصورسازی این داده هاست. به کمک ابزارهای هوش تجاری می توان یک دید کلی از داده ها و فرآیندهای کسب و کار که باعث تغییر داده ها می شوند به دست آورد. همچنین به کمک ابزار های هوش تجاری (مانند Power BI) می توان پیش بینی های مختلفی از کسب و کار انجام داد و تحلیل های گوناگونی انجام داد و تصمیمات مختلفی گرفت.استفاده از روش های یادگیری ماشین: تنها بدست آوردن یک دید از کسب و کار و داده ها کافی نیست و ما باید بتوانیم نسبت به ورودی های جدید نیز واکنش نشان بدهیم. الگوریتم های یادگری ماشین علاوه بر اینکه خودشان ورودی های جدید را نیز تحلیل و طبقه بندی می کنند، سرعت بسیار بالایی نیز دارند و می توان حجم زیادی از داده ها را به کمک آن ها تحلیل کرد. مفاهیمی مانند یادگیری عمیق (Deep Learning)، یادگیری فعال (Active Learning)، یادگیری برخط (Online Learning) و ... در این حوزه قرار می گیرند.در بخش بعدی ابتدا اهمیت و لزوم استفاده از معماری نرم افزار را بیان کرده و پس از آن به طبقه بندی معماری ها و الگوریتم های پردازش داده های حجیم خواهیم پرداخت. 2- ضرورت و اهمیت استفاده از معماری نرم افزاردر این بخش قصد داریم تا با ضرورت استفاده از معماری نرم افزار در فرآیند پردازش داده های آشنا شویم. به طور کلی استفاده از معماری و الگوریتم های نوین نرم افزاری باعث افزایش درک اشخاص از نرم افزار و بهبود ویژگی های کیفی (مانند مقیاس پذیری، قابلیت استفاده مجدد قابلیت تغییر و ...) می شود. اما همانطور که دیدیم فرآیند پردازش داده های حجیم یک فرآیند سنگین و پیچیده است. به طور کلی دلایل زیر را می توان از اهمیت های استفاده از الگو های طراحی و معماری نرم افزار در فرآیند پردازش داده های حجیم بیان کرد:1- افزایش سرعت: یکی از مهم ترین فاکتور هایی که در فرآیند پردازش داده باید به آن اشاره کرد سرعت است. از آنجایی که حجم داده هایی که قرار است پردازش شوند بسیار زیاد است، اگر بخواهیم از روش های سنتی پردازش داده استفاده کنیم زمان زیادی را از دست خواهیم داد. استفاده از الگو ها و معماری های نوین این امکان را فراهم می کند تا این فرآیند سریع تر انجام شود.2- بهبود نتیجه: بسیاری از الگو ها و معماری ها برای رسیدن به نتیجه بهتر ابداع شده اند. در بسیاری از مواقع این الگو ها و معماری های نرم افزاری جدید بوده اند که باعث شده اند تا بتوانیم به هدف و نتیجه نهایی مطلوب خود برسیم.3- افزایش مقیاس پذیری: استفاده از الگو های معماری باعث بهبود ویژگی های غیر عملکردی نرم افزار می شوند که مقیاس پذیری (Scalability) یکی از این ویژگی ها است. در حوزه داده های حجیم، حجم داده ها مدام در حال بیشتر شدن است و منابع تولید کننده آن ها نیز رو به افزایش هستند. همچنین اهداف ما نیز روز به روز تکامل می یابند. داشتن یک معماری خوب می تواند به مقیاس پذیری فرآیند پردازش این داده های حجیم کمک شایاین بکند.4- و ...فواید داشتن یک معماری نرم افزار خوب صرفا به موارد بالا محدود نمی شود. در این بخش سعی کردیم تا تعداد کمی از این فواید را ببینیم تا با ضرورت استفاده از معماری نرم افزار در فرآیند پردازش داده آشنا بشویم.3- معماری ها و الگوریتم های پردازش داده های حجیمبرای پردازش داده های حجیم، الگوهای طراحی، روش ها، مدل ها و الگوریتم های گوناگونی عنوان شده اند که می توان از دید معماری نرم افزار به آن ها نگاه کرد و  آن ها را به عنوان زیرشاخه ای از معماری نرم افزار دانست. ما در این بخش ابتدا قصد داریم تا تعدادی از معماری نرم افزار های معروف در حوزه پردازش داده های حجیم را معرفی کرده و سپس در ادامه فصل آن ها را طبقه بندی خواهیم کرد.1.3- سیستم های دریاچه داده (Data Lake) و انبار داده (Data Warehouse):هنگامی که با حجم زیادی از داده ها مواجه هستیم، دو رویکرد کلی ETL و ELT برای آماده کردن این داده ها برای پردازش های بعدی وجود دارد. اولین رویکرد که به ETL معروف است، ابتدا داده ها را جمع آوری کرده، سپس فرمت ها و ساختار های داده را تغییر کرده و آن ها را تمیز کرده و در نهایت آن ها را در یک مکان نهایی که به آن Data warehouse می گویند بارگذاری می کند تا آماده پردازش و تحلیل های بعدی شوند.دومین رویکرد به ELT معروف است و فرق آن با ETL در این است که ابتدا تمام داده ها با تمام فرمت ها و ساختار ها در یک مکان به نام Data Lake بارگذاری می شوند. سپس هر موقع نیاز به پردازش و تخلیل داشتیم، باید داده های مورد نظر را از این دریاچه داده برداشته و پردازش و تحلیل را روی آن انجام می دهیم.مقایسه ETL با ELTدر واقع تفاوت ETL با ELT در این است که در ETL ابتدا داده ها را برای پردازش آماده می کنیم، اما در ELT هر موقع نیاز به پردازش داشتیم اقدام به آماده کردن داده ها می کنیم.یکی از ابزارهای معروفی که هم از ETL و هم از ELT پشتیبانی می کند و امکان پردازش داده ها را نیز در خود دارد ابزار SnowFlake است. معماری SnowFlake به شرح زیر است:معماری SnowFlakeبه کمک این ابزار می توان داده ها را جمع آوری کرد و انواع تحلیل های هوش تجاری را در سریع ترین زمان ممکن (حتی سریع تر از SQL) انجام داد.یکی دیگر از ابزارهای پرکاربرد و معروف این حوزه Azure Data lake می باشد که این ابزار هم امکان ذخیره سازی داده های حجیم و پردازش آن ها را فراهم کرده است. این ابزار از U-SQL که ترکیبی از SQL و C# است برای پردازش داده های استفاده می کند.2.3- مدل مپ ردیوس (Map Reduce):مپ ردیوس در واقع یک مدل برنامه نویسی است که در سال 2004 توسط گوگل معرفی شده است [11]. این الگوریتم داده ها را به صورت توزیع شده پردازش می کند و از  دو عمل مهم مپ (Map) و ردیوس (Reduce) تشکیل شده است. مثالی از الگوریتم MapReduceفرض کنید می خواهیم در یک متن بلند، تعداد تکرار هر کلمه را پیدا کنیم و کلمات بسیار زیادی در این متن وجود دارد. ما اگر بخواهیم به روش سنتی و غیر توزیع شده این کار را انجام بدهیم، زمان و منابع زیادی هدر می رود. ایده اصلی الگوریتم مپ ردیوس این است که این پردازش به صورت توزیع شده و موازی انجام شود. ابتدا این متن را به چند متن کوچک تر تقسیم می کنیم (Split). سپس در هر قسمت به صورت مجزا تعداد تکرار هر کلمه در متن کوچک شده را به صورت (key, value) که key خود کلمه و value تعداد تکرار آن است محاسبه می کنیم (Map). در گام بعدی نتایج را مرتب سازی می کنیم تا برای جمع زدن آماده بشوند (Shuffle). در نهایت نیز نتایجی که از هر قسمت به دست آمده بود با یکدیگر جمع می شوند تا نتیجه نهایی که تعداد تکرار هر کلمه در متن اصلی است به دست بیاید (Reduce).مثال فوق یک مثال ساده از این الگوریتم بود و امروزه از این الگوریتم در بسیاری از پردازش های سنگین داده های حجیم استفاده می شود. مزیت عمده ای که این الگوریتم دارد این است که امکان پردازش به صورت توزیع شده را فراهم می کند. در روش سنتی تمام پردازش ها بر عهده یک پردازنده و برنامه واحد است، در صورتی که به کمک الگوریتم مپ ردیوس می توان این پردازش را بین پردازنده ها و ماشین های مختلف توزیع کرد و مقیاس پذیری را افزایش داد [8].ابزار آپاچی هدوپ (Apache Hadoop) پر استفاده ترین پیاده سازی منبع باز از الگوریتم مپ ردیوس است [10] که کلیات آن را در شکل زیر میبینیم:معماری هدوپبه طور کلی، معماری هدوپ امکان ذخیره سازی و پردازش و تحلیل داده ها را فراهم می کند. سیستم توزیع شده فایل هدوپ یا همان Hadoop distributed file system یا به اختصار HDFS، سیستم فایل هدوپ است که داده ها را مدیریت کرده و امکان دسترسی به داده ها را فراهم میکند. در معماری هدوپ، مپ ردیوس به عنوان پردازش کننده داده های خوشه ها به صورت توزیع شده عمل می کند که کاربرد آن را با ذکر مثال دیدیم. فناوری YARN نیز در نسخه جدید هدوپ اضافه شده که وظیفه مدیریت منابع را بر عهده گرفته است.3.3- الگوریتم گراف جهت دار بدون دور (DAG):گراف جهت دار بدون دور (Directed Acyclic Graph) یا به اختصار DAG، یک پارادایم برای تحلیل و پردازش داده های پیچیده می باشد و اغلب به صورت توزیع شده و بر بستر ابر (Cloud) عمل می کند. DAG یک نوع گراف است که هر گره آن نشان دهنده یک Task است که در آن دور وجود ندارد:گراف جهت دار بدون دورمعماری DAG نشان گر کلیات فرآیند پردازش داده های ورودی می باشد. در هر گره که نشان گر یک Task به خصوص است، یک سری پردازش خاص روی داده ها انجام می گیرد. این گراف روند منطقی پردازش داده ورودی را به تصویر میکشد. با پیاده سازی این گراف، امکان پردازش موازی (parallel) فراهم میشود و چندین Task می توانند به صورت همزمان با هم انجام شوند. گرچه ممکن است یک Task برای اجرا نیاز به خروجی یک Task دیگر داشته باشد که در این صورت باید منتظر آن بماند.ابزار Apache Spark یک ابزار معروف برای پردازش داده های حجیم با سرعت بالا است که قابلیت های زیادی مانند: بهینه سازی کوئری و سیستم کشینگ درون حافظه و ... دارد. این ابزار در گردش کار (work flow) خود از مفهوم DAG کمک گرفته است، به این صورت که راس ها نشان گر سیستم های توزیع شده انعطاف پذیر (RDD) و یال ها همان عملیاتی هستند که قرار است روی RDD ها انجام بشوند. سایت معروف نتفلیکس از این ابزار برای درک سلیقه مخاطبان ارائه پیشنهاد به آنان استفاده می کند [18]. ابزار Apache Storm یکی دیگر از این ابزار ها است که از DAG استفاده می کند و سرعت بالایی نیز دارد. این بزار تفاوت های جزیی با Apache spark دارد، مثلا Apache storm محاسبات Task ها را موازی سازی می کند، در حالی که Apache Spark محاسبات داده ها را موازی سازی می کند. 4.3- روش پردازش دسته ای (Batch Processing):روش پردازش دسته زمانی به کار می آید که حجم زیادی از داده هایی داشته باشیم که تقریبا تکراری هستند و مفهوم یکسان اما مقادیر متفاوتی دارند. در این روش داده ها به صورت دوره ای (Periodic) مثلا هر روز یا هر هفته یا هر ماه و بدون دخالت کاربر توسط سیستم پردازش می شوند. پردازش دسته ایبه عنوان مثال انتقال وجه پایا را در نظر بگیرید. در این نوع انتقال وجه پول همان لحظه به حساب مبدا واریز نمی شود و در ساعت های خاص روز (مثلا ساعت 4 و 10 و 14 و 18) به حساب مقصد واریز می شوند. در بین این ساعت ها مشتریان در حال انتقال وجه هستند و فرم های پایا را پر می کنند، اما سیستم مرکزی بانک در همان لحظه به آنان پاسخ نمی دهد، بلکه در ساعت های خاص روز، هر آن چه انتقال پایا که ثبت شده و پردازش نشده را پردازش کرده و در صورت تایید وجه را به حساب مقصد واریز می کند. این پردازش در ساعات خاص روز اتفاق می افتد و می تواند شامل عملیات مختلفی مانند برسی صحت مبلغ یا صحت اسناد عدم پولشویی یا ... باشد.یک مثال دیگر ارسال مرسولات پستی می باشد. یک فروشگاه آنلاین بزرگ را در نظر بگیرید که روزانه تعداد زیادی سفارش دارد. طبیعتا هر سفارش پس از ثبت باید توسط پست تحویل مشتری گردد. اگر ادمین سیستم بخواهد بلافاصله بعد از هر سفارش، کالای مورد نظر مشتری را از انبار بیرون بیاورد و به اداره پست برود و آن را برای مشتری ارسال کند، در طی روز باید به تعداد سفارشات به اداره پست مراجعه کند که باعث اتلاف وقت و انرژی و حتی منابع مالی زیادی می شود. اما به کمک پردازش دسته ای، ادمین سیستم هر روز در یک ساعت خاص (مثلا هر روز 9 صبح) لیست سفارشات روز گذشته را پردازش کرده و تمام کالا ها را از انبار بیرون آورده و هنگامی که به اداره پست مراجعه می کند به جای ارسال 1 بسته، تمام آن بسته را برای مقصد های مختلف مشتریان ارسال می کند.مزایای عمده این روش صرفه جویی در منابع و افزایش توانایی نظارت می باشند. از معایب این روش می توان به احتمال افزایش تعداد خطا (مثلا فرض کنید سیستم پست در آن ساعات دچار اشکال باشد در نتیجه هیچ کدام از سفارشات ارسال نخواهند شد) و افزایش کلی زمان پردازش (در مثال اول مشتری باید چند ساعت منتظر بماند تا وجه به حسابش واریز شود) اشاره کرد.4- نتیجه گیریدر این مقاله سعی کردیم تا معماری های معروف در حوزه پردازش داده های حجیم را بیان کنیم. واضح است که مواردی که در این مقاله ذکر شدند تمام معماری های موجود نیستند و تعداد بسیار زیادی معماری برای پردازش داده های حجیم وجود دارد. اگر بخواهیم یک طبقه بندی از معماری های نرم افزار در حوزه پردازش داده های حجیم داشته باشیم، به شکل زیر می رسیم:طبقه بندی معماری های نرم افزار برای پردازش داده های حجیم همانطور که در شکل فوق نیز مشخص شده است، معماری نرم افزار می تواند شامل سیستم، مدل، الگوریتم، روش، الگوهای معماری و الگوهای طراحی و ... بشود. ما در این مقاله سعی کردیم تا روش های معروف موجود را توضیح داده و در یکی از 4 دسته بندی: سیستم، مدل، الگوریتم و روش قرار بدهیم. طبیعتا سیستم درشت دانه تر از سایر دسته ها می باشد. مفاهیم مرتبط با هر دسته بندی با رنگ نارنجی و فناوری های موجود در آخرین سط و با رنگ خاکستری نشان داده شده اند.این مقاله یک مرور کلی بر معماری ها و فناوری های نوین در حوزه پردازش داده های حجیم بود و در آینده می توان روش های مرتبط با هوش مصنوعی در پردازش داده های حجیم را نیز مورد بحث و برسی قرار داد.«این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.»منابع[1] Silvestri, Stefano, et al. &quot;A big data architecture for the extraction and analysis of EHR data.&quot; 2019 IEEE World Congress on Services (SERVICES). Vol. 2642. IEEE, 2019.[2] Arooj, Ansif, et al. &quot;Big data processing and analysis in internet of vehicles: architecture, taxonomy, and open research challenges.&quot; Archives of Computational Methods in Engineering 29.2 (2022): 793-829.[3] Kumar, S. Rakesh, et al. &quot;Medical big data mining and processing in e-healthcare.&quot; Internet of things in biomedical engineering. Academic Press, 2019. 323-339.[4] Habeeb, Riyaz Ahamed Ariyaluran, et al. &quot;Real-time big data processing for anomaly detection: A survey.&quot; International Journal of Information Management 45 (2019): 289-307.[5] Shakhovska, Natalya. &quot;The method of Big data processing.&quot; 2017 12th international scientific and technical conference on computer sciences and information technologies (CSIT). Vol. 1. IEEE, 2017.[6] Qiu, Junfei, et al. &quot;A survey of machine learning for big data processing.&quot; EURASIP Journal on Advances in Signal Processing 2016 (2016): 1-16.[7] Boranbayev, Seilkhan, et al. &quot;Method of processing big data.&quot; Information Technology-New Generations: 15th International Conference on Information Technology. Springer International Publishing, 2018.[8] Sharma, Diksha, Gagan Pabby, and Neeraj Kumar. &quot;Challenges involved in big data processing &amp; methods to solve big data processing problems.&quot; IJRASET 5.8 (2017): 841-844.[9] Lehmann, Claude, et al. &quot;Big Data architecture for intelligent maintenance: a focus on query processing and machine learning algorithms.&quot; Journal of Big Data 7.1 (2020): 1-26.[10] Belcastro, Loris, Fabrizio Marozzo, and Domenico Talia. &quot;Programming models and systems for big data analysis.&quot; International Journal of Parallel, Emergent and Distributed Systems 34.6 (2019): 632-652.[11] Suvarnamukhi, B., and M. Seshashayee. &quot;Big data concepts and techniques in data processing.&quot; International Journal of Computer Sciences and Engineering 6.10 (2018): 712-714.[12] https://www.optalitix.com/guides/what-are-the-3-vs-of-big-data/#:~:text=These%20are%20the%203%20V&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;#x27;s,%3A%20volume%2C%20velocity%20and%20variety.[13] https://www.projectpro.io/article/how-big-data-analysis-helped-increase-walmarts-sales-turnover/109#:~:text=American%20multinational%20retail%20giant%20Walmart,text%20or%20one%20quadrillion%20bytes.[14] https://www.sciencedirect.com/topics/computer-science/big-data-processing#:~:text=Big%20data%20processing%20is%20a,big%20data%20analysis%20in%20datacenters.[15] https://en.wikipedia.org/wiki/Big_data[16] https://hevodata.com/learn/big-data-processing/#Stages-in-the-Big-Data-Processing[17] https://data-flair.training/blogs/hadoop-architecture[18] https://www.projectpro.io/article/top-5-apache-spark-use-cases/271#:~:text=video%20viewing%20experience.-,Apache%20Spark%20at%20Netflix,a%20vital%20role%20in%20personalization.[19] https://k21academy.com/microsoft-azure/data-engineer/batch-processing-vs-stream-processing/[20] https://people.cs.rutgers.edu</description>
                <category>نیوشا محمودی</category>
                <author>نیوشا محمودی</author>
                <pubDate>Sat, 04 Feb 2023 15:20:41 +0330</pubDate>
            </item>
                    <item>
                <title>API Gateway</title>
                <link>https://virgool.io/@mahmoudi.nioosha/api-gateway-jgoxwvvg6qmr</link>
                <description>در این پست می‌خواهیم در مورد API Gateway نکاتی را مطرح کنیم. ابتدا تعاریف مربوط به API، API Gateway را عنوان کرده و در ادامه درباره کاربردهای API Gateway و نحوه کار آن صحبت می‌کنیم و در انتها هم در مورد ابزارهای متن باز و شرکت‌های ایرانی ارائه دهنده مدیریت API مطالبی را مطرح می‌کنیم.در صورتی که به مطالب مربوط به API علاقه‌مند هستید و در عین حال زمان زیادی را نمیخواهید صرف کنید این پست می‌تواند به منظور آشنایی با کلیات برای شما مفید باشد. در پایان منابع دکر شده است که در صورت تمایل به کسب اطلاعات بیشتر می‌توانید به آن‌ها مراجعه کنید. رابط برنامه نویسی برنامه (API) چیست؟در ابتدا لازم است با مفهوم API آشنا شویم اما از آنجایی که امروزه اکثر افراد فعال در حوزه نرم‌افزار با آن آشنا هستند، صرفا یک تعریف مختصر از آن را بیان می‌کنیم. رابط برنامه نویسی برنامه (API)، مکانیسمی است که دو جزء نرم‌افزاری را قادر می‌سازد که طبق یک سری استاندارد و پروتکل بدون آن که از جزییات پیاده‌سازی هم اطلاع داشته باشند با یکدیگر ارتباط برقرار کنند. این رابط یک قرارداد سرویس است بین دو برنامه کاربردی است که نحوه ارتباط از طریق پرسش‌ها و پاسخ‌ها را تعریف میکند.رابط برنامه‌نویسی برنامه یا API مزایای بسیاری دارد. احتمالا مهمترین مزیت آن این است که شرکت‌ها را قادر می‌سازد تا داده‌ها و عملکرد برنامه‌های خود را برای توسعه‌دهندگان شخص ثالث خارجی، شرکای تجاری و بخش‌های داخلی شرکت‌شان باز کنند. به این ترتیب خدمات و محصولات با یکدیگر ارتباط برقرار کرده و از طریق یک رابط مستند از داده‌ها و عملکرد یکدیگر استفاده کنند. توسعه دهندگان نیازی به دانستن نحوه پیاده سازی یک API ندارند. آنها به سادگی از رابط برای ارتباط با سایر محصولات و خدمات استفاده می کنند. استفاده از API در دهه گذشته افزایش یافته است، به حدی که امروزه بسیاری از محبوب‌ترین برنامه‌های وب بدون API امکان‌پذیر نیستند.هیچ اپلیکیشنی جزیره نیست یعنی هیچ برنامه‌ای به تنهایی برای طولانی مدت ارزش تجاری را ارائه نمی‌کند. برنامه‌ها باید به سرمایه‌گذاری‌های فناوری موجود و آینده شما متصل شوند تا ارزش مستمری ارائه دهند و در واقع به عنوان بخشی از تجارت شما وجود داشته باشند. API ها روشی استاندارد برای ادغام اجزای نرم افزاری در اختیار شما قرار می دهند، بدون آنکه نیاز باشد با به روزرسانی یک بخش یا معرفی بخش‌های جدید دیگر بخش‌ها را بازسازی کنید. رابط برنامه نویسی برنامه چگونه کار می‌کند؟API Gateway چیست؟API Gateway یک ابزار مدیریت API و واسطی بین کلاینت و سرویس‌های backend می‌باشد. در واقع یک API Gateway مانند یک پروکسی معکوس عمل می‌کند و همه فراخوانی‌های API را می پذیرد سپس سرویس‌های مورد نیاز آن‌ها را جمع‌آوری کرده و نتیجه مناسب را برمی‌گرداند. یک API Gateway علاوه بر دریافت درخواست کاربر، هدایت آن درخواست به سرویس‌های پشتیبان، جمع‌آوری داده‌های مورد نیاز و تحویل یک بسته ترکیبی به عنوان پاسخ، در زمینه تجزیه و تحلیل، خدمات امنیتی و جلوگیری از تهدید را نیز فراهم می‌آورد.API Gatewayدر شکل زیر نمونه‌ای دیگر از یک API Gateway به همراه میکروسرویس‌هایی که در یک شرکت تجارت الکترونیک وجود دارد آورده شده است:API Gatewayچرا از API Gateway استفاده کنیم؟اکثر API های سازمانی از طریق API Gateway مستقر می شوند. یکی از وظایف رایج API Gatewayها این است که کارهایی مانند احراز هویت کاربر، محدود کردن نرخ و آمار را که در بین سرویس‌های API یک سیستم مشترک هستند، انجام دهند.در حالت بسیار ساده، یک سرویس API یک درخواست از راه دور را می پذیرد و یک پاسخ را برمی گرداند. اما واقعیت این است که دنیای حقیقی هرگز به این سادگی نیست و نگرانی‌های مختلفی در زمان میزبانی از APIهای مقیاس بزرگ وجود داردو در ادامه برخی از این نگرانی‌ها را مطرح می‌کنیم.شما می خواهید از API های خود در برابر استفاده بیش از حد و سوء استفاده محافظت کنید، بنابراین از یک سرویس احراز هویت و محدودیت نرخ استفاده می کنید.شما می خواهید بدانید که مردم چگونه از API های شما استفاده می کنند، بنابراین ابزارهای تجزیه و تحلیل و نظارت را اضافه کرده اید.اگر APIهای کسب درآمد دارید، می‌خواهید به یک سیستم صورت‌حساب متصل شوید.شما ممکن است یک معماری میکروسرویس را اتخاذ کرده باشید، در این صورت یک درخواست می تواند به تماس با ده ها برنامه متمایز نیاز داشته باشد.با گذشت زمان، برخی از سرویس‌های API جدید را اضافه می‌کنید و برخی دیگر را بازنشسته می‌کنید، اما مشتریان شما همچنان می‌خواهند همه سرویس‌های شما را در همان مکان پیدا کنند.چالش شما ارائه یک تجربه ساده و قابل اعتماد در برابر این همه پیچیدگی به مشتریان خود است. یک API Gateway راهی برای جدا کردن رابط مشتری از پیاده سازی backend شما است. هنگامی که یک کلاینت درخواستی می دهد، API Gateway آن را به چندین درخواست تقسیم می کند، آنها را به مکان های مناسب هدایت می کند، پاسخی را تولید می کند و همه چیز را پیگیری می کند.نقش API Gateway در مدیریت APIAPI Gateway بخشی از سیستم مدیریت API است. API Gateway تمام درخواست های دریافتی را رهگیری و آنها را از طریق سیستم مدیریت API ارسال کرده که انواع توابع ضروری را مدیریت می کند.کارهایی که API Gateway انجام می‌دهد می‌تواند از یک پیاده‌سازی به پیاده‌سازی دیگر متفاوت است. برخی از عملکردهای رایج عبارتند از احراز هویت، مسیریابی، محدود کردن نرخ، صورتحساب، نظارت، تجزیه و تحلیل، خط‌مشی‌ها، هشدارها و امنیت.ارزش API Gatewayیک API Gateway یک نقطه ورودی واحد فراهم می‌کند که برای همه فراخوانی‌های API که به یک برنامه وارد می‌شوند، چه برنامه در یک مرکز داده داخلی یا در فضای ابری میزبانی شود. درخواست هایی که از راه دور وارد می شوند را می پذیرد و داده های درخواستی را برمی گرداند.به عنوان مثال، برنامه وب یک رستوران را در نظر بگیرید. با استفاده از لپ‌تاپ یا تلفن همراه، کاربر می‌تواند یک درخواست را وارد کند و به راحتی به منوی رستوران، عکس‌ها و نظرات رستوران‌ها، خدمات پرداخت آن و نقشه‌ای برای بررسی موقعیت مکانی آن دسترسی داشته باشد، علی‌رغم همه این اطلاعات که از میکروسرویس‌های مختلف یا APIهای پشتیبان جمع‌آوری و تحویل می‌شود. درخواست آنها توسط یک API Gateway دریافت و اجرا می شود.با این حال، فراتر از سرویس دهی به درخواست ها، یک API Gateway نیز با در دسترس قرار دادن داده ها به روشی مناسب برای فناوری درخواست کننده، ارزشی را فراهم می کند. به عنوان مثال، شخصی که با استفاده از یک مرورگر وب، اطلاعات یک فروشگاه خرده فروشی را درخواست می کند، اطلاعات بسیار بیشتری نسبت به کسی که داده های همان فروشگاه را در تلفن همراه درخواست کرده و مشاهده می کند، نشان داده می شود. API Gatewayها همچنین می‌توانند ارتباط بی‌درنگ بین frontend و backend برنامه را فعال کنند، به عنوان مثال، در چت وب، سیستم‌های معاملات سهام و بازی‌های آنلاین.پشتیبانی API Gateway از DevOps و محیط های بدون سرور در سازمان‌هایی که از رویکرد DevOps پیروی می‌کنند، توسعه‌دهندگان از میکروسرویس‌ها برای ساخت و استقرار برنامه‌ها به روشی سریع و تکراری استفاده می‌کنند. API ها یکی از رایج ترین راه های ارتباط میکروسرویس ها هستند.علاوه بر این، توسعه ابر مدرن، از جمله مدل بدون سرور، به APIها برای تامین زیرساخت بستگی دارد. شما می‌توانید توابع بدون سرور را مستقر کرده و آنها را با استفاده از یک API Gateway مدیریت کنید.به طور کلی، همانطور که یکپارچگی و اتصال به یکدیگر مهم تر می شوند، API ها نیز اهمیت بیشتری پیدا می‌کنند و با افزایش پیچیدگی API و افزایش استفاده، ارزش API Gateway نیز افزایش می یابد.نحوه کار API Gatewayیک API Gateway بین یک کاربر و مجموعه‌ای از میکروسرویس‌ها قرار می گیرد و سه سرویس کلیدی را ارائه می‌دهد:1. درخواست مسیریابی: یک API Gateway یک درخواست API جدید دریافت می کند، آن را به چندین درخواست تبدیل کرده، یک نقشه مسیریابی را بررسی می‌کند که نشان می دهد هر درخواست باید کجا ارسال شود و درخواست ها را به میکروسرویس داخلی یا میکروسرویس مناسب ارسال می کند.2. ترکیب API Gateway :API هماهنگی جریان کار را فراهم می کند زیرا اطلاعات درخواستی را از چندین میکروسرویس جمع کرده، داده‌ها را بسته بندی می کند و آن را به صورت ترکیبی به درخواست کننده برمی گرداند.3. ترجمه پروتکل: API Gatewayها می‌دانند که درخواست‌های API از طریق دستگاه‌هایی وارد می‌شوند که از پروتکل‌های API مختلف استفاده می‌کنند و به درخواست‌های مشتری و میکروسرویس‌ها کمک می‌کنند تا با ترجمه آن پروتکل‌ها با یکدیگر ارتباط برقرار کنند. این gateway، پروتکل‌های API را از آنچه دستگاه کاربر نهایی استفاده می‌کند - اعم از مرورگر وب، تلفن همراه یا نقطه پایانی دیگر - به پروتکل‌های میکروسرویس ترجمه می‌کند. به عنوان مثال، یک شبکه گسترده (WAN) و شبکه محلی (LAN)، عملکرد متفاوتی دارند و نیازهای API متفاوتی دارند. هنگامی که اطلاعات برمی گردد، Gateway آن را تغییر می دهد و به گونه ای که می توانند آن را مشاهده کنند، برای درخواست کنندگان ارسال می کند. به عنوان مثال، اگر یک میکروسرویس پاسخی را در XML ارائه کند، اما درخواست با استفاده از JSON وارد شود، دروازه به طور خودکار آن ترجمه را انجام می دهد. REST API از پروتکل HTTP برای درخواست خدمات API استفاده می کند.APIها به برنامه های کاربردی جداگانه اجازه می دهند با یکدیگر ارتباط برقرار کنند و داده ها را در داخل و خارج از یک کسب و کار تبادل کنند. دروازه API یک نقطه کانونی و رابط استاندارد برای انجام این فعالیت ها فراهم می کند. درخواست‌هایی را از منابع داخلی و خارجی دریافت می‌کند که «فراخوانی‌های API» نامیده می‌شوند و درخواست‌های متعدد را بسته‌بندی می‌کند، آنها را به API یا APIهای مناسب هدایت می‌کند، و پاسخ‌ها را به کاربر یا دستگاهی که درخواست کرده است، دریافت و تحویل می‌دهد.API Gatewayها همچنین کلید معماری مبتنی بر میکروسرویس‌ها هستند، که در آن درخواست‌های داده، برنامه‌ها و سرویس‌های متعددی را فراخوانی می‌کنند که از چندین API متفاوت استفاده می‌کنند. در اینجا نقش API Gateway مشابه است: یک نقطه ورود واحد برای یک گروه تعریف شده از ریزسرویس ها ارائه کنید و سیاست هایی را برای تعیین در دسترس بودن و رفتار آنها اعمال کنید.API Gateway اغلب سایر عملکردهای مرتبط با API ها و میکروسرویس ها را انجام می دهند:ترجمه پروتکلکشف خدماتمنطق اولیه کسب و کاراحراز هویت و اجرای سیاست های امنیتیتثبیت و تعادل بارمدیریت کشنظارت، ثبت و تجزیه و تحلیلAPI Gateway در مقابل پروکسی API. جایگزینی برای API Gateway یک پروکسی API است که اساساً زیر مجموعه ای از دروازه API است که حداقل پردازش را برای درخواست های API ارائه می دهد. پروکسی API ارتباطات، از جمله ترجمه پروتکل، بین پلتفرم های نرم افزاری خاص، مانند نقطه پایانی پروکسی و API هدف را مدیریت می کند. همچنین می تواند جریان ترافیک بین نقاط ارسال و دریافت را کنترل کند. با این حال، API Gatewayها معمولاً دارای قابلیت‌های تحلیل عملکرد و نظارت بهتری هستند.API Gatewayها و میکروسرویس‌هاAPI Gatewayها، که گاهی اوقات «میکروسرویس‌های لبه» نامیده می‌شوند، اغلب در برنامه‌هایی که با معماری میکروسرویس‌های مدرن و بومی ابری ایجاد می‌شوند، استفاده می‌شوند. این برنامه‌ها معمولاً از بسیاری از مؤلفه‌های مستقل، مستقل و تک عملکردی (یا میکروسرویس‌ها) تشکیل شده‌اند که هر کدام توسط تیم DevOps کوچک و مستقل خود مدیریت می‌شوند. میکروسرویس‌ها به‌طور آزاد متصل هستند، به پایگاه داده‌های خود متصل می‌شوند و می‌توانند به طور مستقل مستقر، نگهداری و آزمایش شوند.هنگامی که درخواست اطلاعات به یک برنامه کاربردی با میکروسرویس ها وارد می شود، یک API Gateway یک رویکرد ساده برای بازیابی و بازگرداندن داده ها ارائه می دهد. علاوه بر کنترل دسترسی، امکان تحویل سریع و قابل اعتماد را در برنامه های بزرگ و پیچیده فراهم می کند.از آنجایی که میکروسرویس‌ها در محیط‌های مستقل خود اجرا می‌شوند، می‌توان آن‌ها را اضافه کرد، ارتقا داد، جابه‌جا کرد و تغییر داد بدون اینکه بر برنامه کلی تأثیر بگذارد. API Gatewayها، افزایش مقیاس برنامه‌های خود را برای شرکت‌ها آسان‌تر می‌کنند. بعلاوه، آنها می توانند ویژگی های جدید را سریعتر توسعه دهند، که امکان نوآوری بیشتر و زمان ورود سریعتر به بازار را فراهم می کند.API Gatewayها و برنامه های یکپارچه (monolithic)قبل از اینکه میکروسرویس ها وجود داشته باشند، برنامه های کاربردی یکپارچه وجود داشت. این برنامه ها بر خدماتی متکی هستند که بخشی از یک معماری همه کاره هستند که به یک پایگاه داده واحد متصل هستند. همه اجزا به یکدیگر وابسته هستند و به عنوان یک واحد عمل می کنند. تغییر هر جنبه ای از یک برنامه یکپارچه به معنای تغییر کدی است که کل معماری را اجرا می کند.بسیاری از برنامه های کاربردی یکپارچه هنوز در حال استفاده هستند. آنها عمدتاً از API Gatewayها برای ارتباط با اشخاص ثالث خارجی، کاربران داخلی یا شرکا استفاده می‌کنند و در عین حال همان امنیت، مقیاس‌پذیری و سایر مزایایی را که برای میکروسرویس‌ها اعمال می‌شود، ارائه می‌کنند.مزایاافزودن یک یا چند API Gateway به برنامه های میکروسرویس شما مزایای بسیاری را به همراه دارد:امنیت میکروسرویس ها: یک API Gateway مانعی در مقابل backend برنامه قرار می دهد و آن را ایمن تر می کند. به این معنی است که نقاط پایانی (endpoints) برنامه در معرض دید قرار نمی گیرند. بنابراین، خطر حمله کمتری وجود دارد. یک شرکت همچنین می تواند از HTTPS برای امنیت بیشتر یا HTTP رمزگذاری شده با SSL استفاده کند که عملکرد را بهبود می بخشد.احراز هویت API: یک API Gateway لایه امنیتی دیگری را فراهم می کند که با احراز هویت فراخوانی های API از اشتباهات، هک ها و نقض داده ها محافظت می کند. احراز هویت و مجوز می تواند شامل اسکن آنتی ویروس، رمزگشایی و رمزگذاری، ترجمه توکن، اعتبارسنجی و سایر عملکردهای امنیتی باشد.اعتبار سنجی ورودی: اعتبار سنجی ورودی تضمین می کند که درخواست API تمام اطلاعات لازم را در قالب صحیح قبل از اینکه gateway آن را به یک میکروسرویس ارسال کند، دارد. اگر چیزی کم یا اشتباه باشد، gateway درخواست را رد می کند. وقتی درست بودن آن تأیید شد، gateway درخواست را ارسال می کند.زمان پاسخ سریعتر: از آنجایی که یک API Gateway درخواست ها را مستقیماً به سرویس های مناسب ارسال می کند، رفت و برگشت کمتر و ترافیک کمتر، تأخیر کمتر و عملکرد بهتر به طور کلی وجود دارد، که به این معنی است که یک برنامه یک تجربه کاربری بهبود یافته را ارائه می دهد.متعادل‌سازی بار میکروسرویس‌ها: یک API Gateway درخواست‌های ارسال شده به میکروسرویس‌های مختلف را پیگیری می‌کند، بار بین گره‌ها را برای کارایی متعادل می‌کند و اطمینان می‌دهد که برنامه در دسترس باقی می‌ماند. این متعادل‌سازی بار زمانی که سطح ترافیک بالایی انتظار می‌رود - مانند هنگام فروش جمعه سیاه یا عرضه محصول جدید - برای جلوگیری از جهش‌ها یا رویدادهای انکار سرویس، حیاتی است.محدود کردن نرخ: محدودیت نرخ به این معنی است که یک API Gateway ترافیک ورودی از همه منابع را نظارت می کند و تعداد درخواست های API را که یک کلاینت (یا ربات مخرب) می تواند در یک بازه زمانی خاص - در هر ثانیه، یا در روز، هفته یا ماه – داشته باشد، برای محافظت از سیستم از پر شدن درخواست ها و احتمالاً خراب شدن سیستم، محدود می کند.صورت‌حساب برای سرویس‌های خرد: برخی از کسب‌وکارها با ارائه خدمات به مصرف‌کنندگان یا شرکت‌های دیگر، از برخی از APIهای خود درآمد کسب می‌کنند. API Gateway ترافیک را کنترل می کند، استفاده از محصولات یا خدمات خاص را نظارت می کند و اطلاعات قیمت را به یک سیستم صورتحساب متصل ارسال می کند. انواع مختلفی از کسب درآمد مستقیم وجود دارد، از جمله کاربرانی که هنگام دسترسی به یک سرویس یا منبع، برای تعداد معینی از خدمات یا از طریق سطوح (جایی که خدمات مختلف در سطوح مختلف ارائه می شود) هزینه پرداخت می کنند. سایر APIها از طریق سهم درآمد تبلیغات، بازاریابی وابسته یا اعتبار به صورت حساب مصرف کننده، درآمد را با مصرف کنندگان به اشتراک می گذارند.ذخیره‌سازی میکروسرویس‌ها: API Gatewayها می‌توانند به بهینه‌سازی فراخوانی‌های API، مانند ذخیره‌سازی میکروسرویس‌ها، کمک کنند. ذخیره پاسخ‌ها به فراخوانی‌های API می‌تواند به جلوگیری از بار غیرضروری در سرویس‌های باطن کمک کند. پاسخ‌های ذخیره‌شده را می‌توان زمانی که درخواست‌های مشابه دریافت کرد، استفاده کرد که باعث بهبود عملکرد و کاهش هزینه می‌شود.نظارت و ردیابی تجزیه و تحلیل برنامه‌ها: از آنجایی که یک دروازه API تمام ترافیک ورودی برنامه را کنترل می‌کند، نظارت بر نرم‌افزار و ارائه گزارش‌هایی درباره قابلیت مشاهده، روندها و سایر بینش‌ها در مورد استفاده از API ساده است. نرم‌افزار دروازه همچنین می‌تواند گزارش‌های ترافیکی ایجاد کند که به ارائه‌دهنده API کمک می‌کند تا مشکلات زیرساخت را درک و رفع کند.گسترش برنامه‌های قدیمی: کسب‌وکارها همچنان از برنامه‌های قدیمی استفاده می‌کنند که حاوی داده‌های ضروری هستند، عملکردهای مهمی را انجام می‌دهند و ارزش ارائه می‌دهند، اما برنامه‌ها برای API نوشته نشده‌اند. چنین فناوری قدیمی‌تری می‌تواند در رسیدگی به تعداد فزاینده فراخوانی‌ها از فناوری‌های جدیدتر، مانند برنامه‌های موبایل، SaaS یا IoT مشکل داشته باشد. دسترسی به آنها نیز ممکن است سخت باشد. یک تیم DevOps می‌تواند به جای انجام یک مهاجرت پیچیده ابری، عملکرد API را اضافه کند - از جمله مزایایی مانند محدود کردن نرخ و کاهش سرعت - برای کمک به مدرن‌سازی و گسترش عملکرد یک برنامه قدیمی.چالش های API Gatewayهادر حالی که افزودن API Gateway مزایای زیادی دارد، چالش‌هایی نیز می تواند وجود داشته باشد:زمان پاسخگویی: در حالی که تاخیر و زمان پاسخ اغلب به دلیل کارآمدتر شدن درخواست‌ها کاهش می‌یابد، مرحله اضافی درخواست از طریق API Gateway می‌تواند به طور بالقوه به زمان پاسخ اضافه کند.وابستگی ها: هر زمان که یک کسب و کار میکروسرویس را اضافه، تغییر یا حذف کند، باید API Gateway خود را به روز کند. این می‌تواند چالش‌برانگیز باشد با برنامه‌ای که از داشتن تنها چند میکروسرویس به تعداد زیادی از آنها تبدیل شده است. با این حال، ایجاد قوانین طراحی API می تواند به این امر کمک کند.پیچیدگی: منطق مسیریابی می تواند ارتباط با میکروسرویس ها را پیچیده تر کند. API Gateway سیستم دیگری است که باید توسعه، مستقر و نگهداری شود.امنیت: از آنجایی که یک API Gateway مناطق بسیاری از سیستم های یک شرکت را لمس می کند، به خطر افتادن آن می تواند به طور جدی بر ایمنی برنامه تأثیر بگذارد.قابلیت اطمینان: اگر فقط یک API Gateway وجود داشته باشد و down شود، کل برنامه از دسترس خارج می شود. ایجاد چندین API Gateway  و استفاده از متعادل کننده های بار می تواند به جلوگیری از این وضعیت کمک کند.API Gateway منبع بازیک API Gateway منبع باز به تیم های DevOps اجازه می دهد بدون نوشتن کد، منابع API جدید ایجاد کنند. برخی از مزایای یک API Gateway منبع باز شامل اجازه دادن به یک شرکت کوچک شروع و گسترش سریع است و اجازه انعطاف پذیری برای نوآوری و تغییر سریع و ایجاد شفافیت برای کاربران را می دهد.ابزارهای متن باز API Gatewayابزار Red Hat: این ابزار راه‌حل‌های ماژولار، سبک و جامع مدیریت API را به کسب و کار شما ارائه می دهد که منبع باز هستند، بر اساس استانداردهای باز ساخته شده اند و در محل یا در فضای ابری در دسترس هستند. Red Hat به تیم شما کمک می‌کند تا همه چیز (برنامه ها و داده ‌ها از قدیمی تا جدید) را حتی با رشد شما به یکدیگر متصل نگه میدارد.ابزار Amazon API Gateway: یک سرویس AWS برای ایجاد، انتشار، نگهداری، نظارت و ایمن سازی API های REST، HTTP و WebSocket در هر مقیاسی است. توسعه دهندگان API می توانند API هایی ایجاد کنند که به AWS یا سایر سرویس های وب و همچنین داده های ذخیره شده در AWS Cloud دسترسی دارند. به عنوان یک توسعه‌دهنده API Gateway، می‌توانید APIهایی را برای استفاده در برنامه‌های کلاینت خود ایجاد کنید. یا می توانید API های خود را در دسترس توسعه دهندگان برنامه های شخص ثالث قرار دهید.ابزار IBM: با کار با IBM، به قابلیت‌های اتوماسیون مبتنی بر هوش مصنوعی، از جمله گردش‌های کاری از پیش ساخته شده، دسترسی خواهید داشت تا با هوشمندتر کردن هر فرآیند، به سرعت بخشیدن به نوآوری کمک کنید.شرکت‌های ایرانی ارائه دهنده API Managementدر ایران یک سری شرکت‌ها وجود دارند که خدمات و ابزارهایی به منظور مدیریت API یا همان API Management ارائه می‌دهند اما شرکتی که به طور خاص به API Gateway بپردازد و در این حوزه ابزار تخصصی ارائه دهد در جستجو‌های من یافت نشد. در ادامه به معرفی برخی از این شرکت‌ها می‌پردازیم:شرکت وصل - پلتفرم سورنا: پلتفرم مدیریت API سورنا توسعه‌دهندگان را قادر می‌سازد تا برنامه‌هایی  مرتبط با سامانه‌های داخلی سازمان/سرویس‌دهنده طراحی و پیاده‌سازی نمایند.  همچنین APIها در تکنولوژی‌های مختلف نظیر اینترنت  اشیا، رایانش ابری و داده‌های حجیم نقشی کلیدی را ایفا می‌نماید. پلتفرم  مدیریت API سورنا پایداری، امنیت و پشتیبانی ویژهای ارائه می‌کند تا  شرکت‌های طرف ثالث، همکاران، شرکا و حتی توسعه‌دهندگان آزاد بتوانند با  آسودگی خیال و اطمینان از آنها استفاده نمایند.شرکت پلتکو:این شرکت پلتفرم مدیریت وب سرویس ارائه می‌دهد. یکی از ابزارهایی که ارائه می‌دهد API Manager می‌باشد. API Manager یک  راه حل مدیریتی و انعطاف پذیر است که یکپارچه سازی زیر ساخت وب سرویس‌های  سازمان را انجام می‌دهد و به شما کمک می کند تا بدانید دقیقاً چه کسی ، چه  زمانی و چگونه به وب سرویس‌های شما دسترسی پیدا می‌کند. API Manager ابزارهای کاربردی و جذابی در اختیار مدیران و اپراتورها قرار می‌دهد که  باعث بالا رفتن کارایی کل سرویس‌های سازمان می‌شود و از خطاها و اتلاف زمان  به طرز چشمگیری جلوگیری می‌کند. علاوه بر این موراد میزان توسعه پذیری کل  وب سرویس‌ها بالا می‌رود و به سازمان امکان استفاده از وب سرویس‌های قدیمی  را بدون کد نویسی می‌دهد.شرکت متفا (شرکت مهندسی توسعه فضای تبادل اطلاعات): این شرکت در زمینه‌های زیر فعالیت می‌کند:      - راهکارهای یکپارچه فناوری اطلاعات و ارتباطات      - نسل بعدی فناوری های اطلاعات و ارتباطات      - تحول دیجیتال و هوشمند سازی​​​​      - امنیت فضای تولید و تبادل اطلاعات​​​​​​​      یکی از محصولات این شرکت آورند است که پلتفرم مدیریت API میباشد. (API Management Platform)«این مطلب، بخشی از تمرین‌های درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.»منابع https://www.redhat.com/en/topics/api/what-does-an-api-gateway-do#:~:text=An%20API%20gateway%20is%20an,and%20return%20the%20appropriate%20result.  https://aws.amazon.com/what-is/api/  https://www.ibm.com/cloud/blog/api-gateway  https://www.altexsoft.com/blog/engineering/what-is-api-definition-types-specifications-documentation/  https://www.ibm.com/topics/api  https://www.techtarget.com/whatis/definition/API-gateway-application-programming-interface-gateway </description>
                <category>نیوشا محمودی</category>
                <author>نیوشا محمودی</author>
                <pubDate>Thu, 29 Dec 2022 14:43:54 +0330</pubDate>
            </item>
                    <item>
                <title>Micro Frontends</title>
                <link>https://virgool.io/@mahmoudi.nioosha/micro-frontends-jvyysrcqoot6</link>
                <description>این اصطلاح که در سال 2016 مطرح شد مفاهیم مربوط به میکروسرویس ها را به حوزه frontend وارد می کند.در حال حاضر علاقه بیشتر ساخت اپلیکیشن های تک صفحه ای است که دارای ویژگی های مختلف و بر مبنای مرورگر بوده و بر روی معماری میکروسرویس قرار می گیرد. به مرور زمان لایه مربوط به frontend گسترش پیدا می کند و با توجه به اینکه معمولا توسط تیم جداگانه ای توسعه می یابد، نگهداری دشوار تر می شود.ایده اصلی Micro Frontends این است که یک اپلیکیشن یا وبسایت مجموعه ای از ویژگی هایی است که توسط تیم های مستقل از یکدیگر توسعه یافته است. به این ترتیب که هر تیم مسئولیت اجرا حوزه تخصصی و ماموریت کسب و کاری خودش است. البته مشابه این ایده قبلا هم وجود داشت مانند self-contained Systems.Monolithic FrontendsOrganisation in Verticalsایده های اصلی در پشت Micro Frontends•	فناوری ناشناس: هر کدام از تیم ها بتوانند بدون نیاز به هماهنگی با دیگر تیم ها امکان تغییر فناوری های مورد استفاده خود را داشته باشد.•	جداسازی کد تیم ها: کدهای تیم¬ها از هم مستقل بوده حتی در صورت استفاده از چاچوب های مشابه هم زمان اجرا را به اشتراک نگذارند.•	ایجاد پیشوندهای تیم ها: جاهایی که امکان جداسازی کامل وجود ندارد توافقی صورت گیرد که مالکیت ها، پیش نیاز ها و ... مشخص گردد. https://micro-frontends.org/ </description>
                <category>نیوشا محمودی</category>
                <author>نیوشا محمودی</author>
                <pubDate>Wed, 23 Nov 2022 12:29:55 +0330</pubDate>
            </item>
                    <item>
                <title>MVVM</title>
                <link>https://virgool.io/@mahmoudi.nioosha/mvvm-ffcrkfo31bsr</link>
                <description>الگوی MVVM که مخفف Model-View-ViewModel است، الگویی است که منطق تجاری و ارائه برنامه از رابط کاربری را به طور مناسب تفکیک می کند. این تفکیک باعث رفع بسیاری از مشکلات توسعه می شود از جمله اینکه تست، نگهداری و تکامل برنامه ساده تر می گردد. MVVM همچنین به عنوان model-view-binder شناخته می شود و توسط معماران مایکروسافت Ken Cooper و John Gossman ساخته شده است. MVVM به سازماندهی کد و تبدیل برنامه ها به ماژول ها کمک می کند تا توسعه، به روز رسانی و استفاده مجدد از کد را ساده تر و سریع تر کند. این الگو اغلب در ویندوز و نرم افزارهای ارائه گرافیک وب استفاده می شود.سه جزء اصلی در الگوی MVVM وجود دارد: مدل، view و view-model که هر کدام هدف مشخصی را دنبال می کنند. شکل زیر روابط بین سه جزء را نشان می دهد.در ادامه به تشریح هر یک از این اجزاء می پردازیم.Model:مدل وظیفه ذخیره داده ها و منطق مربوطه را برعهده دارد. مدل داده هایی را که بین اجزای کنترل کننده یا هر منطق تجاری مرتبط دیگری منتقل می شود، نشان می دهد.View :منظور از View اجزاء مربوط به UI است مثل HTML و CSS. در این الگو View مسئولیت نمایش داده هایی را که از کنترلر دریافت می شود، دارد. وظیفه دیگر آن تبدیل Modelها به UI است.ViewModel :این جزء (ViewModel) در واقع مسئولیت پشتیبانی از وضعیت View را دارد که این کار را از طریق ارائه توابع، دستورات و متدها انجام می دهد. علاوه بر این مسئول اجرای مدل و فعال کردن رویدادها در View نیز می باشد.مزایای MVVM•	تفکیک منطق کسب وکار از Ul •	نگهداری و تست آسان•	استفاده مجدد آسان از کامپوننت ها•	معماری Loosely coupled•	نوشتن موارد unit test برای هر دو لایه viewmodel و Model بدون نیاز به ارجاع به Viewمعایب MVVM•	نگهداری از تعداد زیادی کد در کنترلر•	برای رابط های کاربری ساده معماری MVVM می تواند بیش از حد باشد.•	عدم ارائه اتصال محکم بین view model  وview  https://www.guru99.com/mvc-vs-mvvm.html  https://www.techtarget.com/whatis/definition/Model-View-ViewModel  https://learn.microsoft.com/en-us/xamarin/xamarin-forms/enterprise-application-patterns/mvvm </description>
                <category>نیوشا محمودی</category>
                <author>نیوشا محمودی</author>
                <pubDate>Wed, 23 Nov 2022 10:45:55 +0330</pubDate>
            </item>
                    <item>
                <title>CQRS</title>
                <link>https://virgool.io/@mahmoudi.nioosha/cqrs-o0gh8wxkyowv</link>
                <description>الگوی CQRS که مخفف Command and Query Responsibility Segregation است، یک الگوی محبوب است که عملیات به روزرسانی و نوشتن را برای یک مخزن داده جدا می کند. یک مشکل رایج برای بسیار از برنامه های کاربردی نیاز به جداسازی رفتار نوشتن از رفتار خواندن است که با استفاده از الگوی معماری CQRS این مشکل رفع می شود و برای برنامه های کاربردی ثبات، امنیت و مقیاس پذیری را فراهم کرده و علاوه بر آن عملکرد کلی را نیز بهبود می بخشد. علاوه بر این با مهاجرت به CQRS سیستم انعطاف پذیرتر شده بنابراین در طول زمان بهتر تکامل یافته و از ایجاد تداخل ادغام در سطح دامنه در دستورات به روز رسانی جلوگیری می¬کند.در معماری های سنتی، از مدل داده یکسان برای پرس وجو و به روزرسانی پایگاه داده استفاده می شود. این روش ساده است و برای عملیات اولیه CRUD به خوبی کار می کند ولی در برنامه های پیچیده تر، استفاده از این رویکرد دشوار است. به عنوان مثال، در سمت خواندن، برنامه ممکن است پرس و جوهای مختلفی را انجام دهد و اشیاء انتقال داده (DTO) را با اشکال مختلف برگرداند. نقشه برداری شی می تواند پیچیده شود. در سمت نوشتن، مدل ممکن است اعتبار سنجی پیچیده و منطق تجاری را پیاده سازی کند. در نتیجه، شما می توانید با یک مدل بیش از حد پیچیده روبرو شوید که کارهای زیادی می¬کند.حجم کار خواندن و نوشتن اغلب نامتقارن و با عملکرد و مقیاس بسیار متفاوت است.مشکلات موجود پیرامون معماری های سنتی:•	اغلب یک عدم تطابق بین نمایش خواندن و نوشتن داده ها وجود دارد، مانند ستون ها یا ویژگی های اضافی که باید به درستی به روز شوند، حتی اگر به عنوان بخشی از یک عملیات مورد نیاز نباشند.•	زمانی که عملیات به صورت موازی روی یک مجموعه از داده ها انجام شود، اختلاف داده ها ممکن است رخ دهد.•	رویکرد سنتی می تواند به دلیل بارگذاری روی ذخیره داده¬ها و لایه دسترسی به داده ها و پیچیدگی کوئری ها مورد نیاز برای بازیابی اطلاعات، تأثیر منفی بر عملکرد داشته باشد.•	مدیریت امنیت و مجوزها می‌تواند پیچیده شود، زیرا هر موجودیت تابع عملیات خواندن و نوشتن است، که ممکن است داده‌ها را در زمینه اشتباه نشان دهد.راه حلالگو CQRS خواندن و نوشتن را در مدل‌های مختلف جدا می‌کند و از commandها برای به‌روزرسانی داده‌ها و از queryها برای خواندن داده‌ها استفاده می‌کند.•	دستورات (Commandها) باید به جای داده مبتنی بر وظیفه باشند.•	دستورات ممکن است به جای پردازش همزمان در یک صف برای پردازش ناهمزمان قرار گیرند.•	کوئری ها هرگز پایگاه داده را تغییر نمی دهند. یک کوئری یک DTO را برمی گرداند که هیچ دانش دامنه را کپسوله نمی کند.سپس می توان مدل ها را جدا کرد، همانطور که در نمودار زیر نشان داده شده است، اگرچه این یک الزام مطلق نیست.مراجع https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs  https://www.techtarget.com/searchapparchitecture/definition/CQRS-command-query-responsibility-segregation </description>
                <category>نیوشا محمودی</category>
                <author>نیوشا محمودی</author>
                <pubDate>Wed, 23 Nov 2022 10:38:41 +0330</pubDate>
            </item>
                    <item>
                <title>HEXAGONAL ARCHITECTURE</title>
                <link>https://virgool.io/@mahmoudi.nioosha/hexagonal-architecture-nrt2dm5ewj8p</link>
                <description> در سال 2005، Hexagonal Architecture  یا همان معماری شش ضلعی توسط Alistair Cockburn پیشنهاد شد. پیش از آن معماری های لایه ای وجود داشتند. معماری سه لایه یکی از رایج ترین معماری های لایه ای بود که شامل سه لایه ارائه، منطق و داده بود. پس از آن Eric Evans در کتاب ... معماری 4 لایه را پیشنهاد داد و یک لایه تحت عنوان دامنه اضافه کرد که منطق تجاری را شامل می شود و از سه لایه دیگر رابط کاربری، Application و زیرساخت جدا شده است. معماری لایه ای دارای مزایایی است که مهم ترین آن جداسازی دغدغه ها است ولی ریسک هایی نیز دارد. از جمله این ریسک ها احتمال نشت منطق تجاری در لایه های دیگر است. اما Cockburn با تغییر دید خود به این نتیجه رسید که رابط کاربری و پایگاه داده هر دو عامل خارجی هستند از نظر تعامل با بخش اصلی برنامه که همان منطق تجاری است، مشابه یکدیگرند. به این ترتیب معماری شش ضلعی را ارائه کرد که طبق این معماری پورت ها و آداپتورهایی وجود دارند که از طریق آن ها ارتباط با بازیگران خارجی برقرار می گردد. به این ترتیب از ریسکی که در معماری های لایه ای وجود داشت جلوگیری می شود.مفهوم اصلی پشت معماری شش ضلعی که به عنوان الگوی پورت ها و آداپتورها نیز شناخته می شود، این است که برنامه در مرکز سیستم است. یک پورت ورودی ها و خروجی هایی را که به برنامه می رسند یا از آن خارج می شوند از فناوری های خارجی، مکانیک های تحویل و ابزار جدا می کند.پورت هاپورت همان نقطه ورودی است که با رابطی که تعیین می کند (صرف نظر از پیاده سازی آن ها) به عوامل خارجی اجازه ارتباط با برنامه را می دهد. پورت ها همچنین به برنامه اجازه می دهند با سیستم ها یا خدمات خارجی مانند پایگاه های داده، کارگزاران پیام، سایر برنامه ها و غیره ارتباط برقرار کند.آداپتورهایک آداپتور از طریق یک پورت با استفاده از یک فناوری خاص با برنامه تعامل می کند، برای مثال، یک کنترلر REST آداپتوری را نشان می دهد که به مشتری اجازه می دهد با برنامه ارتباط برقرار کند. برای هر پورت به تعداد موردنیاز می تواند آداپتور وجود داشته باشد بدون اینکه خطری برای پورت ها یا خود برنامه ایجاد کند.اصطلاح Hexagonal به منظور نمایش گرافیکی به کار برده شده است که کامپوننت برنامه را به صورت یک سلول شش ضلعی نشان داده است. در این نمایش بصری منظور وجود شش مرز یا پورت نبوده است بلکه به این دلیل است که فضای کافی برای نمایش رابط¬های مختلف مورد نیاز بین کامپوننت و دنیای بیرونی وجود داشته باشد. برای درک بهتر به تصویر زیر توجه کنید.در ادامه مزایا و معایب این  نوع معماری را بررسی می کنیم.مزایای معماری شش ضلعی•	با توجه به اینکه منطق برنامه از آداپتورها کاملا جدا هستند بنابراین در طول توسعه، بدون هیچ گونه تغییر در منطق برنامه می توانیم آداپتورها را اضافه یا حذف کنیم.•	تست ساده یکی دیگر از مزایای این معماری است چرا که لایه ها از یکدیگر جدا هستند بنابراین به سادگی می توانیم برای هرکدام تست بنویسیم.•	 با توجه به اینکه به راحتی می توانیم آداپتورهای جدید اضافه کنیم و یا آداپتورهای قبلی را تغییر دهیم بنابراین برنامه سازگارتری داریم.•	می توان تمام کتابخانه های شخص ثالث را در لایه زیرساخت نگهداری کرد بنابراین تعمیر و نگهداری آسان تر شده و در نتیجه برنامه پایدارتر است.•	برنامه مستقل از پایگاه داده است و می توان به راحتی ارائه دهندگان پایگاه داده را تغییر داد، زیرا پایگاه داده از دسترسی به داده جدا شده است.•	کد تمیز از مزایای دیگر است چرا که UI را می توان به راحتی پیاده سازی کرد زیرا منطق تجاری از لایه ارائه مانند React، Angular یا Blazor دور نگه داشته شده است.•	از نظر سازماندهی وضعیت مطلوبی دارد و توسعه¬دهندگان جدید به راحتی وارد پروژه می شوند و درک بهتری از پروژه خواهند داشت.معایب معماری شش ضلعی•	با توجه به اینکه کل منطق برنامه در لایه دامنه قرار دارد بنابراین این لایه سنگین می شود.•	افزایش تعداد لایه های انتزاعی در این معماری موجب افزایش بسیار زیاد پیچیدگی می شود.•	هزینه های ساخت و نگهداری به دلیل داشتن لایه های غیرمستقیم و ایزوله افزایش می یابد به طوری که این افزایش هزینه از مزایای انتزاع بیشتر می شود.•	•	می توان گفت اکثر برنامه¬های کاربردی وب هرگز نیاز به تغییر پایگاه داده ها و چارچوب ها پیدا نمی کنند و فقط از طریق مرورگر استفاده خواهند شد. به این ترتیب می توان گفت اگرچه داشتن همچین برنامه هایی با چنین سطح سازگاری بالایی اگرچه بسیار مطلوب هستند ولی ضروری و مورد نیاز اکثریت نیست بنابراین اتلاف تلاش و وقت است.  https://medium.com/ssense-tech/hexagonal-architecture-there-are-always-two-sides-to-every-story-bc0780ed7d9c  https://www.partech.nl/nl/publicaties/2021/06/what-is-hexagonal-architecture# </description>
                <category>نیوشا محمودی</category>
                <author>نیوشا محمودی</author>
                <pubDate>Wed, 23 Nov 2022 10:21:10 +0330</pubDate>
            </item>
                    <item>
                <title>Domain-driven design</title>
                <link>https://virgool.io/@mahmoudi.nioosha/domain-driven-design-ghu6nfc2rruq</link>
                <description>در این بخش می خواهیم به طور خلاصه به بررسی طراحی دامنه محور یا همان Domain-driven design بپردازیم. DDD در واقع یک رویکرد توسعه نرم افزار است که شامل اصول و قواعدی به منظور طراحی سیستم شی می باشد. نکته ای که وجود دارد آن است که بین واقعیت و اهداف تجاری یک کسب و کار با کد مربوط به اجرا و پیاده سازی برنامه کاربردی مربوطه فاصله وجود دارد و DDD در تلاش است با درک پیچیدگی های منطق تجاری به عنوان واسطی بین آن و کدی که به منظور پیاده سازی سیستم مد نظر به کار برده شده است، عمل کند.مشابه هر مفهوم دیگر، طراحی دامنه محور نیز مزایا و معایبی دارد که در ادامه به آن ها می پردازیم.مزایای طراحی دامنه محور•	ارتباط ساده تر: DDD دارای یک زبان مشترک (Ubiquitous Language) است که به کمک آن ارتباط بین متخصصان حوزه کاری و توسعه دهندگان ساده تر می شود. در این زبان مشترک به جای استفاده از اصطلاحات پیچیده فنی از کلمات ساده و روان با تعریف مشخص شده استفاده می گردد.•	انعطاف پذیری بیشتر: از آنجایی که DDD شی گرا است، همه چیز در مورد دامنه یا حوزه کاری مربوطه و شی است. به این ترتیب، کل سیستم را می توان به طور منظم اصلاح و بهبود بخشید.•	دامنه مهم تر از UI/UX است: دامنه یا حوزه کاری اصل موضوع است و برنامه های کاربردی متناسب با حوزه کاری ساخته می شوند. در DDD هم تمرکز بر دامنه است و اینکه محصول نهایی دقیقا کاربرانی را مد نظر قرار دهد که مستقیما به دامنه متصل هستند. معایب طراحی دامنه محور•	دانش عمیق دامنه مورد نیاز است: با توجه به اینکه معمولا تیم های توسعه دانش خیلی تخصصی در زمینه حوزه کاری کسب وکار ندارند، بنابراین لازم است حداقل یک متخصص دامنه در تیم توسعه باشد به طوریکه ویژگی های دقیق حوزه موضوع اصلی برنامه را درک و تفسیر نماید.•	شامل تمرین های تکراری: طراحی دامنه محور شامل بسیاری از شیوه های تکرار است و یک سری افراد معتقد هستند که این خود یک مزیت است. DDD تشویق به استفاده از یکپارچه سازی مداوم برای ساخت برنامه های کاربردی قوی می کند که به این ترتیب بتوانند در صورت لزوم خود را تطبیق دهند. همه سازمان ها با چنین تکرارهایی راحت نیستند مخصوصا در صورتی که از مدل‌های رشد کمتر انعطاف‌پذیر، مانند مدل آبشار در گذشته استفاده می کردند.•	ممکن است برای پروژه های بسیار فنی بهترین عملکرد را نداشته باشد: در واقع می توان گفت طراحی دامنه محور ممکن است بهترین راه حل برای برنامه هایی با منطق کسب وکاری پیچیده باشد ولی پروژه هایی که دارای پیچیدگی های فنی بالا هستند برای کارشناسان حوزه کسب وکار چالش های زیادی ایجاد کنند، بنابراین DDD برای چنین پروژه هایی ممکن است بهترین راه حل نباشد.نتیجهطراحی دامنه محور یک رویکرد مهندسی نرم افزار برای حل یک مدل دامنه خاص است که با استفاده از مدل کسب وکار کدهای اجرا را به اصول کلیدی کسب و کار متصل می کند.مراجع: https://medium.com/microtica/the-concept-of-domain-driven-design-explained-3184c0fd7c3f  آدرسصفحهوبیکهمیخواهیدنمایشدهیدراPasteکنید </description>
                <category>نیوشا محمودی</category>
                <author>نیوشا محمودی</author>
                <pubDate>Wed, 23 Nov 2022 10:08:56 +0330</pubDate>
            </item>
            </channel>
</rss>