<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های faezeh montazerin</title>
        <link>https://virgool.io/feed/@faezehmonta1995</link>
        <description></description>
        <language>fa</language>
        <pubDate>2026-06-16 16:55:25</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/1336308/avatar/avatar.png?height=120&amp;width=120</url>
            <title>faezeh montazerin</title>
            <link>https://virgool.io/@faezehmonta1995</link>
        </image>

                    <item>
                <title>گزارش پایانی پروژه درس: معماري نرم‌افزار Netflix  و Airbnb</title>
                <link>https://virgool.io/@faezehmonta1995/%DA%AF%D8%B2%D8%A7%D8%B1%D8%B4-%D9%BE%D8%A7%DB%8C%D8%A7%D9%86%DB%8C-%D9%BE%D8%B1%D9%88%DA%98%D9%87-%D8%AF%D8%B1%D8%B3-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%D9%8A-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%D8%B4%D8%B1%D9%83%D8%AA-%D9%87%D8%A7%D9%8A-netflix-%D9%88-airbnb-ixwyb8bp1s1n</link>
                <description>در اين مطلب به معماري نرم‌افزار شركت‌هاي Netflix  و  Airbnb مي‌پردازيم. چكيدهمعماری نرم‌افزار به سادگی سازماندهی یک سیستم است. این سازمان شامل تمامی اجزا، نحوه تعامل آن‌ها با یکدیگر، محیطی که در آن فعالیت می‌کنند و اصولی که برای طراحی نرم‌افزار به کار می‌رود، می‌باشد. در بسیاری از موارد، می‌تواند شامل تکامل نرم‌افزار به آینده نیز باشد. شركت‌هايي كه در اين تحقيق در مورد ان‌ها صحبت شده است، شركت‌هايي هستند كه تعداد زياد كاربران ان‌ها زبانزد است و براي همگان مهم است كه از چه فناوري‌ها، ابزارها و متدهايي براي براورده كردن نيازهاي اين تعداد كاربر استفاده شده است. واژگان كليدي: معماري نرم‌افزار، Netflix، Airbnb1-مقدمهالگوی معماری مناسب برای سیستم IT شما به عوامل متعددی از جمله چارچوب زمانی پروژه، بودجه و مجموعه مهارت های توسعه دهندگان درگیر بستگی دارد. همچنین در صورت نیاز امکان ترکیب چندین الگوی مختلف وجود دارد. هیچ الگو یا راه حلی وجود ندارد که در همه جا کار کند، و به همین دلیل است که معماران نرم افزار می توانند در شروع یک پروژه این تصمیمات را به دست آورند. تعیین دقیق «معماری نرم افزار» می تواند کار دشواری باشد. رالف ای جانسون، دانشمند مشهور کامپیوتر، زمانی آن را چنین توصیف کرد: «معماری در مورد چیزهای مهم است. هر چه که باشد.» در حالی که هیچ تعریف دقیق پذیرفته شده جهانی از معنای معماری نرم افزار وجود ندارد، اکثر آنها می توانند بر روی اصول اساسی آن توافق داشته باشند. در ابتدایی ترین شکل آن، می توان آن را طراحی و ساختار سیستم های پیچیده فناوری اطلاعات توصیف کرد. این طرحی است برای اینکه چگونه اجزای نرم افزار فردی باید سازماندهی و در یک سیستم ساختاری قوی که نیازهای تجاری را برآورده می کند، سازماندهی و متصل شوند. درست مانند یک پروژه ساخت و ساز ساختمان، تصمیمات معماری نرم افزار معمولاً انتخاب های طراحی سطح بالا هستند - از چه ابزارها، استانداردها و چارچوب هایی باید استفاده کرد و چگونه همه عناصر با یکدیگر تعامل خواهند داشت. این تصمیمات در شروع یک پروژه گرفته می شود و برای موفقیت آن بسیار مهم است. به هر حال، روشی که در آن سیستم‌های نرم‌افزاری طراحی و کنار هم قرار می‌گیرند، بر عملکرد، امنیت، قابلیت اطمینان و مقیاس‌پذیری تأثیر می‌گذارد. نقش یک معمار نرم افزار گاهی اوقات می تواند با نقش یک مهندس یا توسعه دهنده محو شود، به خصوص زمانی که روی سیستم های کوچکتر و از نظر ساختاری ساده کار می کند. با این حال، چند تمایز مهم وجود دارد: در همان ابتدای چرخه عمر توسعه نرم‌افزار، یک معمار نرم‌افزار باید بتواند بفهمد چه عناصری اساسی هستند و چگونه باید مستقر شوند، متصل شوند و کنترل شوند. چشم انداز معمار، که مهندسان و توسعه دهندگان نرم افزار را راهنمایی می کند، راه حل های طراحی بهینه را برای نیازهای یک کسب و کار (عملکرد، عملکرد و غیره) طرح ریزی می کند، در حالی که تمام محدودیت های مربوطه (زمان، بودجه، زیرساخت های موجود) را در نظر می گیرد. برای انجام موفقیت آمیز این کار، یک معمار نرم افزار باید درک دقیقی از این که چگونه ابزارهای مختلف موجود در آن زمان می توانند مشکلاتی را که با آنها برخورد می کنند را به کارآمدترین و مؤثرترین روش حل کنند، داشته باشد. این شامل دانستن زمانی است که جدیدترین و قدرتمندترین فناوری برای استفاده در یک سیستم خاص مناسب نیست.در اینجا سه ​​دلیل اصلی وجود دارد که چرا یک معماری نرم افزار خوب در هنگام توسعه بسیار مهم است:1. مبنایی برای ارتباطمعماری نرم افزار نوعی طرح از سیستم است و برای درک، مذاکره و ارتباط بین همه ذینفعان (سمت کاربر، مشتری، مدیریت و غیره) اولیه است. درک کل سیستم را آسان تر می کند و فرآیند تصمیم گیری را کارآمدتر می کند.2. اولین تصمیماتاولین تصمیمات در این مرحله گرفته می شود. آن تصمیمات اولیه اهمیت زیادی در بقیه پروژه دارند و هر چه بیشتر در فرآیند پیشرفت کنیم، تغییر آنها بسیار دشوار می شود.3. قابلیت انتقال مدلمعماری نرم افزار مدل نرم افزار و نحوه عملکرد آن را تعریف می کند. وجود آن امکان استفاده مجدد از این مدل را برای سایر نرم افزارها فراهم می کند. کد می تواند مورد استفاده مجدد قرار گیرد و همچنین الزامات. تمام تجربیاتی که در حین انجام معماری به دست می آوریم نیز منتقل می شود. این بدان معناست که ما می‌دانیم و می‌توانیم از عواقب تصمیمات اولیه که در وهله اول گرفته‌ایم استفاده مجدد کنیم.به عبارت دیگر، معماری مشکلاتی را که ممکن است هنگام پیاده سازی با آن مواجه شوید را مشخص می کند. همچنین ساختار سازمانی را نشان می دهد و تصمیم گیری و مدیریت انواع تغییرات را بسیار آسان تر می کند. همچنین به ما این امکان را می دهد که تخمین بهتری از زمان و هزینه یک پروژه داشته باشیم. در اینجا سه ​​دلیل اصلی وجود دارد که چرا یک معماری نرم افزار خوب در هنگام توسعه بسیار مهم است.2- روش تحقيقرويكرد تركيبي پژوهشي و صنعتي: در این پروژه به بررسی تکنولوژی‌های استفاده شده در این معماری‌ها و چالش‌هایی که با طراحی‌های متفاوت حل شده‌اند، می‌پردازیم.3- شركت Netflix3-1- معرفيهمه ما با خدمات نتفلیکس آشنا هستیم. دسته‌های بزرگی از فیلم‌ها و محتوای تلویزیونی را مدیریت می‌کند و کاربران اجاره ماهانه برای دسترسی به این محتواها را پرداخت می‌کنند. نتفلیکس بيش از 180 میلیون مشترک در  بيش از 200 کشور دارد.نتفلیکس سال‌هاست که یکی از بهترین سرویس‌های پخش ویدئو مبتنی بر اشتراک آنلاین در جهان است و بیش از 15 درصد از ظرفیت پهنای باند اینترنت جهان را به خود اختصاص داده است. به طور خاص، مشترکین نتفلیکس بیش از 165 میلیون ساعت را صرف تماشای بیش از 4000 فیلم و 47000 قسمت در روز می کنند. این آمار چشمگیر به ما نشان می دهد که از دیدگاه مهندسی، تیم های فنی نتفلیکس چنین سیستم پخش ویدیویی شگفت انگیزی را با در دسترس بودن و مقیاس پذیری بسیار بالا طراحی کرده اند تا به مشتریان خود در سطح جهانی خدمات ارائه دهند.3-2- معمارينتفلیکس ابر AWS  را برای انتقال زیرساخت‌های فناوری اطلاعات خود انتخاب کرده بود زیرا AWS می‌توانست پایگاه‌های داده بسیار قابل اعتماد، فضای ذخیره‌سازی ابری در مقیاس بزرگ و مراکز داده متعدد در سراسر جهان ارائه دهد. نتفلیکس با استفاده از زیرساخت ابری که توسط AWS ساخته و نگهداری می‌شود، کارهای سنگین غیرمتمایز ساخت مراکز داده را انجام نداد، بلکه بیشتر بر کسب‌وکار اصلی خود یعنی ارائه تجربه کاربر پخش ویدئو با کیفیت بالا تمرکز کرد. حتی با وجود اینکه مجبور است کل فناوری را بازسازی کند تا اجازه دهد به راحتی روی ابر AWS اجرا شود، بهبود مقیاس پذیری و در دسترس بودن سرویس نتفلیکس در ازای آن به طور قابل توجهی افزایش یافته است[4].نتفلیکس همچنین یکی از اولین محرک های اصلی معماری میکروسرویس ها است. Microservices مشکلات طراحی نرم‌افزار یکپارچه را با تشویق جداسازی نگرانی‌ها [11] هدف قرار می‌دهد که در آن برنامه‌های بزرگ با ماژولار بودن با کپسوله‌سازی داده‌ها به تنهایی به اجزای نرم‌افزار کوچک‌تر تقسیم می‌شوند. Microservices همچنین به افزایش مقیاس پذیری از طریق مقیاس افقی و پارتیشن بندی حجم کار کمک می کند. مهندسان نتفلیکس با پذیرش میکروسرویس ها به راحتی هر سرویسی را تغییر می دهند که منجر به استقرار سریعتر می شود. مهمتر از آن، آنها می توانند عملکرد هر سرویس را ردیابی کنند و به سرعت مشکلات آن را از سایر سرویس های در حال اجرا جدا کنند.در این مطالعه، من علاقه مند به درک معماری ابری Netflix و عملکرد آن تحت بارهای کاری مختلف و محدودیت های شبکه هستم. به طور خاص، من می‌خواهم طراحی سیستم را از نظر در دسترس بودن، تأخیر، مقیاس‌پذیری و انعطاف‌پذیری در برابر خرابی‌های شبکه یا قطعی سیستم تجزیه و تحلیل کنم. این مطالعه به شرح زیر سازماندهی شده است. بخش 2 یک معماری احتمالی سیستم Netflix که از منابع مختلف آنلاین آموخته شده است را شرح خواهد داد. سپس در بخش 3، اجزای سیستم با جزئیات بیشتر مورد بحث قرار خواهد گرفت. در بخش 4، 5، 6، 7، سیستم را با توجه به اهداف طراحی فوق تجزیه و تحلیل خواهم کرد. در نهایت، آنچه را که از این تجزیه و تحلیل آموخته‌ایم نتیجه می‌گیرم و گام‌های بعدی احتمالی باید برای بهبود برداشته شود.نتفلیکس بر اساس خدمات محاسبات ابری آمازون (AWS) و Open Connect، شبکه تحویل محتوای داخلی آن [1] عمل می کند. هر دو سیستم باید به طور یکپارچه با هم کار کنند تا خدمات پخش ویدیو با کیفیت بالا را در سطح جهانی ارائه دهند. از نقطه نظر معماری نرم افزار، نتفلیکس شامل سه بخش اصلی است: Client، Backend و Content Delivery Network (CDN).Client هر مرورگر پشتیبانی شده در لپ تاپ یا دسکتاپ یا برنامه Netflix در تلفن های هوشمند یا تلویزیون های هوشمند است. نتفلیکس برنامه های iOS و Android خود را توسعه می دهد تا بهترین تجربه مشاهده را برای هر مشتری و دستگاه ارائه دهد. نتفلیکس با کنترل برنامه‌ها و سایر دستگاه‌های خود از طریق SDK خود، می‌تواند خدمات استریم خود را تحت شرایط خاصی مانند شبکه‌های کند یا سرورهای پربار، به طور شفاف تطبیق دهد.Backend شامل سرویس‌ها، پایگاه‌های داده، ذخیره‌سازی‌هایی است که به طور کامل بر روی ابر AWS اجرا می‌شوند. Backend اساساً همه چیزهایی را که شامل پخش ویدیوها نمی شود کنترل می کند. برخی از اجزای Backend با خدمات AWS مربوطه خود به شرح زیر فهرست شده اند:- نمونه های محاسباتی مقیاس پذیر (AWS EC2)- فضای ذخیره سازی مقیاس پذیر (AWS S3)- ریزسرویس‌های منطق تجاری (فریم‌ورک‌های هدفمند توسط نتفلیکس)- پایگاه داده های توزیع شده مقیاس پذیر (AWS DynamoDB، Cassandra)- کارهای پردازش و تجزیه و تحلیل داده های بزرگ (AWS EMR، Hadoop، Spark، Flink، Kafka و سایر ابزارهای هدفمند ساخته شده توسط Netflix)- پردازش و رمزگذاری ویدیو (ابزارهای هدفمند توسط نتفلیکس)Open Connect CDN شبکه ای از سرورها به نام Open Connect Appliances (OCAs) است که برای ذخیره و پخش ویدیوهای بزرگ بهینه شده است. این سرورهای OCA در شبکه های ارائه دهندگان خدمات اینترنتی (ISP) و مکان های تبادل اینترنتی (IXP) در سراسر جهان قرار می گیرند. OCA ها مسئول پخش مستقیم ویدیوها به مشتریان هستند.در بخش‌های بعدی، من مرجعی از معماری ابری نتفلیکس را شرح می‌دهم که این 3 بخش بالا را شامل می‌شود. یک معماری کلی می‌تواند پس از کلیک روی دکمه Play روی برنامه‌هایش، ویدیوها را پخش کند که معماری پخش نامیده می‌شود. سپس در بخش بعدي، یک معماری میکروسرویس دقیق تر از Backend توضیح داده می شود تا نشان دهد چگونه Netflix در دسترس بودن و مقیاس پذیری را در مقیاس جهانی مدیریت می کند.3-2-1- معماري Playbackوقتی مشترکین روی دکمه Play در برنامه‌ها یا دستگاه‌های خود کلیک می‌کنند، Client با Backend در AWS و OCAs در Netflix CDN صحبت می‌کند تا ویدیوها را پخش کند [7]. نمودار زیر نحوه عملکرد فرآیند پخش را نشان می دهد:شكل 1: معماری پخش برای پخش ویدیوها1- بخش OCAها دائماً گزارش‌های سلامتی درباره وضعیت بار کاری، قابلیت مسیریابی و ویدیوهای موجود خود را به سرویس Cache Control در حال اجرا در AWS EC2 ارسال می‌کنند تا برنامه‌های Playback آخرین OCA‌های سالم را به مشتریان به‌روزرسانی کنند.2- یک درخواست Play از دستگاه مشتری به سرویس برنامه‌های پخش Netflix که در AWS EC2 اجرا می‌شود ارسال می‌شود تا آدرس‌های اینترنتی برای پخش ویدیوها دریافت شود.3- سرویس Playback Apps باید مشخص کند که درخواست Play برای مشاهده ویدیوی خاص معتبر است. چنین اعتبار سنجی هایی طرح مشترک، مجوز ویدیو در کشورهای مختلف و غیره را بررسی می کند.4- سرویس Playback Apps با سرویس Steering نیز در AWS EC2 اجرا می‌شود تا لیست سرورهای OCA مناسب ویدیوی درخواستی را دریافت کند. سرویس Steering از آدرس IP مشتری و اطلاعات ISPها برای شناسایی مجموعه ای از OCA های مناسب برای آن مشتری استفاده می کند.5- از لیست 10 سرور OCA مختلف که توسط سرویس Playback Apps بازگردانده شده است، مشتری کیفیت اتصالات شبکه به این OCA ها را آزمایش می کند و سریع ترین و مطمئن ترین OCA را برای درخواست فایل های ویدیویی برای پخش انتخاب می کند.6- سرور OCA انتخاب شده درخواست های مشتری را می پذیرد و پخش ویدیوها را شروع می کند.در نمودار بالا، خدمات Playback Apps، Steering Service و Cache Control به طور کامل در فضای ابری AWS بر اساس معماری میکروسرویس اجرا می شوند. در بخش بعدی، من مرجعی از معماری میکروسرویس های نتفلیکس باطن را توضیح خواهم داد که در دسترس بودن و مقیاس پذیری سرویس های در حال اجرا را افزایش می دهد.همانطور که در بخش‌های قبلی توضیح داده‌ام، Backend تقریباً همه چیز را کنترل می‌کند، از ثبت‌نام، ورود به سیستم، صورت‌حساب گرفته تا وظایف پردازشی پیچیده‌تر مانند رمزگذاری ویدیو و توصیه‌های شخصی‌شده. نتفلیکس به منظور پشتیبانی از بارهای کاری سبک و سنگین که بر روی یک زیرساخت اساسی اجرا می شوند، معماری میکروسرویس ها را برای سیستم مبتنی بر ابر خود انتخاب کرده است. نمودار در شکل 2 یک معماری میکروسرویس ممکن را در Netflix نشان می دهد که من از چندین منبع آنلاین استخراج کرده ام[11، 13، 14].3-2-2- معماري Backendشكل 2: مرجع معماری Backend بر اساس منابع مختلف1- کلاینت یک درخواست Play به Backend در حال اجرا در AWS ارسال می کند. این درخواست توسط متعادل کننده بار AWS (ELB) رسیدگی می شود.2- AWS ELB آن درخواست را به API Gateway Service در حال اجرا بر روی نمونه های AWS EC2 ارسال می کند. این مؤلفه که Zuul نام دارد توسط تیم نتفلیکس ساخته شده است تا امکان مسیریابی پویا، نظارت بر ترافیک و امنیت، انعطاف پذیری در برابر خرابی ها در لبه استقرار ابر را فراهم کند. این درخواست برای برخی از فیلترهای از پیش تعریف شده مربوط به منطق تجاری اعمال می شود، سپس برای رسیدگی بیشتر به API Application ارسال می شود.3- جزء API Application منطق اصلی کسب و کار پشت عملیات Netflix است. انواع مختلفی از API مربوط به فعالیت های مختلف کاربر مانند Signup API، Recommendation API برای بازیابی توصیه های ویدیویی وجود دارد. در این سناریو، درخواست ارسال شده از API Gateway Service توسط Play API مدیریت می شود.4- Play API یک میکروسرویس یا دنباله ای از میکروسرویس ها را برای انجام درخواست فراخوانی می کند. سرویس Playback Apps، سرویس Steering و سرویس Cache Control در شکل 1 به عنوان یک میکروسرویس در این نمودار دیده می شود.5- میکروسرویس ها عمدتاً برنامه های کوچک بدون تابعیت هستند و می توانند با یکدیگر تماس بگیرند. برای کنترل خرابی آبشاری و فعال کردن انعطاف‌پذیری، هر میکروسرویس توسط Hystrix از فرآیندهای تماس گیرنده جدا می‌شود. نتیجه آن پس از اجرا می‌تواند در یک کش مبتنی بر حافظه ذخیره شود تا امکان دسترسی سریع‌تر برای درخواست‌های با تأخیر کم حیاتی فراهم شود.6- میکروسرویس ها می توانند داده ها را در یک فروشگاه داده در طول فرآیند ذخیره کنند یا از آن دریافت کنند.7- میکروسرویس‌ها می‌توانند رویدادهایی را برای ردیابی فعالیت‌های کاربر یا سایر داده‌ها به خط لوله پردازش جریان برای پردازش بلادرنگ توصیه‌های شخصی یا پردازش دسته‌ای وظایف هوش تجاری ارسال کنند.8- داده‌هایی که از خط لوله پردازش جریان خارج می‌شوند می‌توانند برای سایر فروشگاه‌های داده مانند AWS S3، Hadoop HDFS، Cassandra و غیره پایدار باشند.معماری‌های توصیف‌شده به ما کمک می‌کنند تا درکی کلی از نحوه سازمان‌دهی و کار با هم قطعات مختلف برای پخش جریانی ویدیوها به دست آوریم. با این حال، برای تجزیه و تحلیل در دسترس بودن و مقیاس پذیری معماری ها، باید بیشتر به هر جزء مهم بپردازیم تا ببینیم که چگونه تحت بارهای کاری مختلف عمل می کند. که در بخش بعدی به آن پرداخته خواهد شد.3-2-3- مولفه هادر این بخش، من می‌خواهم به مؤلفه‌های تعریف‌شده در بخش قبلي بپردازم تا در دسترس بودن و مقیاس‌پذیری آن را تحلیل کنم. هنگام توصیف هر جزء، من همچنین نحوه برآورده کردن این اهداف طراحی را ارائه خواهم کرد. تجزیه و تحلیل طراحی عمیق تر در بخش های بعدی با توجه به کل سیستم ذکر خواهد شد.3-2-3-1- كلاينتتیم‌های فنی نتفلیکس تلاش زیادی برای توسعه برنامه‌های مشتری سریع‌تر و هوشمندتر انجام داده‌اند که بر روی لپ‌تاپ، دسکتاپ یا دستگاه‌های تلفن همراه اجرا می‌شوند. حتی در برخی از تلویزیون‌های هوشمند که Netflix در آنها کلاینت تخصصی ایجاد نمی‌کند، Netflix همچنان عملکرد خود را از طریق SDK ارائه شده کنترل می‌کند. در واقع، هر محیط دستگاهی نیاز به نصب Netflix Ready Device Platform (NRDP) دارد تا بتواند بهترین تجربه مشاهده Netflix را ممکن کند. یک جزء ساختاری مشتری معمولی [11] در شکل 3 نشان داده شده است.شكل 3: مولفه برنامه ي كلاينتنرم افزار كلاينت نوع اتصال را به Backend برای کشف و پخش محتوا جدا می کند. کلاینت از پروتکل NTBA [15] برای درخواست‌های پخش استفاده می‌کند تا از امنیت بیشتر مکان‌های سرور OCA خود اطمینان حاصل کند و تأخیر ناشی از یک دست دادن SSL/TLS برای اتصالات جدید را حذف کند.در حین پخش ویدیوها، برنامه Client به طور هوشمند کیفیت ویدیو را کاهش می دهد یا اگر اتصالات شبکه بیش از حد بارگیری شده باشد یا دارای خطا باشد، به سرورهای OCA مختلف [1] سوئیچ می کند. حتی اگر OCA متصل بیش از حد بارگیری شود یا ناموفق باشد، Client App می‌تواند به راحتی به سرور OCA دیگری برای تجربه مشاهده بهتر تغییر کند. همه اینها را می توان به این دلیل به دست آورد که SDK پلتفرم Netflix در Client آخرین OCA های سالم بازیابی شده از سرویس Playback Apps را ردیابی می کند (شکل 1).3-2-3-2- معماري Backend3-2-3-2-1- سرويس API Gatewayمؤلفه API Gateway Service با AWS Load Balancer ارتباط برقرار می کند تا تمام درخواست های مشتریان را حل کند. این مؤلفه را می توان در چندین نمونه AWS EC2 در مناطق مختلف مستقر کرد تا در دسترس بودن سرویس Netflix را افزایش دهد. نمودار در شکل 4 یک Zuul منبع باز را نشان می دهد، پیاده سازی API Gateway که توسط تیم Netflix ایجاد شده است.Zuul Gatewayشكل 4: مولفه ي سرويس 1- فیلترهای ورودی را می توان برای احراز هویت، مسیریابی و تزئین درخواست استفاده کرد.2- از فیلتر نقطه پایانی می توان برای بازگرداندن منابع استاتیک یا مسیریابی درخواست به مبدا یا API مناسب برای پردازش بیشتر استفاده کرد.3- فیلترهای خروجی را می توان برای ردیابی معیارها، تزئین پاسخ به کاربر یا اضافه کردن هدرهای سفارشی استفاده کرد.4- Zuul قادر است API API جدید را با ادغام با سرویس کشف Eureka کشف کند.5- Zuul به طور گسترده برای مسیریابی ترافیک برای اهداف مختلف مانند نصب API برنامه جدید، تست بارگذاری، مسیریابی به نقاط پایانی خدمات مختلف تحت بارهای کاری زیاد استفاده می شود.3-2-3-2-2- قسمت API Applicationقسمت API  نقش یک لایه ارکستراسیون [18] را برای میکروسرویس های Netflix ایفا می کند. API منطقی از ایجاد فراخوانی برای میکروسرویس های زیربنایی به ترتیب مورد نیاز، همراه با داده های اضافی از سایر ذخیره های داده برای ایجاد پاسخ های مناسب، ارائه می دهد. تیم نتفلیکس زمان زیادی را صرف طراحی مولفه Application API کرده است زیرا با عملکردهای اصلی کسب و کار Netflix مطابقت دارد. همچنین باید مقیاس پذیر باشد و در حجم درخواست بالا بسیار در دسترس باشد. در حال حاضر، APIهای برنامه تحت سه دسته تعریف می‌شوند: Signup API برای درخواست‌های غیرعضو مانند ثبت‌نام، صورت‌حساب، آزمایش رایگان و غیره، Discovery API برای جستجو، درخواست‌های توصیه و Play API برای پخش، مشاهده درخواست‌های مجوز. نمودار اجزای ساختاری دقیق Application API در شکل 5 ارائه شده است.شكل 5: جداسازی Play and Discovery Application API در به‌روزرسانی اخیر اجرای Play API، پروتکل شبکه بین Play API و میکروسرویس‌ها gRPC/HTTP2 است که به روش‌ها و موجودیت‌های RPC اجازه می‌دهد از طریق بافرهای پروتکل تعریف شوند، و کتابخانه‌های کلاینت/SDK به طور خودکار در زبان‌های مختلف تولید می‌شوند [ 13]. این تغییر به Application API اجازه می‌دهد تا از طریق ارتباط دو جهته با کلاینت‌های تولید شده به‌طور خودکار یکپارچه شود و استفاده مجدد از کد را در مرزهای سرویس به حداقل برساند.Application API همچنین یک مکانیسم انعطاف پذیر مشترک بر اساس دستورات Hystrix برای محافظت از میکروسرویس های زیرین خود ارائه می دهد.از آنجایی که Application API باید با حجم عظیمی از درخواست ها سر و کار داشته باشد و پاسخ های مناسب بسازد، پردازش داخلی آن باید به طور موازی اجرا شود. تیم نتفلیکس ترکیبی از اجرای همزمان و ورودی/خروجی ناهمزمان [13] را رویکرد مناسبی برای ادامه یافته است.هر درخواست از API Gateway Service برای پردازش در حلقه رویداد شبکه برنامه API قرار می گیرد.هر درخواست توسط یک کنترلر رشته اختصاصی مسدود می شود که دستورات Hystrix مانند getCustomerInfo، getDeviceInfo و غیره را در حلقه رویداد خروجی قرار می دهد. این حلقه رویداد خروجی به ازای هر مشتری تنظیم می‌شود و با ورودی/خروجی غیرمسدود اجرا می‌شود. هنگامی که میکروسرویس های فراخوانی به پایان می رسند یا به پایان می رسند، رشته اختصاصی پاسخ های مربوطه را ایجاد می کند.3-2-3-3- ميكروسرويس هاطبق تعریف مارتین فاولر، «سرویس‌های میکرو مجموعه‌ای از سرویس‌های کوچک هستند که هر یک در فرآیند خاص خود اجرا می‌شوند و با مکانیسم‌های سبک‌وزن ارتباط برقرار می‌کنند». این برنامه های کوچک به طور مستقل با توجه به دیگران قابل اجرا یا ارتقا هستند و داده های کپسوله شده خود را دارند. اجرای مولفه میکروسرویس در نتفلیکس [11] در شکل 7 نشان داده شده است.شكل 7: جزء ساختاری یک میکروسرویسیک میکروسرویس می‌تواند به تنهایی کار کند یا از طریق REST یا gRPC با میکروسرویس‌های دیگر تماس بگیرد.پیاده‌سازی میکروسرویس می‌تواند مشابه Application API باشد که در شکل 6 توضیح داده شده است که در آن درخواست‌ها در حلقه رویداد شبکه قرار می‌گیرند و نتایج سایر ریزسرویس‌های نامیده شده در صف نتیجه در I/O غیرمسدود ناهمزمان قرار می‌گیرند.هر میکروسرویس می‌تواند دیتا استور مخصوص به خود و برخی از حافظه‌های کش در حافظه نتایج اخیر را داشته باشد. EVCache یک انتخاب اصلی برای کش کردن میکروسرویس ها در Netflix است.3-2-3-4- ذخيره ي دادههنگام انتقال زیرساخت خود به ابر AWS، نتفلیکس از فروشگاه های داده مختلف (شکل 8)، هم SQL و هم NoSQL، برای اهداف مختلف استفاده کرد [6].شکل 8: فروشگاه های داده Netflix مستقر در AWSپایگاه داده MySQL برای مدیریت عنوان فیلم و اهداف تراکنش/صورتحساب استفاده می شود.Hadoop برای پردازش کلان داده ها بر اساس گزارش های کاربر استفاده می شود.ElasticSearch عناوین جستجو برای برنامه های Netflix را تقویت کرده است.Cassandra یک فروشگاه داده NoSQL مبتنی بر ستون توزیع شده برای رسیدگی به حجم زیادی از درخواست‌های خواندنی بدون هیچ نقطه‌ای از شکست است. برای بهینه‌سازی تأخیر در درخواست‌های نوشتن بزرگ، از Cassandra به دلیل توانایی در نهایت ثابت آن استفاده می‌شود.3-2-3-5- خط لوله ي پردازش جريانخط لوله پردازش جریان داده [14، 3] به ستون فقرات داده نتفلیکس برای تجزیه و تحلیل تجاری و وظایف توصیه شخصی تبدیل شده است. مسئولیت تولید، جمع‌آوری، پردازش، جمع‌آوری و انتقال همه رویدادهای میکروسرویس به سایر پردازشگرهای داده در زمان واقعی را بر عهده دارد. شکل 9 قطعات مختلف سکو را نشان می دهد. شکل 9: بستر پردازش جریان کیستون در نتفلیکسپلتفرم پردازش استریم روزانه تریلیون ها رویداد و پتابایت داده را پردازش می کند. همچنین با افزایش تعداد مشترکین، به طور خودکار مقیاس خواهد شد.ماژول روتر مسیریابی به سینک های داده یا برنامه های کاربردی مختلف را امکان پذیر می کند در حالی که کافکا مسئول مسیریابی پیام ها و همچنین بافر برای سیستم های پایین دست است.پردازش جریان به عنوان یک سرویس (SPaaS) به مهندسان داده اجازه می دهد تا برنامه های پردازش جریان مدیریت شده سفارشی خود را بسازند و نظارت کنند در حالی که پلت فرم از مقیاس پذیری و عملیات مراقبت می کند.3-2-4- قسمت Open Connectقسمت Open Connect  یک شبکه جهانی تحویل محتوا (CDN) است که مسئول ذخیره و ارائه نمایش‌ها و فیلم‌های تلویزیونی نتفلیکس به مشترکان خود در سراسر جهان است. نتفلیکس با نزدیک کردن محتوایی که مردم می‌خواهند تماشا کنند، Open Connect را تا حد امکان به جایی که می‌خواهند تماشا کنند، ساخته و به‌طور کارآمد اجرا کرده است. به منظور بومی سازی ترافیک تماشای ویدیوهای نتفلیکس به شبکه مشتریان، نتفلیکس با ارائه دهندگان خدمات اینترنت (ISP) و نقاط تبادل اینترنت (IX یا IXP) در سراسر جهان برای استقرار دستگاه های تخصصی به نام Open Connect Appliances (OCAs) همکاری کرده است. در داخل شبکه آنها [7].شکل 10: استقرار OCA ها در سایت های IX یا ISPقسمت OCA ها سرورهایی هستند که برای ذخیره و پخش فایل های ویدئویی بزرگ از سایت های IX یا ISP به طور مستقیم به خانه مشترکان بهینه شده اند. این سرورها به‌طور دوره‌ای مسیرهای بهینه معیارهای سلامتی را که از شبکه‌های IXP/ISP آموخته‌اند و چه ویدیوهایی را روی دیسک‌های SSD خود ذخیره می‌کنند تا خدمات Open Connect Control Plane در AWS گزارش کنند. در عوض، خدمات صفحه کنترل چنین داده‌هایی را برای هدایت خودکار دستگاه‌های کلاینت به بهینه‌ترین OCA با توجه به در دسترس بودن فایل، سلامت سرور و نزدیکی شبکه به کلاینت‌ها می‌برد.خدمات صفحه کنترل همچنین رفتار پر کردن اضافه کردن فایل‌های جدید یا به‌روزرسانی فایل‌ها در OCA‌ها را هر شب کنترل می‌کند. رفتارهای پر کردن [8،9] در شکل 11 نشان داده شده است.وقتی فایل‌های ویدیویی جدید با موفقیت رمزگذاری شدند و در AWS S3 ذخیره شدند، سرویس‌های صفحه کنترل در AWS این فایل‌ها را به سرورهای OCAs در سایت‌های IXP منتقل می‌کنند. این سرورهای OCA، حافظه پنهان را برای انتقال این فایل‌ها به سرورهای OCA در سایت‌های ISP تحت شبکه‌های فرعی خود اعمال می‌کنند.هنگامی که یک سرور OCA با موفقیت فایل‌های ویدیویی را ذخیره کرد، می‌تواند در صورت نیاز، فایل‌های همتا را برای کپی کردن این فایل‌ها در سایر سرورهای OCA در همان سایت شروع کند.بین 2 سایت مختلف که می توانند آدرس های IP یکدیگر را ببینند، OCA ها می توانند فرآیند پر کردن ردیف را به جای پر کردن کش معمولی اعمال کنند.شکل 11: الگوهای بین OCA ها3-3- الگوهاي طراحيدر بخش‌های قبلی، معماری ابر و اجزای آن را که به کسب و کار پخش ویدیوی نتفلیکس نیرو می‌دهند، با جزئیات شرح داده‌ام. در این بخش و بخش‌های بعدی، می‌خواهم به تحلیل این معماری طراحی عمیق‌تر بپردازم. فهرستی از مهمترین اهداف طراحی را به شرح زیر شروع می کنم:- از در دسترس بودن بالا برای خدمات پخش در مقیاس جهانی اطمینان حاصل کنید.- با قابلیت ارتجاعی با خرابی های شبکه و قطعی سیستم مقابله کنید.- تأخیر جریان را برای هر دستگاه پشتیبانی شده تحت شرایط شبکه مختلف به حداقل برسانید.- پشتیبانی از مقیاس پذیری در صورت حجم درخواست بالا.- در بخش‌های فرعی، من قصد دارم در دسترس بودن سرویس پخش و تأخیر بهینه مربوط به آن را تجزیه و تحلیل کنم. بخش 6 به تجزیه و تحلیل عمیق تر در مورد مکانیسم های انعطاف پذیری مانند مهندسی آشوب می پردازد در حالی که بخش 7 مقیاس پذیری سرویس های پخش را پوشش می دهد.1- در دسترس بودن بالاطبق تعریف، در دسترس بودن یک سیستم بر حسب تعداد دفعاتی که یک پاسخ برای یک درخواست در یک بازه زمانی مشخص می شود، بدون تضمین اینکه حاوی آخرین نسخه اطلاعات است، اندازه گیری می شود. در طراحی سیستم ما، در دسترس بودن سرویس‌های استریم بستگی به در دسترس بودن سرویس‌های Backend و سرورهای OCA دارد که فایل‌های ویدئویی جریانی را نگه می‌دارند.هدف خدمات Backend دریافت لیستی از نزدیکترین OCAهای سالم به یک کلاینت خاص، چه از حافظه پنهان یا با اجرای برخی از ریزسرویسها است. بنابراین، در دسترس بودن آن به مؤلفه‌های مختلف مربوط به درخواست پخش بستگی دارد: متعادل‌کننده‌های بار (AWS ELB)، سرورهای پروکسی (سرویس دروازه API)، Play API، اجرای میکروسرویس‌ها، ذخیره‌های کش (EVCache) و ذخیره‌سازی داده (Cassandra).متعادل‌کننده‌های بار می‌توانند با مسیریابی ترافیک به سرورهای پراکسی مختلف دسترسی را بهبود بخشند تا از بار کاری بیش از حد جلوگیری شود.Play API اجرای میکروسرویس‌ها را با مهلت زمانی از طریق دستورات Hystrix کنترل می‌کند که می‌تواند به جلوگیری از خرابی‌های آبشاری در سرویس‌های بعدی کمک کند.میکروسرویس‌ها می‌توانند با داده‌های موجود در حافظه پنهان به Play AI پاسخ دهند، در صورتی که تماس با سرویس‌های خارجی یا فروشگاه‌های داده بیشتر از حد انتظار طول بکشد.کش برای دسترسی سریع‌تر تکرار می‌شود.هنگام دریافت لیست سرورهای OCA از Backend، سرویس گیرنده شبکه را به این OCA ها بررسی می کند و بهترین OCA ها را برای اتصال انتخاب می کند. اگر آن OCA بیش از حد بارگیری شود یا در طول فرآیند پخش ناموفق باشد، مشتری به یکی دیگر از موارد خوب تغییر می کند یا پلتفرم SDK OCA های دیگری را درخواست می کند. بنابراین در دسترس بودن آن با در دسترس بودن همه OCA های موجود در ISP یا IXP آن ارتباط زیادی دارد.در دسترس بودن بالای خدمات پخش Netflix به قیمت عملیات و خدمات پیچیده AWS چند منطقه ای و همچنین افزونگی سرورهای OCA است.2- تاخیر کمتأخیر سرویس‌های پخش بیشتر به این بستگی دارد که API Play چقدر می‌تواند فهرست OCA‌های سالم را حل کند و ارتباط مشتری با سرور OCA انتخابی چقدر است.همانطور که در بخش Application API توضیح داده‌ام، Play API برای همیشه منتظر اجرای میکروسرویس نمی‌ماند، زیرا از دستورات Hystrix برای کنترل مدت زمانی استفاده می‌کند که می‌خواهد برای نتیجه منتظر بماند تا داده‌های به‌روز نشده را دریافت کند. حافظه پنهان انجام این کار می تواند تأخیر قابل قبول را کنترل کند و همچنین خرابی های آبشاری برای خدمات بعدی را متوقف کند.اگر شبکه سرور OCA انتخابی فعلی خراب شود یا سرور بیش از حد بارگیری شود، کلاینت بلافاصله به سایر سرورهای OCA نزدیک با قابل اطمینان ترین اتصال شبکه سوئیچ می کند. همچنین می‌تواند کیفیت ویدیو را برای مطابقت با کیفیت شبکه کاهش دهد تا در صورت مشاهده کاهش در اتصال شبکه.4- شركت Airbnb4-1- معرفيشركت Airbnb وب سایتی است که یک بازار آنلاین و خدمات مهمان نوازی را برای افراد برای اجاره یا اجاره مسکن کوتاه مدت ارائه می دهد. چالش های تیم مهندسی شامل دسترسی بالا، مقیاس پذیری سریع و ... است.4-2- معماريجسيكا تاي يكي از مديران اين شركت مي گويد: در ابتدای Airbnb، معماری ما واقعا ساده بود. این یک برنامه یکپارچه Ruby on Rails بود که به عنوان monorail شناخته می شد. بیایید معماری خود را به عنوان یک طناب نشان دهیم. اگر آن را تصور کنید، یک طناب است که به راحتی می توان آن را دنبال کرد و به راحتی باز می شود. با این حال، زمانی که توسعه دهندگان در طول سالیان متمادی کد را به مونوریل اضافه می کردند، این طناب ساده به زودی به یک گره پیچیده تبدیل شد. فهمیدن مونوریل سخت شد و مولد بودن در آن سخت شد. مهندسان وقتی مجبور به تغییر و استقرار مونوریل می شدند ناله می کردند. واضح بود که باید دریابیم که چگونه این آشفتگی اسپاگتی را باز کنیم. راه حلی که به آن رسیدیم مهاجرت به معماری سرویس گرا یا SOA بود. SOA این گره مونوریل عظیم را در خدمات محصور شده جداگانه سازماندهی کرد که در اینجا به صورت تکه های طناب مختلف نشان داده شده است. اولین نسخه ما از SOA بسیار شبیه به نمای مدل در لایه های کنترل کننده مونوریل به نظر می رسید و به ما کمک کرد تا از دردسرهای رو به رشد آن زمان عبور کنیم. با این حال، در نهایت، زیرا ما صدها سرویس را توسعه داده بودیم، چالش های جدیدی ظاهر شد. چیزی که قبلا ماژول و تمیز به نظر می رسید، اکنون دوباره شروع به یک سری پیچ و تاب و گره پیچیده می کند[22].شركت Airbnb از خدمات AWS استفاده می‌کند. از نمونه‌های EC2 برای برنامه‌های کاربردی، حافظه پنهان و سرورهای جستجو استفاده می‌کند. از RDS به عنوان پایگاه داده اصلی MySQL استفاده می‌کند. از ELB برای متعادل کردن بار ترافیکی استفاده کرد. از EMR برای پردازش و تجزیه و تحلیل روزانه داده‌ها استفاده می‌کند. از S3 برای پشتیبان‌گیری و فایل‌های ثابت، از جمله تصاویر کاربر استفاده می‌کند. از Amazon CloudWatch برای نظارت بر دارایی‌های ES2 استفاده می‌کند[28].متعادل‌کننده بار: Charon، متعادل‌کننده بار جلوی Airbnb است. قبلاً ELB آمازون بود. این تصمیم مبتنی بر این واقعیت است که ELB درهم و برهم بود و برای عیب‌یابی کمتر مفید بود[29].پایگاه داده: Airbnb از Amazon RDS به عنوان پایگاه داده اصلی MySQL استفاده می‌کند. پایگاه‌های داده در چند AZ (منطقه در دسترس) مستقر شده‌اند. چندین نوع پایگاه داده برای سناریوهای مختلف وجود دارد، به عنوان مثال، تقویم، پیام، و غیره[30].پایگاه داده تحلیلی: زیرساخت داده‌های Airbnb معیارها را مدیریت می‌کند، مدل‌های یادگیری ماشینی را آموزش می‌دهد و تجزیه و تحلیل‌های تجاری و غیره را اجرا می‌کند.از خدمات زیر AWS استفاده می کند[23]:- از نمونه های EC2 برای برنامه های کاربردی، حافظه پنهان و سرورهای جستجو استفاده می کند.- از RDS به عنوان پایگاه داده اصلی MySQL استفاده می کند.- از ELB برای تعادل بار ترافیکی استفاده کرد (توجه: به نظر می رسد دیگر استفاده نمی شود، بخش Load Balancer را در زیر بررسی کنید.).- از EMR برای پردازش و تجزیه و تحلیل روزانه داده ها استفاده می کند (توجه: به نظر می رسد تا حدودی قدیمی است، بخش انبار داده را در زیر بررسی کنید). - از S3 برای پشتیبان گیری و فایل های ثابت، از جمله تصاویر کاربر استفاده می کند. - از Amazon CloudWatch برای نظارت بر دارایی های ES2 استفاده می کند.4-3- کشف خدمات[24]SmartStack یک چارچوب کشف سرویس OSS است. دو جزء دارد: عصب و سیناپس به Zookeeper برای ذخیره داده های کشف و همچنین HAProxy برای مسیریابی متکی است. Nerve چرخه زندگی میکروسرویس ها را بر اساس بررسی های سلامت مدیریت می کند. Synapse نمونه های میکروسرویس را جستجو می کند و پیکربندی HAProxy را به طور خودکار به روز می کند. Zookeeper znode را برای نام سرویس‌ها ذخیره می‌کند و نمونه‌های میکروسرویس تغییر را از طریق ساعت‌های Zookeeper ارائه می‌کند.4-4- پايگاه دادهAirbnb از Amazon RDS به عنوان پایگاه داده اصلی MySQL استفاده می کند. پایگاه های داده در چند AZ (منطقه در دسترس) مستقر شده اند. معماری 3 لایه زیر الگوی اصلی را منعکس می کند. توجه داشته باشید که چندین نوع پایگاه داده برای سناریوهای مختلف وجود دارد، به عنوان مثال، airmaster، تقویم، پیام، و غیره. بنابراین، بیش از دوجین dbproxy وجود دارد و صدها نمونه پایگاه داده مستقر می شوند.شكل 12: پايگاه دادهآنها نسخه جامعه سرور MySQL هستند.هر سرور MySQL از مدل یک رشته در هر اتصال استفاده می کند.Airbnb فورک شده و اصلاح شده است. MariaDB MaxScale برای پراکسی پایگاه داده.عملکردهای اصلی این لایه پروکسی عبارتند از: ادغام اتصال، کاهش درخواست، فهرست بلوک پرس و جو و غیره.4-5- پایگاه داده تحلیلیزیرساخت داده‌های Airbnb معیارها را مدیریت می‌کند، مدل‌های یادگیری ماشینی را آموزش می‌دهد و تجزیه و تحلیل‌های تجاری و غیره را اجرا می‌کند[27].شكل 13: پايگاه داده ي تحليلي- کافکا به عنوان یک واسطه برای گزارش رویدادها عمل می کند. - Sqoop به عنوان یک کارگزار برای تخلیه پایگاه داده تولید عمل می کند. - خوشه Gold and Silver Hive سینک های داده هستند. خوشه Gold Hive داده ها را به نقره تقلید می کند.    خوشه Gold Hive دارای ضمانت SLA بالاتری است.  - یک Spark Cluster بر روی یادگیری ماشینی برای پردازش جریانی کار می کند.  - یک خوشه Presto برای پرس و جوی موقت است.  - یک برنامه Airflow در جلو برای برنامه ریزی کار اجرا می شود.  - S3 یک راه حل بلند مدت برای داده های HDFS است.4-6- میکروسرویس هاشركت Airbnb از Dropwizard استفاده می کند. چارچوب سرویس، و یک سرویس Thrift IDL را سفارشی کرد.توسعه دهندگان می توانند بین JSON-over-http و Thrift-over-http یکی را انتخاب کنند. سرویس های پایین دستی باید کلاینت های RPC تولید شده را از بالادست نصب کنند.سرویس‌های پایین‌دستی همچنین نیاز به اعمال زمان استاندارد، امتحان مجدد و منطق قطع کننده مدار دارند.این چارچوب معیارهای درخواست و پاسخ را هم در سمت سرویس و هم در سمت مشتری اضافه می کند.چارچوب، زمینه درخواست‌ها، از جمله شناسه درخواست را به تمام درخواست‌های خدمات اساسی اضافه می‌کند. این چارچوب از افزودن هشدارها بر اساس معیارهایی مانند p95_latency، p99_latency و غیره پشتیبانی می‌کند[25].4-7- سرويس جست و جوشكل 14: سرويس جست و جوسرويس Nebula یک سرویس ذخیره داده بدون طرح و نسخه است که هم دسترسی تصادفی به داده ها در زمان واقعی و هم مدیریت داده های دسته ای آفلاین دارد. جریان جستجو فقط مقداری منطق نمایه سازی جستجو را به این سیستم اضافه می کند. عکس فوری روزانه به عنوان بخشی از ادغام داده های آفلاین تولید می شود. فهرست جستجو از روی عکس فوری ساخته شده و سپس برای جستجوی دوره ای به عنوان یک استقرار باینری معمولی استفاده می شود[26].5- مقايسه‌ي دو معمارياستفاده از سرويس هاي ابري آمازون، معماري ميكروسرويس، MySQL و NoSQL بين معاري اين دو شركت مشترك است. اما با توجه به اهداف پياده سازي مانند ميزان در درس بودن سيستم استفاده از تكنولوژي هاي براي اين معماري ها متفاوت است. 6- جمع بندياین مطالعه کل معماری ابری خدمات استریم در Netflix و Airbnb را تشریح کرده است. همچنین اهداف طراحی مختلف را از نظر در دسترس بودن، تأخیر، مقیاس پذیری و انعطاف پذیری در برابر خرابی های شبکه یا قطع سیستم تجزیه و تحلیل کرد. به طور خلاصه، معماری ابری نتفلیکس، که توسط سیستم تولید آن ثابت شده است که به میلیون‌ها مشترکی که روی هزاران سرور مجازی کار می‌کنند، ارائه می‌کند، در دسترس بودن بالا با تأخیر بهینه، مقیاس‌پذیری قوی از طریق ادغام با سرویس‌های ابری AWS و قابلیت انعطاف‌پذیری در برابر خرابی‌های شبکه و قطعی سیستم نشان داده است. در مقیاس جهانی بیشتر معماری و اجزای مشتق شده از طریق منابع قابل اعتماد آنلاین موجود آموخته می شود. اگرچه منابع مستقیم زیادی برای توصیف پیاده‌سازی داخلی میکروسرویس‌ها و همچنین ابزارها و سیستم‌ها برای نظارت بر عملکرد آنها وجود ندارد، این مطالعه می‌تواند به عنوان یک پیاده‌سازی مرجع برای چگونگی ساخت یک سیستم تولید معمولی عمل کند.این فرآیند ما را به توسعه سیستم زبان طراحی جدید (یا DLS) و همچنین مجموعه‌ای از ابزارهای داخلی و شخص ثالث هدایت کرد که به تیم‌های ما اجازه می‌دهد نه تنها هوشمندانه‌تر، بلکه نزدیک‌تر کار کنند. DLS مجموعه ای از مؤلفه ها است که با اصول و الگوهای مشترک تعریف شده اند. این امکان تکرار سریع با استفاده از واژگان مشترک در طراحی، مهندسی و سایر رشته ها را فراهم می کند. ساختار DLS ساده و منسجم است و ارتباط بین تیم ها را آسان می کند.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»منابعNetflix: What Happens When You Press Play? By Todd Hoff on Dec 11, 2017. LinkHigh Quality Video Encoding at Scale. By Anne Aaron and David Ronca on HighScalability. Dec 9, 2015. LinkBuilding and Scaling Data Lineage at Netflix to Improve Data Infrastructure Reliability, and Efficiency. By Di Lin, Girish Lingappa, Jitender Aswani on The Netflix Tech Blog. Mar 25, 2019. LinkTen years on: How Netflix completed a historic cloud migration with AWS. By Tom Macaulay on Computerworld. Sep 10, 2018. LinkThe Netflix Simian Army. By Yury Izrailevsky and Ariel Tseitlin on The Netflix Tech Blog. LinkGlobally Cloud Distributed Applications at Netflix. By Adrian Cockcroft. Oct 2012. LinkOpen Connect Overview. By Netflix. LinkOpen Connect Deployment Guide. By Netflix. LinkNetflix and Fill. By Michael Costello and Ellen Livengood. Aug 11, 2016. LinkAutomating Operations of a Global CDN. By Robert Fernandes at Strange Loop. Sep 14, 2019. LinkMastering Chaos — A Netflix Guide to Microservices. By Josh Evans at QCon. Dec 07, 2016. LinkNetflix Revenue and Usage Statistics. By Mansoor Iqbal on BusinessofApps. March 6, 2020. LinkNetflix Play API — Why we build an Evolutionary Architecture. By Suudhan Rangarajan at QCon 2018. Dec 12, 2018. LinkKeystone Real-time Stream Processing Platform. By Zhenzhong Xu on The Netflix Tech Blog. Sep 10, 2018. LinkNetflix Releases Open Source Message Security Layer. By Chris Swan on InfoQ. Nov 24th, 2014. LinkNetflix Open Source. LinkTitus, the Netflix container management platform, is now open source. By Amit Joshi and others. LinkEngineering Trade-Offs and The Netflix API Re-Architecture. By Katharina Probst and Justin Becker on The Netflix Tech Blog. Aug 23, 2016. LinkKafka Inside Keystone Pipeline. By Real-Time Data Infrastructure Team. April 27, 2016. LinkOpen Sourcing Zuul 2. By Arthur Gonigberg and others on The Netflix Tech Blog. May 21, 2018. LinkPerformance Vs Scalability. By Beekums. Aug 19, 2017. LinkData Infrastructure at Airbnb Scaling Airbnb&amp;amp;amp;#x27;s Experimentation PlatformWhat is the Airbnb Software ArchitectureAirbnb Case StudyBinaryAlert: Real-time Serverless Malware DetectionAlerting Framework at AirbnbScaling Airbnb Payment PlatformMeasuring Transactional Integrity in Airbnb&amp;amp;amp;#x27;s Distributed Payment EcosystemTracking the Money - Scaling Financial Reporting at Airbnb </description>
                <category>faezeh montazerin</category>
                <author>faezeh montazerin</author>
                <pubDate>Sat, 12 Feb 2022 20:21:15 +0330</pubDate>
            </item>
                    <item>
                <title>آشنایی با Continuous Delivery</title>
                <link>https://virgool.io/@faezehmonta1995/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-continuous-delivery-lydzw1iy35sn</link>
                <description>1- مقدمه و کاربردتحویل مداوم یک روش توسعه نرم افزار است که در آن تغییرات کد به طور خودکار برای عرضه به تولید آماده می شود. یکی از ستون‌های توسعه برنامه‌های کاربردی مدرن، تحویل مستمر پس از یکپارچگی مداوم با استقرار همه تغییرات کد در یک محیط آزمایش و/یا یک محیط تولید پس از مرحله ساخت، گسترش می‌یابد. زمانی که توسعه دهندگان به درستی پیاده سازی شوند، همیشه یک مصنوع ساخت آماده برای استقرار خواهند داشت که از یک فرآیند تست استاندارد عبور کرده است.تحویل مستمر به توسعه‌دهندگان امکان می‌دهد تست‌های فراتر از تست‌های واحد را به‌طور خودکار انجام دهند تا بتوانند به‌روزرسانی‌های برنامه را در ابعاد مختلف قبل از استقرار برای مشتریان تأیید کنند. این تست‌ها ممکن است شامل تست UI، تست بارگذاری، تست یکپارچه‌سازی، تست قابلیت اطمینان API و غیره باشد. این به توسعه‌دهندگان کمک می‌کند تا به‌روزرسانی‌ها را به‌طور کامل اعتبارسنجی کنند و پیشگیرانه مشکلات را کشف کنند. با استفاده از فضای ابری، خودکارسازی ایجاد و تکثیر چندین محیط برای آزمایش، که قبلاً انجام آن در محل دشوار بود، آسان و مقرون به صرفه است.تحویل مستمر در مقابل استقرار مستمربا تحویل مداوم، هر تغییر کد ساخته می‌شود، آزمایش می‌شود و سپس به یک محیط آزمایش یا مرحله‌بندی غیرتولیدی هدایت می‌شود. ممکن است چندین مرحله آزمایش موازی قبل از استقرار تولید وجود داشته باشد. تفاوت بین تحویل مداوم و استقرار مداوم وجود تأییدیه دستی برای به روز رسانی به تولید است. با استقرار مداوم، تولید به طور خودکار و بدون تأیید صریح اتفاق می افتد.تحویل مداوم کل فرآیند انتشار نرم افزار را خودکار می کند. هر تجدیدنظری که انجام می شود یک جریان خودکار را راه اندازی می کند که به روز رسانی را ایجاد، آزمایش و سپس مرحله بندی می کند. تصمیم نهایی برای استقرار در یک محیط تولید زنده توسط توسعه دهنده انجام می شود.مزایا1- انتشار کم خطر: هدف اولیه از تحویل مداوم این است که پیاده‌سازی نرم‌افزار را بدون دردسر و رویدادهای کم خطری که می‌توان در هر زمان و بنا به درخواست انجام داد، انجام داد. با بکارگیری الگوهایی مانند استقرارهای سبز-آبی، دستیابی به استقرارهای زمان توقف صفر که برای کاربران غیرقابل شناسایی هستند، نسبتاً ساده است.2- زمان سریعتر: برای بازاریابی غیرمعمول نیست که مرحله ادغام و آزمایش/تثبیت چرخه عمر مرحله ای سنتی تحویل نرم افزار هفته ها یا حتی ماه ها طول بکشد. هنگامی که تیم ها برای خودکارسازی ساخت و استقرار، تهیه محیط و فرآیندهای تست رگرسیون با هم کار می کنند، توسعه دهندگان می توانند تست یکپارچه سازی و رگرسیون را در کار روزانه خود بگنجانند و این مراحل را به طور کامل حذف کنند. ما همچنین از حجم زیاد دوباره کاری که رویکرد مرحله‌ای را آزار می‌دهد اجتناب می‌کنیم.3- کیفیت بالاتر: وقتی توسعه‌دهندگان ابزارهای خودکاری دارند که در عرض چند دقیقه رگرسیون‌ها را کشف می‌کنند، تیم‌ها آزاد می‌شوند تا تلاش خود را بر روی تحقیقات کاربر و فعالیت‌های تست سطح بالاتر مانند تست اکتشافی، تست قابلیت استفاده، و تست عملکرد و امنیت متمرکز کنند. با ساخت یک خط لوله استقرار، این فعالیت ها می توانند به طور مداوم در طول فرآیند تحویل انجام شوند و اطمینان حاصل شود که از ابتدا کیفیت در محصولات و خدمات تعبیه شده است.4- هزینه های پایین تر: هر محصول یا خدمات نرم افزاری موفقی در طول عمر خود به طور قابل توجهی تکامل می یابد. با سرمایه‌گذاری در ساخت، آزمایش، استقرار و اتوماسیون محیطی، ما با حذف بسیاری از هزینه‌های ثابت مرتبط با فرآیند انتشار، هزینه ایجاد و ارائه تغییرات تدریجی در نرم‌افزار را به‌طور قابل ملاحظه‌ای کاهش می‌دهیم.5- محصولات بهتر: تحویل مداوم کار را در دسته های کوچک اقتصادی می کند. این بدان معنی است که ما می توانیم در طول چرخه عمر تحویل بر اساس نرم افزار کار از کاربران بازخورد دریافت کنیم. تکنیک‌هایی مانند تست A/B ما را قادر می‌سازد تا رویکردی مبتنی بر فرضیه برای توسعه محصول داشته باشیم که به موجب آن می‌توانیم ایده‌ها را با کاربران قبل از ایجاد ویژگی‌های کامل آزمایش کنیم. این بدان معناست که می‌توانیم از 2/3 ویژگی‌هایی که می‌سازیم که ارزش صفر یا منفی را به کسب‌وکارمان ارائه می‌کنند، اجتناب کنیم.6- تیم های شادتر: تحقیقات بررسی شده نشان داده است که تحویل مداوم باعث کاهش درد و کاهش فرسودگی تیم می شود. علاوه بر این، هنگامی که ما به دفعات بیشتری منتشر می کنیم، تیم های تحویل نرم افزار می توانند فعالانه تر با کاربران درگیر شوند، یاد بگیرند که کدام ایده ها کار می کنند و کدام نه، و نتایج کاری را که انجام داده اند، از نزدیک ببینند. با حذف فعالیت‌های دردناک کم‌ارزش مرتبط با تحویل نرم‌افزار، می‌توانیم روی چیزی که بیشتر به آن اهمیت می‌دهیم تمرکز کنیم - به طور مداوم کاربران خود را خوشحال کنیم.ارتباط با DevOpsتحویل مداوم و DevOps از نظر معانی مشابه هستند و اغلب با هم ترکیب می شوند، اما آنها دو مفهوم متفاوت هستند. DevOps دامنه وسیع تری دارد و حول محور تغییرات فرهنگی، به ویژه همکاری تیم های مختلف درگیر در تحویل نرم افزار (توسعه دهندگان، عملیات، تضمین کیفیت، مدیریت، و غیره)، و همچنین خودکارسازی فرآیندها در تحویل نرم افزار متمرکز است. از سوی دیگر، تحویل مستمر رویکردی برای خودکارسازی جنبه تحویل است و بر گردآوری فرآیندهای مختلف و اجرای سریعتر و مکرر آنها تمرکز دارد. بنابراین، DevOps می تواند محصول تحویل مداوم باشد و CD مستقیماً به DevOps جریان می یابد.خط لوله استقرارتحویل مداوم از طریق خط لوله استقرار فعال می شود. هدف خط لوله استقرار دارای سه جزء است: دید، بازخورد، و استقرار مداوم.قابلیت مشاهده - تمام جنبه های سیستم تحویل از جمله ساخت، استقرار، آزمایش و انتشار برای همه اعضای تیم برای ارتقای همکاری قابل مشاهده است.بازخورد - اعضای تیم در صورت بروز مشکلات در اسرع وقت از آنها مطلع می شوند تا بتوانند در اسرع وقت آنها را برطرف کنند.استقرار مداوم - از طریق یک فرآیند کاملاً خودکار، می توانید هر نسخه از نرم افزار را در هر محیطی استقرار و منتشر کنید.ابزار/انواع ابزارتحویل مداوم، اتوماسیون را از کنترل منبع تا پایان تولید می‌گیرد. ابزارهای مختلفی وجود دارد که به انجام تمام یا بخشی از این فرآیند کمک می کند. این ابزارها بخشی از خط لوله استقرار هستند که شامل تحویل مداوم است. انواع ابزارهایی که بخش‌های مختلف فرآیند را اجرا می‌کنند عبارتند از: یکپارچه‌سازی مداوم، اتوماسیون انتشار برنامه، اتوماسیون ساخت، مدیریت چرخه عمر برنامه.معماری برای تحویل مداومبرای اجرای مؤثر تحویل مستمر، برنامه‌های نرم‌افزاری باید مجموعه‌ای از الزامات مهم معماری (ASR) مانند قابلیت استقرار، تغییرپذیری و آزمایش‌پذیری را برآورده کنند. این ASR ها نیاز به اولویت بالایی دارند و نمی توان آنها را به راحتی معامله کرد.میکروسرویس ها اغلب هنگام معماری برای تحویل مداوم استفاده می شوند. استفاده از Microservices می تواند قابلیت استقرار و تغییرپذیری یک سیستم نرم افزاری را افزایش دهد. پیشرفت‌های قابل استقرار مشاهده‌شده عبارتند از: استقلال استقرار، زمان استقرار کوتاه‌تر، روش‌های استقرار ساده‌تر، و استقرار زمان توقف صفر. پیشرفت‌های قابل تغییر مشاهده‌شده عبارتند از: زمان چرخه کوتاه‌تر برای تغییرات عملکردی افزایشی کوچک، تغییرات آسان‌تر در انتخاب فناوری، تغییرات ویژگی کیفیت افزایشی، و ارتقای زبان و کتابخانه آسان‌تر.محدودیت‌ها1- ترجیحات مشتری: برخی از مشتریان به روز رسانی مداوم سیستم های خود را نمی خواهند. این امر به ویژه در مراحل بحرانی عملیات آنها صادق است.2- محدودیت‌های دامنه: در برخی حوزه‌ها، مانند مخابرات و پزشکی، مقررات نیاز به آزمایش گسترده قبل از ورود نسخه‌های جدید به فاز عملیاتی دارند.3- عدم اتوماسیون تست: عدم اتوماسیون تست منجر به عدم اطمینان توسعه دهنده می شود و می تواند از استفاده مداوم از تحویل جلوگیری کند.4- تفاوت در محیط ها: محیط های مختلف مورد استفاده در توسعه، آزمایش و تولید می تواند منجر به لغزش مسائل ناشناخته به محیط تولید شود.5- آزمایش‌هایی که به اوراکل انسانی نیاز دارند: همه ویژگی‌های کیفیت را نمی‌توان با اتوماسیون تأیید کرد. این ویژگی‌ها به انسان‌ها در حلقه نیاز دارند و خط لوله تحویل را کاهش می‌دهند.تضمین تحویل مستمراز همان ابزارهایی که CI/CD را خودکار می کنند، می توان برای خودکارسازی امنیت نیز استفاده کرد. کالین کمپبل، مدیر الگوها و شیوه‌ها در Chef، این داستان را نقل می‌کند: «یک سازمان مالی بزرگ بلافاصله مزایای استفاده از پلتفرم اتوماسیون سرآشپز را زمانی که Shellshock در سال 2014 وارد شد، دید. این شرکت 2200 سرور را به Chef منتقل کرده بود و آن 2200 سرور را برد. 10 دقیقه برای گزارش آسیب‌پذیری و خود پچ کردن. 66000 سرور این شرکت که به آشپز منتقل نکرده بودند؟ هشت ساعت برای شناسایی آسیب‌پذیری، پنج روز برای وصله تمام سرورها و یک تیم ۱۸ نفره برای حل این مشکل طول کشید.»خط لوله CI/CDخط لوله CI/CD مجموعه ای از مراحل است که به منظور ارائه نسخه جدیدی از نرم افزار انجام می شود. وقتی CI/CD را در عمل پیاده کردید، یک خط لوله CI/CD ایجاد کرده اید.خط لوله CI/CD، نظارت و اتوماسیون را برای بهبود گردش کار توسعه برنامه، به ویژه در مراحل یکپارچه سازی و آزمایش، و همچنین در حین تحویل و استقرار معرفی می کند.اگرچه امکان اجرای دستی هر یک از مراحل یک خط لوله CI/CD وجود دارد، اما ارزش واقعی خطوط لوله CI/CD از طریق اتوماسیون چرخه عمر برنامه محقق می شود.2- ابزارهای مرتبط1- ابزار Buddyابزار Buddy یک ابزار هوشمند CI/CD برای توسعه دهندگان وب است که برای کاهش آستانه ورود به DevOps طراحی شده است. از خطوط لوله تحویل برای ساخت، آزمایش و استقرار نرم افزار استفاده می کند. خطوط لوله با بیش از 100 اقدام آماده برای استفاده ایجاد شده اند که می توان آنها را به هر شکلی مرتب کرد - درست مانند ساختن خانه ای از آجر.پیکربندی 15 دقیقه‌ای در UI/UX واضح و گویااستقرار سریع رعد و برق بر اساس تغییراتبیلدها در کانتینرهای ایزوله با وابستگی های کش اجرا می شونداز همه زبان‌ها، فریم‌ورک‌ها و مدیران وظیفه پشتیبانی می‌کندفهرست اختصاصی اقدامات Docker/Kubernetesبا AWS، Google، DigitalOcean، Azure، Shopify، WordPress و موارد دیگر ادغام می شوداز موازی سازی و پیکربندی YAML پشتیبانی می کند2- ابزار JBossابزار JBOSS متعلق به Red Hat یک سرور برنامه وب است که به طور کامل به منظور میزبانی برنامه های مبتنی بر JAVA (برنامه های توسعه یافته با استفاده از پلت فرم Java EE) یکپارچه شده است.این شامل سرور HTTP آپاچی، موتورهای سرولت، متعادل کننده بار و کتابخانه بومی آپاچی تامکت است. JBOSS قابلیت اجرا بر روی چندین پلتفرم را دارد.3- ابزار TOMCATآپاچی TOMCAT که به آن سرور تامکت نیز گفته می شود توسط ASF (بنیاد نرم افزار آپاچی) توسعه یافته است. این شامل ادغام مشخصات مختلف جاوا مانند Java Servlet، Java EE، Java EL، سوکت وب، صفحات سرور، عبارات جاوا و غیره است که یک محیط خالص برای اجرای کد جاوا ایجاد می کند.وب سرور Tomcat از برنامه های متعدد در چندین پلتفرم پشتیبانی می کند و تحت مجوز Apache 2.0 منتشر شده است.3- شرکت‌های فعال در این زمینه1- ابراروان مسئله‌ی Delivery &amp; Deployment مستمربا اتصال Source Code Managementهایی چون Git Lab به سکوی ابری آروان، با هر تغییر در کد اصلی به‌شکل خودکار تغییرات در خروجی نهایی محصول اعمال می‌شود.2- لیاراهمه ما با دغدغه‌ها و مسائل مربوط به مدیریت سرور آشنا هستیم، هدف لیارا با ارائه خدمات ابری PaaS یا Platform as a Service و DBaaS یا DataBase as a Service ایجاد زیرساختی مناسب است تا توسعه‌دهندگان و استارتاپ‌های ایرانی به راحتی و در کمترین زمان، بتوانند محصول خود را به بازار عرضه کنند.جمع‌بندیادغام مستمر و تحویل مستمر یک سناریوی ایده آل برای تیم های برنامه سازمان شما فراهم می کند. توسعه دهندگان شما به سادگی کد را به یک مخزن فشار می دهند. این کد یکپارچه می شود، آزمایش می شود، مستقر می شود، دوباره آزمایش می شود، با زیرساخت ادغام می شود، بررسی های امنیتی و کیفیت را طی می کند و با اطمینان بسیار بالا آماده استقرار می شود.وقتی از CI/CD استفاده می‌شود، کیفیت کد بهبود می‌یابد و به‌روزرسانی‌های نرم‌افزار به سرعت و با اطمینان بالا ارائه می‌شوند که هیچ تغییری ایجاد نمی‌کند. تأثیر هر انتشار می تواند با داده های تولید و عملیات مرتبط باشد. می‌توان از آن برای برنامه‌ریزی چرخه بعدی نیز استفاده کرد - یک تمرین حیاتی DevOps در تحول ابری سازمان شما.منابع1- https://aws.amazon.com/devops/continuous-delivery/2- https://en.wikipedia.org/wiki/Continuous_delivery3- https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment4- https://www.synopsys.com/glossary/what-is-continuous-delivery.html5- https://www.redhat.com/en/topics/devops/what-is-continuous-delivery6-https://www.softwaretestinghelp.com/best-continuous-delivery-tools/7- https://www.arvancloud.com/fa/products/paas8- https://liara.ir/«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»</description>
                <category>faezeh montazerin</category>
                <author>faezeh montazerin</author>
                <pubDate>Fri, 24 Dec 2021 12:24:45 +0330</pubDate>
            </item>
                    <item>
                <title>آشنایی با API Gateway</title>
                <link>https://virgool.io/@faezehmonta1995/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-api-gateway-ah4srnliokkk</link>
                <description>1- آشنایی و کاربردشکل 1: معماری API Gateway آمازونچرا از دروازه API استفاده کنیم؟اکثر API های سازمانی از طریق دروازه های API مستقر می شوند. برای دروازه‌های API معمول است که وظایف مشترکی را که در یک سیستم از سرویس‌های API استفاده می‌شوند، مانند احراز هویت کاربر، محدود کردن نرخ و آمار انجام دهند.در ابتدایی ترین حالت، یک سرویس API یک درخواست راه دور را می پذیرد و یک پاسخ را برمی گرداند. اما زندگی واقعی هرگز به این سادگی نیست. نگرانی های مختلف خود را هنگام میزبانی API در مقیاس بزرگ در نظر بگیرید.شما می خواهید از API های خود در برابر استفاده بیش از حد و سوء استفاده محافظت کنید، بنابراین از یک سرویس احراز هویت و محدودیت نرخ استفاده می کنید.شما می خواهید بدانید که مردم چگونه از API های شما استفاده می کنند، بنابراین ابزارهای تجزیه و تحلیل و نظارت را اضافه کرده اید.اگر از APIهای درآمدزایی دارید، باید به یک سیستم صورتحساب متصل شوید.ممکن است شما یک معماری میکروسرویس را اتخاذ کرده باشید، در این صورت یک درخواست می تواند به تماس با ده ها برنامه متمایز نیاز داشته باشد.با گذشت زمان، برخی از سرویس‌های API جدید را اضافه می‌کنید و برخی دیگر را بازنشسته می‌کنید، اما مشتریان شما همچنان می‌خواهند همه سرویس‌های شما را در همان مکان پیدا کنند.چالش شما ارائه یک تجربه ساده و قابل اعتماد در برابر این همه پیچیدگی به مشتریان خود است. دروازه API راهی برای جدا کردن رابط مشتری از پیاده سازی باطن شما است. هنگامی که یک کلاینت درخواستی می دهد، دروازه API آن را به چندین درخواست تقسیم می کند، آنها را به مکان های مناسب هدایت می کند، پاسخی را تولید می کند و همه چیز را پیگیری می کند.نقش دروازه API در مدیریت APIدروازه API بخشی از سیستم مدیریت API است. دروازه API تمام درخواست های دریافتی را رهگیری می کند و آنها را از طریق سیستم مدیریت API ارسال می کند که انواع توابع ضروری را مدیریت می کند.دقیقاً کاری که دروازه API انجام می دهد از یک پیاده سازی به اجرای دیگر متفاوت است. برخی از عملکردهای رایج عبارتند از احراز هویت، مسیریابی، محدود کردن نرخ، صورتحساب، نظارت، تجزیه و تحلیل، خط‌مشی‌ها، هشدارها و امنیت.چگونه یک دروازه API از DevOps و محیط های بدون سرور پشتیبانی می کند؟در سازمان‌هایی که از رویکرد DevOps پیروی می‌کنند، توسعه‌دهندگان از میکروسرویس‌ها برای ساخت و استقرار برنامه‌ها به روشی سریع و تکراری استفاده می‌کنند. API ها یکی از رایج ترین راه های ارتباط میکروسرویس ها هستند.علاوه بر این، توسعه ابر مدرن، از جمله مدل بدون سرور، به APIها برای تامین زیرساخت بستگی دارد. شما می توانید توابع بدون سرور را مستقر کرده و با استفاده از یک دروازه API مدیریت کنید.به طور کلی، همانطور که یکپارچگی و اتصال به یکدیگر مهم تر می شوند، API ها نیز اهمیت بیشتری پیدا می کنند. و با افزایش پیچیدگی API و افزایش استفاده، ارزش دروازه API نیز افزایش می یابد.API Gatewayانواع APIAPI های RESTful:APIهای RESTful را با استفاده از APIهای HTTP برای بارهای کاری بدون سرور و پشتیبان‌های HTTP بسازید. API های HTTP بهترین انتخاب برای ساخت API هایی هستند که فقط به عملکرد پراکسی API نیاز دارند. اگر API های شما به عملکرد پراکسی API و ویژگی های مدیریت API در یک راه حل نیاز دارند، API Gateway API های REST را نیز ارائه می دهد.API های WEBSOCKET:با استفاده از WebSocket APIها، برنامه‌های ارتباطی دوطرفه بلادرنگ، مانند برنامه‌های چت و داشبوردهای جریانی بسازید. API Gateway یک اتصال دائمی برای مدیریت انتقال پیام بین سرویس باطن و مشتریان شما برقرار می کند.فوایدتوسعه API کارآمدچندین نسخه از یک API را به طور همزمان با API Gateway اجرا کنید، که به شما امکان می دهد نسخه های جدید را به سرعت تکرار کنید، آزمایش کنید و منتشر کنید. شما برای تماس های برقرار شده با API های خود و انتقال داده به خارج پرداخت می کنید و هیچ حداقل کارمزد یا تعهدات اولیه وجود ندارد.عملکرد در هر مقیاسیبا استفاده از شبکه جهانی مکان‌های لبه ما با استفاده از Amazon CloudFront، کمترین تأخیر ممکن را برای درخواست‌ها و پاسخ‌های API به کاربران نهایی ارائه دهید. ترافیک را کنترل کنید و تماس‌های API را مجاز کنید تا اطمینان حاصل شود که عملیات پشتیبان در برابر افزایش ترافیک مقاومت می‌کنند و سیستم‌های بک‌اند به طور غیر ضروری فراخوانی نمی‌شوند.صرفه جویی در هزینه در مقیاسAPI Gateway یک مدل قیمت گذاری طبقه بندی شده برای درخواست های API ارائه می دهد. با قیمت درخواست های API کمتر از 0.90 دلار برای هر میلیون درخواست در بالاترین سطح، می توانید هزینه های خود را با افزایش استفاده از API در هر منطقه در سراسر حساب های AWS خود کاهش دهید.نظارت آسانمعیارهای عملکرد و اطلاعات مربوط به تماس‌های API، تأخیر داده‌ها و نرخ خطا را از داشبورد API Gateway نظارت کنید، که به شما امکان می‌دهد با استفاده از Amazon CloudWatch تماس‌های سرویس‌های خود را به صورت بصری نظارت کنید.کنترل های امنیتی انعطاف پذیربا AWS Identity and Access Management (IAM) و Amazon Cognito اجازه دسترسی به API های خود را بدهید. اگر از نشانه های OAuth استفاده می کنید، API Gateway پشتیبانی OIDC و OAuth2 را ارائه می دهد. برای پشتیبانی از الزامات مجوز سفارشی، می توانید یک مجوز دهنده Lambda را از AWS Lambda اجرا کنید.گزینه های RESTful APIAPI های RESTful را با استفاده از API های HTTP یا REST API ایجاد کنید. APIهای HTTP بهترین راه برای ساختن API برای اکثر موارد استفاده هستند—آنها تا 71% ارزانتر از APIهای REST هستند. اگر مورد استفاده شما به عملکرد پراکسی API و ویژگی های مدیریتی در یک راه حل نیاز دارد، می توانید از REST API استفاده کنید.ساخت میکروسرویس ها با استفاده از دروازه APIبرای اکثر برنامه های کاربردی مبتنی بر میکروسرویس، پیاده سازی یک دروازه API منطقی است، زیرا به عنوان یک نقطه ورودی واحد به سیستم عمل می کند. دروازه API مسئول مسیریابی درخواست، ترکیب و ترجمه پروتکل است و می تواند سیستم را ساده کند. با یک دروازه API، هر یک از مشتریان برنامه یک API سفارشی دریافت می کند. دروازه API برخی از درخواست‌ها را به سادگی با مسیریابی آنها به سرویس باطن مناسب مدیریت می‌کند و با فراخوانی چندین سرویس پشتیبان و جمع‌آوری نتایج، برخی دیگر را مدیریت می‌کند. اگر در سرویس‌های باطن خرابی وجود داشته باشد، دروازه API می‌تواند با برگرداندن داده‌های ذخیره‌شده یا پیش‌فرض آن‌ها را پنهان کند.نقش دروازه های API در معماری میکروسرویس هادروازه API هادی است که درخواست های پردازش شده توسط معماری میکروسرویس ها را سازماندهی می کند تا تجربه ای ساده برای کاربر ایجاد کند. این یک مترجم است که بسیاری از درخواست‌های مشتری را می‌پذیرد و آنها را تنها به یکی تبدیل می‌کند تا تعداد رفت‌وآمدهای بین مشتری و برنامه را کاهش دهد. یک دروازه API در مقابل میکروسرویس ها راه اندازی می شود و به نقطه ورود هر درخواست جدیدی که توسط برنامه اجرا می شود تبدیل می شود. هم پیاده سازی مشتری و هم اپلیکیشن میکروسرویس را ساده می کند.2- ابزارهای مربوطه1. دروازه کنگ (OSS)Kong Gateway (OSS) یک دروازه API بومی ابری محبوب، منبع باز و پیشرفته است که برای استقرار جهانی ساخته شده است: می تواند بر روی هر پلتفرمی اجرا شود. این به زبان برنامه نویسی Lua نوشته شده است و از زیرساخت های ترکیبی و چند ابری پشتیبانی می کند و برای میکروسرویس ها و معماری های توزیع شده بهینه شده است.در هسته خود، Kong برای عملکرد بالا، توسعه پذیری و قابلیت حمل ساخته شده است. کونگ همچنین سبک، سریع و مقیاس پذیر است. از پیکربندی اعلامی بدون پایگاه داده، تنها با استفاده از ذخیره سازی در حافظه و CRD های بومی Kubernative پشتیبانی می کند.کنگ دارای توازن بار (با الگوریتم‌های مختلف)، گزارش‌گیری، احراز هویت (پشتیبانی از OAuth2.0)، محدود کردن نرخ، تغییر شکل‌ها، نظارت زنده، کشف سرویس، ذخیره‌سازی، تشخیص و بازیابی خرابی، خوشه‌بندی و موارد دیگر است. نکته مهم این است که Kong از خوشه بندی گره ها و توابع بدون سرور پشتیبانی می کند.از پیکربندی پراکسی ها برای سرویس های شما پشتیبانی می کند و آنها را از طریق SSL ارائه می دهد یا از WebSockets استفاده می کند. می‌تواند ترافیک تعادلی را از طریق کپی خدمات بالادستی شما بارگیری کند، در دسترس بودن خدمات شما را نظارت کند و تعادل بار آن را بر این اساس تنظیم کند.علاوه بر این، Kong با یک رابط خط فرمان ارائه می شود که به شما امکان می دهد یک خوشه Kong را از خط فرمان مدیریت کنید. همچنین، Kong با استفاده از پلاگین ها و انواع مختلف ادغام بسیار توسعه پذیر است. برای حداکثر انعطاف‌پذیری، می‌توان آن را با RESTful API مدیریت کرد.2. ابر TykTyk (تلفظ Taik) یک دروازه API منبع باز، قدرتمند، سبک و با امکانات کامل است که از ابتدا با استفاده از زبان برنامه نویسی Go نوشته شده است. این ابر بومی است، دارای عملکرد بسیار بالا با معماری به راحتی قابل توسعه و اتصال بر اساس استانداردهای باز است.می تواند به طور مستقل اجرا شود و فقط به Redis به عنوان یک ذخیره داده نیاز دارد. این امکان را به کاربران می دهد تا به طور ایمن انواع خدمات از جمله قدیمی، REST و GraphQL را منتشر و مدیریت کنند (از GraphQL خارج از جعبه پشتیبانی می کند).Tyk با ویژگی‌های بسیاری ساخته شده است که شامل انواع روش‌های احراز هویت، سهمیه‌بندی، و محدود کردن نرخ، کنترل نسخه، اعلان‌ها و رویدادها، نظارت و تجزیه و تحلیل است. همچنین از کشف سرویس، تبدیل‌های در حال پرواز و نقاط پایانی مجازی پشتیبانی می‌کند و امکان ایجاد APIهای ساختگی قبل از انتشار را فراهم می‌کند.علاوه بر موارد فوق، Tyk از اسناد API پشتیبانی می کند و یک پورتال توسعه دهنده API، یک سیستم شبیه به CMS (سیستم مدیریت محتوا) ارائه می دهد که در آن می توانید API های مدیریت شده خود را منتشر کنید و توسعه دهندگان شخص ثالث ثبت نام کنند، در API های خود ثبت نام کنند، و بتوانند آن ها را مدیریت کنند. نکته مهم این است که تنها یک نسخه از Tyk API Gateway وجود دارد که 100٪ منبع باز است. چه کاربر نسخه Community یا یک کاربر سازمانی باشید، همان دروازه API را دریافت می کنید. این دستگاه با تمام قطعات ممکن مورد نیاز برای استفاده کامل، بدون قفل ویژگی و بدون جعبه سیاه ارسال می شود. با Tyk، دقیقاً با نحوه پردازش داده های خود آشنا می شوید.3. KrakenDهمچنین در Go نوشته شده و با در نظر گرفتن عملکرد ساخته شده است، KrakenD یک دروازه API منبع باز، ساده و قابل اتصال با کارایی بالا است که با معماری بدون حالت طراحی شده است. می تواند در همه جا اجرا شود و برای اجرا به پایگاه داده نیاز ندارد. پیکربندی ساده ای دارد و از پایانه ها و باطن های نامحدود پشتیبانی می کند.KrakenD دارای مانیتورینگ، کش کردن، سهمیه کاربر، محدود کردن نرخ، کیفیت خدمات (تماس‌های همزمان، قطع کننده مدار، و مهلت زمانی دانه‌بندی شده)، تبدیل، تجمیع، (منابع ادغام)، فیلتر کردن (در لیست سفید و لیست سیاه) و رمزگشایی است. این ویژگی های پروکسی مانند تعادل بار، ترجمه پروتکل و Oauth را ارائه می دهد. و ویژگی های امنیتی مانند SSL و سیاست های امنیتی.شما می توانید رفتار دروازه API را با دست یا با استفاده از KrakenDesigner پیکربندی کنید، یک رابط کاربری گرافیکی که به شما امکان می دهد API خود را به صورت بصری از ابتدا طراحی کنید یا یک API موجود را از سر بگیرید. علاوه بر این، معماری توسعه پذیر KrakenD امکان افزودن قابلیت های اضافی، پلاگین ها، اسکریپت های تعبیه شده و میان افزارها را بدون تغییر کد منبع آن فراهم می کند.3- شرکت‌های فعال در این حوزه1- شرکت ابر درساابر درسا در سال ۱۳۹۸ توسط تعدادی از صاحب نظران در حوزه رایانش ابری بنیانگذاری شده و در سال ۱۴۰۰ با نام سیستم خبره درسا در اداره کل ثبت شرکت ها و موسسات غیرتجاری ثبت و با نام تجاری ابر درسا شروع به فعالیت نموده است. ماموریت ابر درسا تبدیل شدن به پلت فرم اول رایانش ابری در منطقه خاورمیانه است.سرویس API Gateway ابریسرویس ApiGateway ابری یک سرویس میزبانی API است. این مجموعه وسیعی از توابع مدیریت چرخه زندگی را برای کمک به ایجاد معماری سیستم API محور ارائه می دهد. توابع مدیریت چرخه زندگی شامل طراحی API، توسعه، آزمایش، انتشار، فروش، O&amp;M  و نظارت، کنترل امنیت و عدم انتشار است. سرویس Api Gateway ابری با استفاده از قابلیت های سازگاری و یکپارچگی قدرتمند خود، API های سیستم های تجاری مختلف را مدیریت می کند و API ها را به صورت متمرکز فراخوانی می کند.قابلیت‌هااز محیط‌های ناهمگن شبکه پشتیبانی میکند: سرویس Api Gateway ابری می تواند API های سیستم های تجاری شما را مدیریت کند، صرف نظر از اینکه سیستم های تجاری شما در ابر درسا ، مراکز داده محلی یا ابرهای شخص ثالث مستقر شده اند یا خیر.ساخت انواع معماری فنیمعماری بدون سرور ترکیبی از Function Compute و API Gateway به توسعه دهندگان امکان می دهد تا کد را کشف کرده و به سرعت خدمات کم هزینه، بسیار در دسترس و مقیاس پذیر درزمان واقعی را ایجاد کنند. این معماری توسعه مشاغل مرتبط با دستگاه های تلفن همراه، برنامه های وب، اینترنت اشیا (IoT) بازار ابر را تسهیل می کند. این معماری امکانات توسعه تجارت ومرزهای تجاری را گسترش می دهد. انعطاف پذیری ترکیبات محصول بهبود یافته است.معماری میکروسرویسسرویس Api Gateway ابری به عنوان یک سرویس ابری بالغ عمل می کند که اجازه دسترسی به خوشه هایبرنامه Kubernetes را می دهد. این به طور قابل توجهی قابلیت های سرویسخوشه های برنامه Kubernetes را بهبود می بخشد. این معماری به عنوان معماری استاندارد برای برنامه های کاربردی اینترنت در مقیاس بزرگ عمل می کند.2- شرکت وصلپلتفرم مدیریت API سورنا توسعه‌دهندگان را قادر می‌سازد تا برنامه‌هایی مرتبط با سامانه‌های داخلی سازمان/سرویس‌دهنده طراحی و پیاده‌سازی نمایند. همچنین APIها در تکنولوژی‌های مختلف نظیر اینترنت اشیا، رایانش ابری و داده‌های حجیم نقشی کلیدی را ایفا می‌نماید. پلتفرم مدیریت API سورنا پایداری، امنیت و پشتیبانی ویژهای ارائه می‌کند تا شرکت‌های طرف ثالث، همکاران، شرکا و حتی توسعه‌دهندگان آزاد بتوانند با آسودگی خیال و اطمینان از آنها استفاده نمایند.4- جمع‌بندیمنابع1- https://www.redhat.com/en/topics/api/what-does-an-api-gateway-do2- https://aws.amazon.com/api-gateway/3- https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html4- https://www.nginx.com/learn/api-gateway/5- https://dorsacloud.com/service-post/api-gateway-service/6- http://vasl.ir/«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»</description>
                <category>faezeh montazerin</category>
                <author>faezeh montazerin</author>
                <pubDate>Fri, 24 Dec 2021 10:05:58 +0330</pubDate>
            </item>
                    <item>
                <title>آشنايي با Business Rule Management System</title>
                <link>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</link>
                <description>1- توضيح و كاربردBusiness Rules Managment:شکل 1قوانین تجاری اساساً بلوک های ساختاری سازمانی خط مشی شرکت هستند که برای دستیابی به اهداف استراتژیک استفاده می شوند. قوانین کسب و کار پارامترهایی را برای نحوه اجرای وظایف و نحوه اجرای عملکردهای سازمانی تعیین می کند. هنگامی که قوانین کسب و کار را ایجاد، مدیریت و خودکار می کنید، در واقع درگیر مدیریت قوانین تجاری با هدف استفاده از منابع کمتر برای دستیابی به اهداف مشابه هستید.سیستم مدیریت قوانین کسب و کار (BRMS) پلتفرمی است که برای خودکارسازی منطق تصمیم‌گیری به عنوان یک قانون تجاری در بین برنامه‌ها طراحی شده است. به جای ادغام کد منبع بر اساس یک برنامه کاربردی، یک پلت فرم BRMS قوانین تجاری مدیریت را از کد برنامه بیرونی می کند. در نتیجه، چندین برنامه می توانند همزمان از قوانین تجاری تعیین شده استفاده کنند.دلیل استفاده از BRMSشرکت ها می توانند از یک پلت فرم BRMS برای حفظ قوانین تجاری خود و تعیین اقدامات از یک مخزن مرکزی استفاده کنند. منطق تصمیم گیری خارج از کد برنامه نویسی است و BRMS را به یک کاتالیزور برای منطق دقیق، کارایی فرآیند، بهبود بهره وری و چابکی تبدیل می کند. می‌توانید در هر زمان و در صورت نیاز، تغییرات سریع‌تری در قوانین کسب‌وکار انجام دهید. روش های مختلفی برای ذخیره و تعریف قوانین تجاری وجود دارد، از جمله موارد زیر:دوستانه و غیر رسمی نوشته شده است، رسمی، خودکارهر کسب‌وکاری که قوانین تجاری خود را جدی می‌گیرد، پلتفرم BRMS مناسب می‌تواند از رسمی و خودکار بودن آنها اطمینان حاصل کند. ارسال قوانین روی کاغذ یا از طریق ایمیل دیگر کارآمد نیست و ایمن نیست.دلیل نیاز به BRMSهر صنعت، هر عمودی، توسط مجموعه ای از قوانین اداره می شود. بنابراین، پیاده سازی یک سیستم BRMS در اکثر سازمان ها، از جمله: هر کسب و کار، سازمان یا نهاد دولتی که توسط قوانین اداره می شود.هر نهادی که توسط قوانین اداره می شود.مشاغل با سیاست های داخلی برای کارمندان، مشتریان و شرکا.سازمان هایی که می خواهند دقت و کارایی را در تصمیم گیری بهبود بخشند.مدیرانی که می خواهند با سرعت بیشتری تصمیمات آگاهانه بگیرند.شرکت هایی که می خواهند انطباق را بهبود بخشند.اکنون، بیایید 5 مزیت سیستم های مدیریت قوانین کسب و کار را بررسی کنیم.بهبود کارایی فرآیندبرای رونق هر کسب و کاری مستلزم رعایت مهلت ها، معیارها و سهمیه ها است. با این حال، در پیش گرفتن کارآمدترین مسیر بدون مجموعه ای مناسب از قوانین تجاری چالش برانگیز می شود. با این وجود، فرض کنید کسب و کار شما کارایی فرآیند را بهبود نمی بخشد. در این صورت، ممکن است به زودی از یک عرصه رقابتی محو شود و به دلیل عدم ارائه محصولات و خدمات مورد تقاضا در یک بازه زمانی معقول، از بازار خارج شود. بنابراین، بسیار مهم است که فرآیندهای کاری موجود خود را ارزیابی کنید و میزان موفقیت فعلی آنها را با معیارهای کلیدی مانند کیفیت، زمان انجام کار، اتلاف، افزونگی کار و موارد دیگر اندازه گیری کنید.یک پلت فرم BRMS به شرکت شما اجازه می دهد تا قوانین کسب و کار را از یک منبع حقیقت مدیریت، به روز رسانی و حفظ کند تا تعیین کند که در کجا باید تغییرات ایجاد شود. این کمک می کند که با ترسیم فرآیندهای موجود خود با استفاده از نمودار جریان، نمودار شناور یا با نوشتن آنها شروع کنید.در مرحله بعد، تنگناها را مشخص کنید و همچنین به دنبال مواردی باشید که در حال حاضر به خوبی کار می کند. فرآیندهایی را که می توانند از بهینه سازی بهره مند شوند علامت گذاری کنید. همانطور که فرآیندهای ایده‌آل خود را تجسم می‌کنید، بهتر می‌توانید حفره‌هایی را ببینید که باید برطرف شوند. اکنون، فرآیند کامل خود را کامل کنید که دقیقاً چگونه ترجیح می دهید جریان داشته باشد و چه وظایفی برای تکمیل موفقیت آمیز حیاتی هستند.شاید بتوان ارتباطات را بهبود بخشید - هنگام جستجوی راه حل خلاقانه فکر کنید. به یاد داشته باشید، بهبود فرآیندهای کسب و کار شما هم زمان و هم کمی آزمایش می خواهد. شما یک ایده آل مطرح می کنید، نظریه خود را اجرا می کنید و آن را آزمایش می کنید. اگر متوجه شدید که روند ایده آل شما آنطور که می خواهید کار نمی کند، از نو شروع کنید. هنگامی که به یک نتیجه موفقیت آمیز رسیدید، قوانین کسب و کار خود را با استفاده از BRMS اعمال کنید.ویژگی های امنیتی پیشرفتهیک پلت فرم BRMS می‌تواند مجموعه‌ای از ویژگی‌ها را ارائه دهد که در آن کاربران نهایی غیرفنی می‌توانند قوانین تجاری را ایجاد، حفظ و اجرا کنند. قوانین کسب و کار را می توان برای مدیریت گردش کار و همچنین اتخاذ تصمیمات تجاری مناسب مورد استفاده قرار داد. به عنوان موتور قواعد، یک پلت فرم BRMS از روش استنتاج زنجیره‌ای رو به جلو استفاده می‌کند که توسط الگوریتم Rete پشتیبانی می‌شود.بنابراین، زنجیره جلویی تضمین می کند که موتور در هر فرآیند کاری تا رسیدن به هدف تکرار می شود. این منافذ از طریق هر واقعیت تا زمانی که عبارت IF به عنوان درست تعیین شود. وقتی این قانون پیدا شد، موتور قوانین نتیجه را اجرا می کند و اطلاعات جدیدی را به مجموعه داده اضافه می کند. ویژگی‌های امنیتی برای تضمین عدم تغییر قوانین تجاری توسط بدافزارها یا مجرمان سایبری ساخته شده‌اند. فقط کاربران مجاز می توانند قوانین کسب و کار را تغییر دهند.منطق تصمیم گیری را با دقت بیان کنیدهنگام خودکارسازی و مدیریت تصمیمات تجاری از طریق BRMS، مزایای زیادی نسبت به مسیرهای سنتی به شرح زیر دریافت می کنید:کاربران غیرفنی تجاری می توانند به بهبود همکاری های تجاری و فناوری اطلاعات کمک کنند و بار کاری را برای همه ذینفعان کاهش دهند.هر یک از قوانین تجاری را می توان به طور مستقل مدیریت کرد زیرا آنها اظهاری هستند. نتیجه، مدیریت ساده‌تر منطق تصمیم‌گیری است و در عین حال ارزیابی دقیق‌تری از کیفیت و سازگاری را القا می‌کند.قوانین تجاری می توانند یک عنصر شرطی را به کار گیرند که مشخص می کند آیا بند IF برای یک فرآیند درست است یا خیر. منطق تصمیم گیری دقیقی را منتقل می کند که از تصمیم گیری و تجزیه و تحلیل بهبود یافته پشتیبانی می کند.کاهش اتکا به فناوری اطلاعات برای تغییراتبا استفاده از پلتفرم BRMS، کاربران تجاری غیرفنی تایید شده می‌توانند در صورت لزوم به‌روزرسانی‌ها یا تغییراتی را ایجاد کنند که به فناوری اطلاعات زمان آزاد بیشتری برای تمرکز بر پروژه‌ها و توسعه با ارزش بالاتر بدهند. در عین حال، فناوری اطلاعات می تواند از یک پلت فرم BRMS برای القای تغییرات سریع استفاده کند که مکان یابی و آزمایش منطق تصمیم گیری را در صورت نیاز آسان تر می کند. هنگامی که چندین بخش می توانند یک پلت فرم BRMS را به اشتراک بگذارند و به روز کنند، همه برنده می شوند زیرا می توانند زمان و منابع بیشتری را برای تخصیص به طرح های دیگر پس بگیرند.قوانین تصمیم گیری مقیاس در سراسر برنامه های تجاریهنگامی که یک BRMS به خوبی طراحی شده باشد، می تواند قوانین تصمیم گیری را در بسیاری از برنامه های کاربردی که در آن فرآیندهای کاری و گردش کار مدیریت می شوند، مقیاس کند. BRMS می تواند به عنوان یک منبع منفرد از حقیقت پیاده سازی شود که در آن کاربران نهایی می توانند به راحتی قوانین تصمیم گیری را به چندین برنامه به طور همزمان مقیاس کنند.استانداردهااستاندارد OMG Decision Model و Notation برای استانداردسازی عناصر توسعه قوانین کسب و کار، به ویژه نمایش جدول تصمیم، طراحی شده است. همچنین استانداردی برای Java Runtime API برای موتورهای قانون JSR-94 وجود دارد.مدل انگیزه کسب و کار OMG (BMM): مدلی از چگونگی تناسب استراتژی ها، فرآیندها، قوانین و غیره برای مدل سازی کسب و کارOMG SBVR: محدودیت های کسب و کار را در مقابل خودکارسازی رفتار تجاری هدف قرار می دهدOMG Production Rule Representation (PRR): نشان دهنده قواعدی برای سیستم های قوانین تولید است که اکثر اهداف اجرای BRMS را تشکیل می دهند.OMG Decision Model and Notation (DMN): مدل هایی از تصمیمات را نشان می دهد که معمولاً توسط یک BRMS مدیریت می شوند.RuleML خانواده ای از زبان های نشانه گذاری قوانین را ارائه می دهد که می توانند در یک BRMS استفاده شوند و با W3C RIF خانواده ای از زبان های قوانین مرتبط را برای تبادل قوانین در پشته وب معنایی W3C فراهم می کند.بسیاری از استانداردها، مانند زبان‌های دامنه خاص، بازنمایی خود را از قوانین تعریف می‌کنند و نیاز به ترجمه به موتورهای قوانین عمومی یا موتورهای سفارشی خود دارند.دامنه های دیگر مانند PMML نیز قوانین را تعریف می کنند.اجزای کلیدی سیستم مدیریت قوانین کسب و کارانواع مختلفی از سیستم های مدیریت قوانین کسب و کار وجود دارد که طیف گسترده ای از ویژگی ها و عملکردها را ارائه می دهند. با این حال، هر BRMS شامل اجزای کلیدی زیر است:مخزنمخزن یک زیرساخت پایگاه داده است که داده ها را جمع آوری، مدیریت و ذخیره می کند. در یک BRMS قوانین کسب و کار به جای تعبیه قوانین به عنوان کد در برنامه، در یک مخزن ذخیره می شوند. به این ترتیب قوانین توسط بیش از یک برنامه قابل دسترسی هستند و برای استفاده مجدد در دسترس هستند.محیط توسعهیک BRMS ابزارهای توسعه را برای کاربران فنی و تجاری برای تعریف و مدیریت قوانین تجاری فراهم می کند. کاربران می توانند قوانین کسب و کار را بدون نوشتن کد توسعه دهند و قوانین تجاری را از جمله ویژگی های دیگر تأیید کنند.محیط زمان اجرامحیط اجرا یک زیرساخت سخت‌افزاری و نرم‌افزاری است که عملکرد یک پایگاه کد را در زمان واقعی امکان‌پذیر می‌سازد. در یک BRMS، این به برنامه‌ها اجازه می‌دهد تا قوانین تجاری قابل اجرا را فراخوانی کنند و آنها را با استفاده از موتور قوانین تجاری اجرا کنند.مزایای BRMSیک سیستم مدیریت قوانین کسب و کار طیف وسیعی از مزایای را به سازمان ها ارائه می دهد. برخی از مزایای کلیدی عبارتند از:- افزایش کارایی از طریق تصمیم گیری خودکار، کاهش نیاز به پردازش دستی تصمیمات تکراری- توانایی مقیاس کردن قوانین تصمیم گیری در چندین برنامه- از رعایت سیاست ها و مقررات قابل اجرا اطمینان حاصل کنید. با یک BRMS، خط مشی ها و مقررات در قوانین تجاری گنجانده می شوند که از انطباق خودکار و ایجاد یک مسیر حسابرسی اطمینان حاصل می کنند.- خدمات مشتری بهبود یافته و تجربیات مشتری برتر. BRMS می تواند عوامل خدمات مشتری را از طریق بهترین شیوه ها راهنمایی کند و سازمان ها می توانند عملکرد سلف سرویس را افزایش دهند.- ویژگی های امنیتی پیشرفته قوانین کسب و کار را از تغییر، از دست دادن یا دسترسی افراد غیرمجاز محافظت می کند.- تجزیه و تحلیل و بهبود منطق تصمیم گیری. یک BRMS به سازمان‌ها کمک می‌کند تا مناطقی را که منطق تصمیم‌گیری در آنها بهبود می‌یابد شناسایی کنند. علاوه بر این، منطق تصمیم گیری را می توان با استفاده از نحو واژگان تجاری و نمایش قوانین گرافیکی با دقت بیان کرد.2- ابزارهاي مرتبط1- نرم‌افزار Camunda Cloudنرم‌افزار Camunda Cloud توسط Zeebe، کلاس جدیدی از موتور گردش کار BPMN که مقیاس‌پذیری افقی واقعی را ارائه می‌کند و موارد استفاده با کارایی بالا را که زمانی فراتر از قلمرو اتوماسیون گردش کار بودند، امکان‌پذیر می‌کند. کاموندا ابر از ابتدا برای ابر طراحی شده است. برای موارد استفاده از برنامه های ابری مانند برنامه های کاربردی مبتنی بر میکروسرویس ایده آل است و به طور یکپارچه با بهترین اجزای کلاس ابری ادغام می شود.2- پلتفرم Nintex Processنینتکس مدیریت، خودکارسازی و بهینه سازی فرآیندهای کسب و کار شما را سریع و آسان می کند. با ابزارهایی که صاحبان فرآیند و شرکت کنندگان دوست دارند از آن استفاده کنند، فرآیندهای کسب و کار خود را بصری برنامه ریزی، نقشه برداری و مدیریت کنید. فرآیندهایی را که برای اتوماسیون مناسب هستند یا نیاز به اتوماسیون دارند شناسایی کنید و با کلیک ها شروع کنید، نه با کد. با استفاده از داده های ایجاد شده از طریق فرآیندهای خودکار خود، فرآیندهای کسب و کار خود را بهینه کنید.3- پلتفرم Quickbaseپلتفرم Quickbase یک پلتفرم توسعه اپلیکیشن است که تیم های تجاری و فناوری اطلاعات را با این امکان را می دهد که حل کننده های مشکل با هر پیشینه فنی با یکدیگر همکاری کنند تا اکوسیستمی از برنامه ها را ایمن، ایمن و پایدار ایجاد کنند. Quickbase به کسب‌وکارها کمک می‌کند تا نوآوری مستمر فرآیندهای منحصربه‌فرد را با ایجاد امکان توسعه شهروندان در مقیاس در یک پلتفرم مشترک سرعت بخشند.3- شركت‌هاي فعال در اين زمينهدر حال حاضر در ايران شركت‌هاي قابل توجهي فعاليت ندارند و امكان پيشرفت دارد. جویا افزار ماندگار پرسیا، شرکتی است که می‌توان از فعالین در این حوزه نام برد.جام پرسيا پيشرو در توليد نرم افزارهاي يكپارچه سازماني (ERP) است؛ مبتني بر وب بوده و به شركتها در همه ابعاد و در صنايع مختلف كمك مي كند تا به بهترين وجه كسب و كار خود را اجرا نمايند. راهكار، تكنولوژي و فناوري هاي پيشرفته تحليلي جام كمك مي كنند مشاغل به كسب و كارهاي هوشمند تبديل شده و با سودآوري فعاليت كنند؛ به طور مرتب بروزرساني شده و با همه ابزارهاي سخت افزاري سازگار گردند. كاربرد جام در اين صنايع محدود به فرايندهاي عمومي نبوده و براي هر يك از صنايع ، داراي راهكارهاي ويژه اي مي باشد. جام در كنار محصولات اصلي، برخي محصولات جانبي از قبيل نرم افزارهاي تحليلي، BI، DW،… را نيز دارا مي باشد. جام قابل اجراء در كليه ي درگاه هاي موبايل (تلفن همراه، تبلت و … ) بوده و راهكارهاي مبتني بر رايانش ابري را نيز ارايه كرده است.4- جمع‌بنديبه‌اندازه کافی ساده به نظر می‌رسد که بهبود کارایی فرآیند باعث افزایش سودآوری، زمان چرخش، مشارکت مشتری و کاهش هزینه‌های عملیاتی می‌شود. با این حال، مزایای دیگری نیز وجود دارد که باید در نظر گرفت. برای نشان دادن، اگر بتوانید محصولات و خدمات را سریعتر ارائه دهید، می توانید تقاضای مشتری بیشتری را برآورده کرده و جذب کنید و در بازار مربوطه خود رقابتی تر شوید.  آیا زمان استفاده از مزایای BRMS فرا نرسیده است؟ درباره پلتفرم اتوماسیون فرآیند کم‌کد برنده جایزه Processmaker که دارای یکپارچگی بومی با OpenRules، سیستم مدیریت تصمیم‌گیری و قوانین تجاری است، بیشتر بیاموزید.منابع1- https://en.wikipedia.org/wiki/Business_rule_management_system2- https://www.processmaker.com/blog/what-is-a-business-rules-management-system-brms/3- https://roi4cio.com/en/categories/category/brms-business-rule-management-system/4- https://www.softwarereviews.com/products/quickbase?c_id=2945- https://www.techopedia.com/definition/30027/business-rule-management-system-brms6- http://www.jampersia.com/7- https://www.bptrends.com/business-rule-solutions-obligations-are-business-rules/«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»</description>
                <category>faezeh montazerin</category>
                <author>faezeh montazerin</author>
                <pubDate>Thu, 23 Dec 2021 22:45:31 +0330</pubDate>
            </item>
                    <item>
                <title>آشنايي با ESB</title>
                <link>https://virgool.io/@faezehmonta1995/%D8%A2%D8%B4%D9%86%D8%A7%D9%8A%D9%8A-%D8%A8%D8%A7-esb-bjzet1hu56rr</link>
                <description>1- معرفي و كاربردشكل 1: گذرگاه سرويس سازمانياساساً یک معماری است. این مجموعه ای از قوانین و اصول برای ادغام برنامه های کاربردی متعدد با هم بر روی یک زیرساخت گذرگاه مانند است. محصولات ESB کاربران را قادر می‌سازد تا این نوع معماری را بسازند، اما در نحوه انجام آن و قابلیت‌هایی که ارائه می‌دهند متفاوت هستند. مفهوم اصلی معماری ESB این است که شما برنامه های مختلف را با قرار دادن یک گذرگاه ارتباطی بین آنها یکپارچه می کنید و سپس هر برنامه را قادر می سازید تا با گذرگاه صحبت کند. این سیستم‌ها را از یکدیگر جدا می‌کند و به آن‌ها اجازه می‌دهد بدون وابستگی یا آگاهی از سیستم‌های دیگر در گذرگاه ارتباط برقرار کنند. مفهوم ESB به دلیل نیاز به دور شدن از ادغام نقطه به نقطه متولد شد که مدیریت آن در طول زمان شکننده و سخت می‌شود. ادغام نقطه به نقطه منجر به پخش کد یکپارچه‎‌سازی سفارشی در بین برنامه‌ها بدون هیچ راه مرکزی برای نظارت یا عیب‌یابی می شود. این اغلب به عنوان &quot;کد اسپاگتی&quot; نامیده می شود و مقیاس نمی شود زیرا وابستگی شدید بین برنامه ها ایجاد می کند.افزایش چابکی سازمانی با کاهش زمان برای بازاریابی برای ابتکارات جدید یکی از رایج ترین دلایلی است که شرکت ها ESB را به عنوان ستون فقرات زیرساخت فناوری اطلاعات خود پیاده سازی می کنند. یک معماری ESB با ارائه یک سیستم ساده و قابل اتصال، به خوبی تعریف شده، که مقیاس بسیار خوبی دارد، این امر را تسهیل می‌کند. علاوه بر این، یک ESB با استفاده از قابلیت‌های ارتباطی و تبدیلی خود، راهی برای استفاده از سیستم‌های موجود و قرار دادن آنها در معرض برنامه‌های جدید فراهم می‌کند.پیاده سازیمعماری ESB دارای اصول کلیدی است که امکان چابکی و مقیاس تجاری را فراهم می کند. تمرکز اصلی این است که سیستم‌ها را از یکدیگر جدا کنیم در حالی که به آنها اجازه می‌دهیم به روشی سازگار و قابل مدیریت ارتباط برقرار کنند.مفهوم &quot;گذرگاه&quot; برنامه ها را از یکدیگر جدا می کند. این معمولاً با استفاده از یک سرور پیام رسانی مانند JMS یا AMQP به دست می‌آید.داده‌هایی که در گذرگاه جابه‌جا می شوند فرمت متعارفی هستند و تقریبا همیشه XML هستند.یک &quot;آداپتور&quot; بین برنامه کاربردی و گذرگاه وجود دارد که داده ها را بین دو طرف تنظیم می کند.آداپتور مسئول مکالمه با برنامه کاربردی و تبدیل داده ها از فرمت برنامه به فرمت گذرگاه است. آداپتور همچنین می تواند مجموعه ای از فعالیت های دیگر مانند مدیریت تراکنش مسیریابی پیام، امنیت، نظارت، رسیدگی به خطا و غیره را انجام دهد.ESB ها عموماً بدون تابعیت هستند. وضعیت در پیام هایی که از گذرگاه عبور می‌کنند تعبیه شده است.قالب پیام متعارف قرارداد بین سیستم ها است. قالب متعارف به این معنی است که یک قالب پیام ثابت در گذرگاه وجود دارد و هر برنامه در گذرگاه می تواند با یکدیگر ارتباط برقرار کند.اصول اصلی ادغام1- ارکستراسیون: ترکیب چندین جزء ریزدانه موجود در یک سرویس ترکیبی مرتبه بالاتر. این را می توان برای دستیابی به &quot;دانه دانه بودن&quot; مناسب خدمات و ارتقای استفاده مجدد و مدیریت پذیری اجزای اساسی انجام داد.2- تبدیل: تبدیل داده بین فرمت های داده متعارف و فرمت های داده خاص مورد نیاز هر کانکتور ESB. یک مثال از این می تواند تبدیل بین فرمت های CSV، Cobol copybook یا EDI به SOAP/XML یا JSON باشد. فرمت‌های داده متعارف می‌توانند الزامات تبدیل مرتبط با پیاده‌سازی بزرگ ESB را که در آن مصرف‌کنندگان و ارائه‌دهندگان زیادی وجود دارد، که هرکدام قالب‌ها و تعاریف داده‌های خاص خود را دارند، بسیار ساده‌تر کنند.3- حمل و نقل: مذاکره پروتکل حمل و نقل بین چندین فرمت (مانند HTTP، JMS، JDBC). توجه: Mule با تبدیل کردن JDBC به انتقال (یا نقطه پایانی) دیگری که در آن می توان به داده ها دسترسی داشت، با پایگاه داده مانند «سرویس» دیگری رفتار می کند.4- میانجیگری: ارائه چندین رابط به منظور الف) پشتیبانی از چندین نسخه از یک سرویس برای سازگاری با عقب یا به طور متناوب ب) اجازه دادن به کانال های متعدد برای اجرای یک مؤلفه زیربنایی. این نیاز دوم ممکن است شامل ارائه چندین رابط برای یک مؤلفه، یک رابط قدیمی (فایل مسطح) و یک رابط سازگار با استانداردها (SOAP/XML) باشد.5- سازگاری غیرعملکردی: برای یک ابتکار معمولی ESB، این می تواند شامل سازگاری در مورد نحوه اعمال و اجرای سیاست های امنیتی و نظارت باشد. علاوه بر این، اهداف مقیاس‌پذیری و در دسترس بودن را می‌توان با استفاده از نمونه‌های متعدد یک ESB برای افزایش توان عملیاتی (مقیاس‌پذیری) و حذف تک‌نقطه‌های شکست (SPOFs)، که هدف کلیدی برای سیستم‌های بسیار در دسترس است، به دست آورد.6- پیام آگنوستیک: یکی از ویژگی های قدرتمند Mule این است که کانتینر پیام آگنوستیک است. این بدان معناست که پیام های XML را به کاربران خود تحمیل نمی کند. در حالی که XML رایج است، سناریوهای زیادی وجود دارد که می‌خواهید از JSON، فایل‌های مسطح، کتاب‌های کپی Cobol، پیوست‌های باینری و فایل، جریان‌ها و اشیاء جاوا استفاده کنید. نقشه‌بردار داده‌های گرافیکی ما به همان اندازه در مورد داده‌هایی که می‌توان نقشه‌برداری کرد سر و صدا ندارد. علاوه بر این، Mule streaming به توسعه دهندگان اجازه می دهد تا پیام های بزرگ را به طور موثر پردازش کنند.7- ابر آماده است: اگر ترجیح می دهید معماری برنامه، میزبانی و نظارت بر ادغام خود را به متخصصان ادغام بسپارید، CloudHub™ برای شما مناسب است. CloudHub یک پلتفرم یکپارچه به عنوان سرویس (iPaaS) است که شما را در عرض چند دقیقه راه اندازی می کند. CloudHub یک پلت فرم الاستیک و چند مستاجر با قابلیت اتصال به بیش از 150 SaaS، رسانه های اجتماعی و خدمات زیرساختی و امکان اتصال به برنامه های کاربردی داخلی شما ارائه می دهد. برنامه های CloudHub روی Mule مستقل اجرا می شوند و بالعکس. این بدان معناست که چه در حال استقرار در محل یا فضای ابری باشید، هیچ مفهوم جدیدی برای یادگیری وجود ندارد و تجربه توسعه‌دهنده یکسان است. نیازی به یادگیری روش جدیدی برای انجام کارها نیست.2- ابزار ESB1- پلتفرم Muleشكل 2: MuleSoftپلتفرم های ESB زیادی وجود دارد، از فروشندگان بزرگ اختصاصی گرفته تا فروشندگان داخلی و منبع باز. روی کاغذ، شباهت های زیادی وجود دارد. در اینجا نکاتی وجود دارد که باید هنگام انتخاب ESB در نظر بگیرید. سبک وزن: Mule سبک‌ترین پلتفرم یکپارچه‌سازی موجود است، با توزیع کاملاً بارگذاری شده با وزن 40 مگابایت. از نظر طراحی ماژولار است، بنابراین در صورت نیاز به کاهش ردپا، می توانید ماژول های ناخواسته را حذف کنید. ما &quot;سبک بودن&quot; را فقط در مورد اندازه نمی بینیم. همچنین هزینه ایجاد تغییرات در ادغام های موجود و مقدار سنگینی که برای ایجاد تغییرات باید انجام دهید، می باشد. زمان اجرای Mule: ماژولارسازی و استقرار سریع فوق العاده سریع و همچنین یک مدل پیکربندی را ارائه می دهد که سفارش مجدد و افزودن/تغییر عملکرد را آسان می کند. نه فقط میانجیگری اکثر فروشندگان ESB را صرفاً میانجی بین سیستم ها می دانند و محصولات جداگانه ای برای میزبانی منطق تجاری و خدمات انتشار دارند. ما این را پیچیدگی غیر ضروری می بینیم. Mule یک کانتینر خدمات سبک و مقیاس پذیر برای انتشار خدمات REST و SOAP ارائه می دهد. از آنجایی که Mule به شدت با Spring ادغام می شود، به این معنی است که توسعه دهندگان همچنین می توانند از قابلیت های Spring برای پیاده سازی منطق تجاری استفاده کنند. قابل دسترس: هر توسعه دهنده ای می تواند Mule را یاد بگیرد. Mule از ابزارهای رایجی استفاده می کند که همه توسعه دهندگان جاوا با آن آشنا هستند، مانند Maven، Eclipse، JUnit و Spring. Mule از یک مدل پیکربندی XML (شبیه به Spring) برای تعریف منطق استفاده می کند و کد سفارشی را می توان به زبان های مختلفی از جمله جاوا، Groovy، JavaScript، Ruby یا Python نوشت. همچنین، Anypoint Studio به توسعه دهندگان جدید کمک می کند تا با یک محیط توسعه گرافیکی به سرعت به سرعت بالا بروند. افزایش مقیاس، کاهش مقیاس: Mule برای مقیاس افقی در سخت افزار کالا طراحی شده است. زمان اجرا Mule به راحتی در یک برنامه جاسازی می شود. همچنین می تواند در سرور برنامه شما مانند Tomcat، JBoss یا WAS یا مستقیماً در برنامه شما تعبیه شود. مهمتر از آن، Mule پشتیبانی JUnit را فراهم می کند تا بتوان آن را در یک مورد آزمایشی JUnit جاسازی کرد. این قدرتمند است زیرا به این معنی است که می توانید تست های واحد تکرار شونده را برای ادغام هایی ایجاد کنید که روی یک لپ تاپ توسعه دهنده اجرا می شوند و می توانند در یک ساخت پیوسته گنجانده شوند.2- پلتفرم JBoss Fuseپلتفرم JBoss Fuse چیزی بیش از یک گذرگاه خدمات سازمانی (ESB) است. این یک پلتفرم ادغام متن باز سبک وزن است – بر اساس Apache ServiceMix – که در محل یا در فضای ابری در دسترس است. JBoss Fuse که بر اساس استانداردهای باز ساخته شده است، به جای تیم های کوچکی که معمولا کد منبع اختصاصی را حفظ می کنند، توسط جامعه بزرگی از توسعه دهندگان تقویت شده است.ویژگی ها و مزایا:Apache ActiveMQ: یک واسطه پیام منبع باز و سریع که از JMS و همچنین کلاینت های نوشته شده به زبان های دیگر مانند C و Python پشتیبانی می کند.Apache Camel: یک چارچوب متن باز که پیاده سازی های آزمایش شده و واقعی EIPS (الگوهای یکپارچه سازی سازمانی) را ارائه می دهد. این به توسعه‌دهندگان اجازه می‌دهد تا از راه‌حل‌های از پیش موجود برای چالش‌های کدنویسی مرتبط با یکپارچه‌سازی سازمانی که اغلب با آن‌ها مواجه می‌شوند، استفاده کنند.Apache CFX: یک چارچوب خدمات وب منبع باز، که برای ارتباط با استفاده از استانداردهای مختلف مانند JAX-WS و JAX-RS، HTTP و FTP و همچنین فرمت های مختلف مانند JSON، XML، CSV و غیره فراهم می کند.Apache Karaf: یک کانتینر زمان اجرا OSGI برای استقرار برنامه هاFabric8: یک ابزار ارکستراسیون برای استقرار میان افزارهای بزرگ3- پلتفرم Oracle ESBOracle ESB بر اساس یک محصول قبلی اوراکل به نام Retail Integration Bus Essentials است. برای کمک به برقراری ارتباط بین محصولات موجود اوراکل و برنامه های شخص ثالث در نظر گرفته شده است.ویژگی ها و مزایاOracle Message Broker: یک API سازگار با JMS که از AQ، IBM MQSeries، TIBCo Rendezvous و غیره پشتیبانی می کند.سرویس مسیریابی: سرویس‌های مسیریابی به سبک SOA که اجازه می‌دهد قوانین مسیریابی با WSDL تعریف و منتشر شوند.آداپتورهای یکپارچه: مجموعه ای از آداپتورهای JCA که برای دانلود در دسترس هستند. اینها امکان ارتباط با پایگاه های داده، صف های پیام، برنامه های کاربردی مختلف سازمانی و پروتکل های مختلف را فراهم می کند.سرور ESB: سرور زمان اجرا که به موضوعات برای به روز رسانی گوش می دهد.کنترل ESB: اجازه می دهد تا تغییرات پیکربندی در زمان واقعی انجام شود.3- معرفي شركت‌هاي فعال در حوزه‌ي ESB1- شرکت دانش‌بنیان داده‌پرداز پویای شریفشرکت دانش‌بنیان داده‌پرداز پویای شریف فعالیت خود را بیش از یک دهه باهدف تولید و توسعه سامانه‌های تحت وب و موبایل همچون پرتال‌های سازمانی، سامانه یکپارچه‌سازی برنامه‌های کاربردی سازمانی، پلتفرم جامع مدیریت پروژه‌ شبکه‌های رادیویی، توسعه قراردادهای هوشمند، طراحی اپلیکیشن‌های موبایل و ... آغاز نموده است. این شرکت از ابتدای تاسیس با به کارگیری استانداردهای تولید نرم‌افزار و به پشتوانه نیروهای متخصص توانسته پروژه‌های موفق بسیاری را انجام دهد. همکاری با سازمان‌های بزرگی همچون همراه اول، سازمان فناوری اطلاعات ایران، شرکت یونیلیور، کناف و ... طی سالیان متوالی با هدف رشد و توسعه تجارت ایشان از افتخارات داده پرداز می‌باشد. شرکت دانش‌بنیان داده‌پرداز پویای شریف ارائه‌دهنده راهکار‌های تخصصی تحت وب می‌باشد که تاکنون خدمات پیچیده‌ای را به سهولت در اختیار مشتریان خود قرار داده‌است.وجود تعداد بیشماری از پروژه‌های طراحی و برنامه‌نویسی وب در کارنامه ما نشان از توانمندی و تجربه در طراحی و برنامه‌نویسی سیستم‌های پیشرفته تحت وب با منطق‌های تجاری پیچیده و حجم زیادی از داده‌ها و معاملات است. این کوله بار علم و تجربه، ما را قادر ساخته تا کاربران وب را با راه‌حل‌های نرم‌افزاری قابل اعتماد و خلاقانه همراهی کنیم تا بتوانند پیچیده‌ترین و غیرقابل تصورترین ایده‌های کاری خود را به انجام برسانند.داده‌پرداز هم اکنون پس از فعالـیت به مدت یک دهه در زمینه &quot;فناوری اطلاعات&quot;، متشکل از یک تیم قدرتمند با متخصصین مجرب و حرفه‌ای است تا بتواند خدماتی فراگیر از طراحی وب‌سایت سفارشی تا توسعه سیستم‌های پیچیدۀ اینترنتی را بر پایه درک نیاز‌های تجاری و کــاری مشتریان و همچنین ارائه راه‌کارهای قابــل اعتماد، پیاده‌سازی نماید.منطقی است که اجرای فرآیندهای کاری در هر حوزه‌ای، امروزه وابسته به نرم‌‌افزارها و سیستم‌های اطلاعاتی متنوعی است که هر کدام با تکنولوژی خاصی تهیه شده‌اند. این برنامه‌ها درسازمان‌ها زمانی می‌‌توانند موثر باشند که با یکدیگر ارتباط مناسبی داشته باشند. بنابراین چالش‌های پیش روی سازمان‌ها شناخته شده‌اند! پلتفرم ESB داده پرداز یکی از بهترین راهکارها برای یکپارچه سازی انواع سرویس‌ها در سازمان‌های بزرگ و مدیریت نمودن جریان اطلاعات در آنهاست. پلتفرم ESB داده‌پرداز محصولی دانش‌بنیان است که تا به امروز در سامانه‌های بزرگی همچون سامانه فروش بلیط بن ریل، اپلیکیشن خدمت در محل همراه یار، پرتال دولت الکترونیک و ... به کاربرده شده و ویژگی اصلی آن، توانایی برقراری ارتباط با ماکروسرویس‌های بزرگ و برقراری جریان امنیت اطلاعات و مدیریت آنهاست.2- پلتكودر پلتکو با بهره‌مندی از کارشناسان ارشد حوزه معماری زیر ساخت سرویس سازمانی و تجربه انجام پروژه‌های متعدد می‌توان با ارائه یک مشاوره تخصصی و رایگان معضلات و مشکلات سازمان را شناسایی کرد و راهکارهای کارآمد که منجر به صرفه جویی مالی و زمانی می شود را معرفي كرد.عدم استفاده از ESB باعث می‌شود تا با زیاد شدن سرویس‌های سازمان و ارتباط دو به دو آنها با هم، یک ساختار پیچیده و در هم تنیده بوجود آید که علاوه بر خطرات احتمالی، مانع از توسعه آنها در آینده نیز خواهد شد. استفاده از گذرگاه خدمات سازمانی باعث می‌شود که با تغییر یک یا چند وب ‌سرویس در سازمان، نیازی به اطلاع دادن به سرویس گیرندگان سازمان برای تغییر در نحوه‌ی دریافت داده‌ها نباشد.بنا بر ارتباط خوب و مستمر هیئت مدیره شرکت پلتکو با دانشگاه صنعتی شریف و دانش مناسب در زمینه زیر ساخت نرم افزار سازمانی، در سال 1396 پروژه‌ای بنام پیاده سازی نرم افزار WSO2 برای یکی از سازمان‌های بزرگ دولتی به شرکت پلتکو ارائه گردید که طی زمان بندی مشخص شده به خوبی تحویل کارفرما گردید.پس از آن با مشاهده‌ی چالش‌های گوناگون سازمان‌ها در خصوص یکپارچه‌سازی، نظارت، تحلیل و مدیریت بر وب‌سرویس‌ها و افزایش تجربه تیم فنی ما در این زمینه ، در سال 1397 ، شرکت پلتکو با رویکرد ارائه‌ی راه‌حل اساسی برای این چالش‌ها وارد فاز  توسعه شد.پلتکو با بهره گیری از کارشناسان ارشد تیم فنی خود که از نخبگان دانشگاه صنعتی شریف می‌باشند با مطالعه بازار و نیاز‌ سنجی‌های انجام شده، با محوریت نرم افزار WSO2، پلتفرم جامع یکپارچه سازی و مدیریت وب سرویس را طراحی و پیاده سازی نمود و با اتصال و ادغام چند نرم افزار به یکدیگر یک پلتفرم کارآمد برای رفع نیاز یکپارچه سازی، نظارت، تحلیل و مدیریت وب سرویس ها پیاده سازی نمود.در این پلتفرم تکنولوژی‌های قدیم و جدید مدیریت چرخه زندگی وب سرویس ادغام شده و به صورت یک خروجی واحد و کاملا شخصی سازی شده در اختیار سازمان‌ها قرار داده می‌شود.3- آيكنگروه مهندسی آی کن با توجه به رسالت خود در ارائه محصولات زیرساختی برای سازمان ها و همچنین تجربه ای که طی دو دهه گذشته در مواردی مشابه بدست آورده است، اقدام به طراحی و ارائه راهکارهای جامع و مبتنی بر استانداردهای جهانی(ESB) در راستای ایجاد زیرساختی یکپارچه برای تعاملات نرم افزاری در سازمان ها نموده است.یکپارچه‌ساز آی‌کن (IIF) نقش گذرگاه ارتباطی بین نرم‌افزارها و سرویس‌های سازمانی و فراسازمانی را ایفا می‌کند که به طور کلی مسئولیت مدیریت پیام‌های بین نرم‌افزاری، مانیتورینگ، اعمال سطوح دسترسی، تغییر پروتکل ارتباطی (انتقال اطلاعات بین سیستم‌هایی که از تکنولوژی متفاوتی استفاده می کنند) و … را بر عهده دارد و با توجه به معماری استاندارد و زیرساخت سرویس‌گرای محصول، سازمان را در جهت نیل به معماری سرویس‌گرا و استاندارد یاری می‌رساند.از ارزش‌های سازمانی آی‌کن میتوان به اخلاق‌محوری و مشتری‌مداری اشاره نمود. اعتقاد به این ارزش‌ها در آی‌کن سبب شده است که مشتریان، در کنار تجربه استفاده از بهترین راهکارها در بخش‌های مختلف سازمانی، از پشتیبانی مناسب و کامل بهره‌مند گردند. برقراری ارتباط دوستانه با مشتریان، پاسخ‌دهی کامل به سوالات، سفارشی‌سازی کامل با توجه به نیازمندی‌های سازمان شما، محیا کردن بستری امن و یکپارچه از دیگر ویژگی‌های آی‌کن می‌باشد. آی کن (آینده کاوان کهکشان نرم فزار) با ساختاری پایدار و قوی‌تر از همیشه امروز با افتخار راهکار جامع خود را بر اساس نیاز هر یک از مشتریان به عنوان یک راهکار در جهت برنامه ریزی و بهینه سازی سازمان ارائه می‌دهد. 4- جمع‌بنديبیشتر سازمان‌ها می‌خواهند چابکی را با کاهش زمان برای بازاریابی برای ابتکارات جدید افزایش دهند. ESB ها این هدف را با اجرای یک سیستم ساده، به خوبی تعریف شده و &quot;قابل اتصال&quot; که مقیاس بسیار خوبی دارد، ترویج می کنند. در اینجا در MuleSoft می‌دانیم که معماری ESB دقیقاً همین است: یک معماری و نه صرفاً محصولی که می‌توانید آن را از قفسه خریداری کنید. این نه تنها زیرساخت بلکه طراحی برنامه را نیز در بر می گیرد.منابع:1- https://www.mulesoft.com/resources/esb/what-esb2-https://www.hcltech.com/blogs/everything-you-need-know-about-enterprise-service-bus-esb3-https://shadow-soft.com/enterprise-service-bus-esb-tools/4-https://searchapparchitecture.techtarget.com/definition/Enterprise-Service-Bus-ESB#:~:text=An%20enterprise%20service%20bus%20(ESB,structural%20and%20business%20policy%20rules«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»</description>
                <category>faezeh montazerin</category>
                <author>faezeh montazerin</author>
                <pubDate>Thu, 23 Dec 2021 19:10:08 +0330</pubDate>
            </item>
                    <item>
                <title>آشنايي با BPMS</title>
                <link>https://virgool.io/@faezehmonta1995/%D8%A2%D8%B4%D9%86%D8%A7%D9%8A%D9%8A-%D8%A8%D8%A7-bpms-sx6l6zgz4f9x</link>
                <description>1- موضوع و كاربردمدیریت فرآیند کسب و کار (BPM) رشته‌ای است که در آن افراد از روش‌های مختلفی برای کشف، مدل‌سازی، تجزیه و تحلیل، اندازه‌گیری، بهبود، بهینه‌سازی و خودکارسازی فرآیندهای تجاری استفاده می‌کنند. هر ترکیبی از روش‌های مورد استفاده برای مدیریت فرآیندهای تجاری یک شرکت، BPM است. فرآیندها می توانند ساختاریافته و قابل تکرار یا بدون ساختار و متغیر باشند. اگرچه لازم نیست، فناوری‌های فعال اغلب با BPM استفاده می‌شوند.می‌توان آن را از مدیریت برنامه متمایز کرد زیرا مدیریت برنامه به مدیریت گروهی از پروژه‌های وابسته به هم مربوط می‌شود. از دیدگاهی دیگر، مدیریت فرآیند شامل مدیریت برنامه است. در مدیریت پروژه، مدیریت فرآیند استفاده از یک فرآیند تکرارپذیر برای بهبود نتیجه پروژه است.تمایزات کلیدی بین مدیریت فرآیند و مدیریت پروژه تکرارپذیری و قابل پیش‌بینی بودن است. اگر ساختار و توالی کار منحصر به فرد باشد، پس یک پروژه است. در مدیریت فرآیند کسب و کار، دنباله‌ای از کار می‌تواند از نمونه‌ای به نمونه دیگر متفاوت باشد. مهم نیست که چند انشعاب در جاده وجود دارد، ما همه آن‌ها را از قبل می دانیم و شرایط را برای طی کردن یک مسیر یا مسیر دیگر درک می کنیم. اگر این شرط رعایت شود، با یک فرآیند روبرو هستیم.به عنوان یک رویکرد، BPM فرآیندها را به عنوان دارایی‌های مهم یک سازمان می‌بیند که باید برای اعلام و ارائه محصولات و خدمات ارزش افزوده به مشتریان، درک، مدیریت و توسعه یابد. این رویکرد بسیار شبیه سایر روش‌های مدیریت کیفیت جامع یا روش‌های فرآیند بهبود مستمر است.مدیریت فرآیند کسب‌وکار (BPM) رشته‌ای است که شامل هر ترکیبی از مدل‌سازی، اتوماسیون، اجرا، کنترل، اندازه‌گیری و بهینه‌سازی جریان‌های فعالیت تجاری، در حمایت از اهداف سازمانی، سیستم‌های فراگیر، کارکنان، مشتریان و شرکا در داخل و خارج از مرزهای سازمانی است.انجمن حرفه ای مدیریت فرآیند کسب و کار BPM را اینگونه تعریف می کند:مدیریت فرآیند کسب و کار (BPM) یک رویکرد منضبط برای شناسایی، طراحی، اجرا، مستندسازی، اندازه گیری، نظارت و کنترل فرآیندهای کسب و کار خودکار و غیر خودکار برای دستیابی به نتایج هدفمند و هماهنگ با اهداف استراتژیک سازمان است. BPM شامل تعریف، بهبود، نوآوری و مدیریت عمدی، مشارکتی و با کمک فناوری روز به روز فرآیندهای تجاری است که نتایج کسب و کار را هدایت می کند، ارزش ایجاد می‌کند و سازمان را قادر می‌سازد تا اهداف تجاری خود را با چابکی بیشتری برآورده کند. BPM یک شرکت را قادر می‌سازد تا فرآیندهای تجاری خود را با استراتژی تجاری خود هماهنگ کند، که منجر به عملکرد مؤثر کلی شرکت از طریق بهبود فعالیت‌های کاری خاص در یک بخش خاص، در سراسر شرکت یا بین سازمان‌ها می‌شود.گارتنر مدیریت فرآیند کسب‌و‌کار را اینگونه تعریف می‌کند:&quot;انضباط مدیریت فرآیندها (به جای وظایف) به عنوان ابزاری برای بهبود نتایج عملکرد کسب و کار و چابکی عملیاتی. فرآیندها مرزهای سازمانی را در بر می‌گیرند، افراد، جریان‌های اطلاعات، سیستم‌ها و سایر دارایی‌ها را به یکدیگر پیوند می‌دهند تا ارزش ایجاد کنند و به مشتریان و مؤلفه‌ها ارائه کنند.&quot;تفاوت BPM با BPMSاشتباه گرفتن BPM با مجموعه BPM (BPMS) معمول است. BPM یک رشته حرفه ای است که توسط افراد انجام می شود، در حالی که BPMS مجموعه ای فناورانه از ابزارهایی است که برای کمک به متخصصان BPM در دستیابی به اهدافشان طراحی شده است. BPM همچنین نباید با یک برنامه کاربردی یا راه حلی که برای پشتیبانی از یک فرآیند خاص ایجاد شده است اشتباه گرفته شود. مجموعه‌ها و راه‌حل‌ها راه‌هایی برای خودکارسازی فرآیندهای تجاری هستند، اما اتوماسیون تنها یکی از جنبه‌های BPM است.مزاياي سيستم مديريت فرايندهاي كسب‌وكارچابكي بيشتر كسب‌وكار: به سازمان‌ها اجازه می‌دهد فرایندهای کسب و کار، تغییرات اجرایی را موقتا متوقف کنند و سپس دوباره اجرا کنند.كاهش هزينه‌ها و افزايش درآمدها: ابزار مدیریت فرایندهای کسب و کار گلوگاه‌ها را از بین می‌برد که خود سبب کاهش هزینه‌ها در طول زمان می‌شود. تاثیر آن می‌تواند. همچنین می‌تواند منابعی جهت کاهش هدررفت اختصاص دهد که این، هزینه‌ها را نیز کم می‌کند و منجر به افزایش سود می‌شود.كارايي بالاتر: یکپارچه‌سازی فرایندهای کسب و کار، پتانسیلی برای بهبود کلی کارایی فرایندها فراهم می‌کند. مسئولین فرایندها با داشتن اطلاعات درست می‌توانند تاخیرها را از نزدیک نظارت کنند و در صورت نیاز، منابع اضافی اختصاص دهند.ديد بهتر: نرم افزار bpm ضمن اینکه نظارت در لحظه بر معیارهای عملکردی کلیدی را تضمین می‌کند، امکان اتوماسیون را نیز فراهم می‌کند. این، سبب افزایش شفافیت می‌شود که به مدیریت بهتر و توانایی اصلاح کارآمد ساختارها و فرایندها در عین پیگیری خروجی‌ها می‌انجامد.امنيت: BPMS جامع تطابق سازمان با استانداردها را تضمین می‌کند و با قوانین جدید به روز می‌شود. مدیریت فرایندهای کسب و کار همچنین می‌تواند ایمنی و امنیت که توسط رویه‌های سازمانی مناسب و تسهیل انطباق، اندازه‌گیری می‌شود را تامین کند.اتوماسیون: جنبه اصلی اتوماسیون فرآیند، بارگذاری بسیاری از کارهای معمولی مربوط به عملکردهای روزانه کارکنان به سیستمی است که با قوانین تجاری و محرک های خودکار با تعامل انسانی محدود به لطف موتور گردش کار برنامه ریزی شده است. ایجاد این اتوماسیون شامل جمع آوری وظایف یا اقدامات و مکانیزم های ورودی (مانند فرم ها یا ورودی های سیستم) برای تقلید از رفتار یک فرآیند تجاری است.تجزیه و تحلیل: ابزارهای BPMS سطوح مختلفی از گزارش را ارائه می دهند یا با ابزارهای گزارش ادغام می شوند تا تجزیه و تحلیلی در مورد عملکرد فرآیند ارائه دهند. گزارش ها به KPI ها (شاخص های کلیدی عملکرد) گره خورده اند و داده هایی را در مورد عملکرد اقدامات، فرآیندها، اعضای فرآیند و غیره ارائه می دهند. علاوه بر این، ممیزی می تواند بر روی اقدامات تاریخی انجام شود.KPIها و معیارهای فرآیند کسب و کار: مانند هر تلاش تجاری، اندازه گیری با BPM بسیار مهم است. مهم‌ترین چیزی که هنگام تصمیم‌گیری برای اندازه‌گیری باید از آن اجتناب کرد، استفاده از یک رویکرد بدون اسکریپت است که فهرست خواسته‌های KPIها را از مدیران بخش فهرست می‌کند، زیرا این رویکرد ممکن است منجر به فهرستی طولانی از KPIها برای مدیریت شود، KPIهایی که ارزش تجاری ناکافی ارائه می‌دهند، KPIها. که با اهداف تجاری سطح بالا همسو نیستند و KPIهایی که در واقع اهداف متقابل دارند.معیارهای فرآیند کسب و کار استفاده از معیارهای SMART برای اندازه گیری عملکرد فرآیند مفهوم رایج معیارهای SMART هنگام اندازه گیری عملکرد تلاش های بهبود فرآیند اعمال می شود.خاص: معیارها باید خاص و مرتبط با اهداف تجاری باشد.قابل اندازه گیری: معیارها باید معنی دار و قابل اندازه گیری باشند. عناصر داده های زیربنایی باید به طور دقیق و کامل جمع آوری شوند و محاسبه باید صحیح باشد.قابل دستیابی: مقادیر هدف برای متریک شما باید به طور واقع بینانه قابل دستیابی باشد. آیا افراد مناسب توانایی و اختیار دارند تا معیار را به سمت مقدار هدف هدایت کنند؟مرتبط: معیارها باید واقع بینانه، مرتبط و نتیجه گرا باشند. آیا اقدامات شناسایی شده ای وجود دارد که بتواند متریک را به سمت مقدار هدف خود سوق دهد؟زمان محدود: معیارها باید به موقع باشند، به خصوص اگر معیارهای شاخص شاخص باشند. آیا می توان گزارش ها را تولید کرد یا داشبوردها را به موقع به روز کرد تا مداخلات مناسب برای هدایت متریک به سمت هدفش امکان پذیر شود؟شكل 1: معيارهاي فرآيندهاي كسب‌وكار2- ابزارهاي مورد استفاده1-  پلتفرم BPMApp: پیشرو در این راه، BPMApp است، نرم افزاری که توسط 500apps طراحی شده است. این برنامه به مدیریت و بهینه سازی فرآیند گردش کار کمک می کند. این نرم‌افزاری است که برای بهینه‌سازی فرآیند و نگه داشتن نبض تمام وظایفی که در فرآیندهای تجاری انجام می‌شوند به آن نیاز دارید تا کسب و کار خود را به خوبی اجرا کنید.با BPMApp، می‌توانید گردش‌های کاری سفارشی‌شده را با استفاده از گره‌ها ایجاد و مدیریت کنید، فرم‌هایی برای جمع‌بندی داده‌ها ایجاد کنید، مخاطبین خود را مدیریت کنید و پاسخ‌های فرم خود را کنترل کنید. بیش از 30000 کاربر فعال به BPMApp اعتماد دارند و این نرم افزار به دلیل قرارگیری 6 مرکز داده استراتژیک در سراسر جهان در دسترس است. همچنین، این برنامه همیشه آنلاین است و پشتیبانی مشتری درجه یک است.BPMApp یک طرح رایگان ارائه نمی دهد، اما یک دوره آزمایشی رایگان در دسترس است.2- پلتفرم  Kissflow: نرم افزاری است که برای حداقل اختلال در کار طراحی شده است. این برای محل کار مدرن طراحی شده است. Kissflow راحتی، کارایی و مدیریت بهینه تمام کارهای شما را تضمین می کند. این نرم افزار مدیریت گردش کار، مدیریت پرونده، مدیریت پروژه و همکاری را پوشش می دهد. با Kissflow، می توانید محل کار عالی خود را طراحی کنید.بیش از 10000 مشتری با بازخوردهای عالی به Kissflow اعتماد دارند. این نرم افزار محصولاتی مانند محل کار دیجیتال، مدیریت گردش کار، مدیریت فرآیند، ابر تدارکات، مدیریت پروژه و کد پایین را ارائه می دهد.نرم افزار مدیریت فرآیند کسب و کار Kissflow سه طرح اساسی، پیشرفته و کامل را به کاربران ارائه می دهد. ویژگی منحصر به فرد در اینجا این است که هر طرح یک آزمایش رایگان ارائه می دهد. قبل از تصمیم گیری در مورد اینکه آیا واقعاً آن چیزی است که می خواهید، می توانید از بالاترین امتیازات نرم افزار بهره مند شوید.3- پلتفرم  Bizagi: یک ابزار مدیریت فرآیند کسب‌وکار کم کد پیشرو در صنعت است. این نرم‌افزار پلتفرمی را مدل‌سازی و خودکار می‌کند که افراد، برنامه‌ها، روبات‌ها و اطلاعات را روی یک پلتفرم واحد به هم متصل می‌کند. Bizagi با توانمندسازی افراد برای ایجاد تحول دیجیتال، همکاری واقعی بین تجارت و فناوری اطلاعات را ممکن می‌سازد. آن‌ها به سازمان‌ها در سراسر صنایع کمک می‌کنند تا کارآمدتر کار کنند تا از روابط بین کارکنان و مشتریان بهره ببرند.مشاغل برتر در سراسر جهان از Bizagi استفاده می کنند. آنها یک مدل قیمت گذاری مبتنی بر عملکرد ارائه می دهند، بنابراین شما فقط برای آنچه استفاده می کنید پرداخت می کنید. شما می توانید به طور ایمن برنامه های سازمانی با کارایی بالا را اجرا کنید، تجربیات متنی ایجاد کنید، از ابزارهای نظارت گرافیکی استفاده کنید و از یک پلت فرم اتوماسیون برای هر فرآیند و هر دستگاهی استفاده کنید.4- پلتفرم  Processmaker: یک ابزار BPM است که به خودکارسازی فرآیندهای تجاری فشرده، پیچیده و در سطح سازمانی با کمک iBPMS جدید کم‌کد خود کمک می‌کند. استفاده از Processmaker تحول دیجیتالی کسب و کار شما را در عرض چند روز سرعت می بخشد. با کمک Processmaker، فرآیندها را در چندین بخش و سیستم به طور خودکار انجام می دهید و وظایف دستی، تنگناها و سیلوهای داده را حذف می کنید. همچنین، دید و ردیابی فرآیندها را در کل سازمان بهبود می‌بخشید.اهرم پردازشگر در نقطه تصمیم گیری کم کد و ساده. شما فقط باید وظایف را بکشید و رها کنید، فرم ها، کاربران و سایر ویژگی های آسان برای استفاده خود را اضافه کنید. شما به سرعت راه‌حل‌ها را با خودکارسازی گردش‌های کاری در هفته‌ها برخلاف بازه زمانی سنتی ماه‌ها به کار می‌گیرید. این به شما کمک می کند تا سطح بالای عملیات و برتری مشتری را حفظ کنید.Processmaker چهار طرح قیمت گذاری را ارائه می دهد که برای همه سازمان ها پوشش می دهد: App، Standard، Enterprise و Custom. همچنین می توانید قبل از اشتراک در هر یک از طرح ها، یک نسخه آزمایشی درخواست کنید.5- پلتفرم Creatio: یک ابزار BPM برنده جایزه برای بازاریابی، فروش و خدمات برای مدیریت فرآیندهای کسب و کار در یک پلت فرم واحد با کد پایین در کل سفر مشتری است. می‌توانید از Creatio برای خودکارسازی وظایف، اجرای قوانین و مقررات شخص ثالث استفاده کنید. Creatio با هماهنگ کردن سفرهای مشتری شما و تسریع در کسب درآمد، بازاریابی را بهبود می بخشد. برای فروش، ایجاد فرآیند فروش کامل را تسریع می‌کند، از سرب تا فروش تکراری. شما خدمات خود را از طریق Creatio با ساده‌سازی تعاملات مشتریان و تسریع در ارائه خدمات بهبود می‌بخشید.این شرکت به عنوان یک کلید اصلی بازار توسط تحلیلگران صنعتی به رسمیت شناخته شده است. نرم افزار آن باعث تسریع فروش، بازاریابی، خدمات و عملیات همه طیف وسیعی از مشاغل می شود. Creatio با فعالیت فعال در 110 کشور در سراسر جهان، نمایندگی جهانی دارد.پلتفرم Creatio bpm دارای سه ابزار Studio، Studio Enterprise و Studio Free می باشد. استودیو رایگان دارای ویژگی‌های محدودی است اما همچنان برای مشاغل کوچک مؤثر است. می توانید استودیو را به صورت رایگان برای یک دوره آزمایشی 14 روزه امتحان کنید.6- پلتفرم Bonitasoftبا پلتفرم  Bonita BMP از پشتیبانی کامل برای تمام عملیات دیجیتال و نوسازی فناوری اطلاعات خود لذت ببرید. Bonita یک پلت فرم اتوماسیون متن باز و توسعه پذیر است. استفاده از Bonita باعث افزایش دید و درک برای بهبود فرآیندهای کسب و کار شما می شود. استفاده از Bonita ساده است زیرا می توانید یک رابط کاربری پاسخگو با Bonita UI Designer ایجاد کنید. با Bonita، فرآیندها و برنامه های تجاری خود را نظارت و کنترل کنید.پلتفرم Bonitasoft BPM نحوه انجام کار را سازماندهی می کند، فرآیندهای کسب و کار را با درگیر کردن افراد از حوزه های مختلف خودکار می کند و عملکرد خود را در طول زمان تجزیه و تحلیل می کند. با اطمینان از ثبات و تداوم خدمات، نرم افزار BPM یک تجربه عالی برای مشتری ارائه می دهد. بیش از 150000 عضو و مشتری از بیش از 75 کشور در سراسر جهان دارد. اشتراک های سالانه Bonita توسط ابر داخلی، خصوصی یا عمومی یا Bonita Cloud تعیین می شود. برای ابر خصوصی، قیمت اشتراک 80000 دلار و بیش از 140000 دلار برای Bonita Cloud است.7- پلتفرم ProWorkflow: یک ابزار BPM بسیار محبوب است. این نرم افزار برای مدیران و کارکنان طراحی شده است تا برنامه ریزی، پیگیری و همکاری برای بهبود تحویل پروژه داشته باشند. توجه داشته باشید، ProWorkflow اکنون در هشتمین تکرار خود است، محصول تحقیق و توسعه مداوم. این نرم افزار دارای یک ویژگی مشترک است که به چندین عضو اجازه می دهد تا به طور همزمان کار کنند. این برنامه همچنین به یک تیم امکان چت، ارسال پیام، اشتراک گذاری فایل ها و موارد دیگر را می دهد.به نرم افزار ProWorkflow IBM اجازه دهید کنترل را در دست بگیرد تا بتوانید زمان کمتری را صرف مدیریت ذهنی فرآیند کسب و کار خود کنید. از ویژگی های ارائه شده توسط نرم افزار می توان به مدیریت وظایف، ورود و گزارش جدول زمانی، مدیریت مخاطبین، مدیریت گردش کار، قالب های با کاربری آسان و بسیاری موارد دیگر اشاره کرد. می توانید از برخی افزونه های دیگر استفاده کنید و همچنین محل کار خود را با ابزارهای انتخابی خود ادغام کنید.ProWorkflow دارای دو طرح قیمت گذاری است. حرفه ای و پیشرفته شما همچنین می توانید تصمیم بگیرید که آیا طرح پرداخت ماهانه یا سالانه را آغاز خواهید کرد.8- پلتفرم iGrafxIGrafx یک نرم افزار BPM است که استفاده از آن بسیار آسان است. به راحتی می تواند اتصال و همگام سازی اطلاعات بین تجربه مشتری و فرآیندهای تجاری را انجام دهد. iGrafx فرآیند کسب و کار شما را تجزیه و تحلیل می کند تا به برند شما کمک کند بهترین شیوه های فرآیند کسب و کار را شناسایی و پیاده سازی کند. با iGrafx، شما قدرت لازم برای شناسایی و اجرای مطلوب ترین فرآیندهای تجاری را دارید.ابزار IGrafx BPM استفاده بصری از گرافیک را با پشتیبانی کامل از تمام جنبه های طراحی کسب و کار فراهم می کند. این یک زیرساخت راه حل پایان به انتها برای استقرار ابر درون شرکتی، ریسک و تعظیم رسمی به روشی قابل مدیریت برای کسب و کارها فراهم می کند.برخی از ویژگی های موجود در ابزار iGrafx BPM عبارتند از: کنترل های دسترسی، مدیریت تقویم، ابزارهای همکاری، ردیابی انطباق، داشبورد، تجزیه و تحلیل طراحی، کنترل فرآیند کسب و کار و بسیاری موارد دیگر.IGrafx یک برنامه قیمت گذاری منطقی دارد. این نرم افزار همچنین دارای یک دوره آزمایشی رایگان است اما نسخه رایگان ندارد.9- پلتفرم  ComindwareComindware یک نرم افزار BPM با کد پایین است که برای تغییر روش مدیریت کسب و کار شما طراحی شده است. قابلیت های حیاتی برای وظایف، داده ها و مدیریت اسناد را فراهم می کند. Comindware برای فرآیندهای تجاری بدون ساختار و به سرعت در حال تغییر طراحی شده است.ابزار Comindware BPM از سال 2010 وارد بازار شده است و بیش از 98٪ بازخورد مثبت را در Gartner Peer Insights دریافت کرده است. همچنین، این نرم افزار بیش از 10 پتنت آمریکایی و بین المللی را به دست آورده است.برخی از ویژگی های متمایز ابزار Comindware BPM عبارتند از: برنامه ریزی خودکار پروژه، ردیابی پیشرفت، مدیریت منابع، ترکیب انعطاف پذیر پروژه ها، مجموعه مدیریت پروژه و حداکثر همکاری تیمی. Comindware همچنین گزینه های استقرار در محل و در فضای ابری را ارائه می دهد. مهم‌تر از همه، می‌توانید با ابزار Comindware BPM خود در دستگاه‌های دسکتاپ، iOS و Android خود کار کنید.Comindware یک مدل قیمت گذاری برای هر ویژگی ارائه می دهد، یک نسخه آزمایشی رایگان دارد اما نسخه رایگان ندارد.10- پلتفرم Kintone: یک ابزار BPM همه کاره در محل کار است. از Kintone برای انتقال پایگاه داده صفحه گسترده خود استفاده کنید و از نمایش بدون وقفه داده های خود لذت ببرید. این پلتفرم به شما انعطاف پذیری یک محل کار را می دهد که با تیم هایی برای ایجاد، اشتراک گذاری و خودکارسازی گردش های کاری سفارشی همکاری می کند. برای دریافت نتایج مبتنی بر داده، از Kintone استفاده کنید.می‌توانید از ابزار Kintone BPm برای ساخت برنامه‌های کاربردی برای کاربردهای خاص بدون هیچ بخش فناوری اطلاعات استفاده کنید. Kintone همکاری شما را با همکاران داخلی، شرکای خارجی و مشتریان افزایش می دهد. این نرم افزار نمودارها و نمودارهایی را برای داده های بلادرنگ با استفاده از ویژگی های خودکار نوآورانه نشان می دهد. مهمتر از همه، می‌توانید اعلان‌های درخواست تأیید را در دستگاه‌های تلفن همراه خود دریافت کنید.3- شركت‌هاي فعال در اين حوزه1- آرمان دنياي فناوري اطلاعات تتيس: هدف آن تسهیل و ساده سازی طراحی و پیاده سازی فرآیندهای سازمانی، خدمات الکترونیک و زیر سیستم های درون سازمانی تحت وب، است. نصب و راه‌اندازی سیستم مدیریت فرآیند تتیس: سیستم مدیریت فرآیند تتیس بر روی سرور اختصاص داده شده نصب می گردد و اطلاعات مدیریتی نرم افزار برای مشتری ارسال می گردد.تحلیل سامانه: با توجه به مستندات ارائه شده و پس از برگزاری جلسات شناخت با کارشناسان، سیستم تحلیل و طراحی می گرددپیاده سازی سامانه: پس از انجام تحلیل و طراحی، کارشناسان شرکت نسبت به پیاده سازی سامانه در سیستم مدیریت فرآیند اقدام می کنند، این شامل طراحی و ساخت جداول و فیلدها، طراحی فرم ها و لیست ها، طراحی گردش کار ها و فرآیندها و همچنین طراحی گرافیکی سامانه اقدام می کنند.بررسی نهایی و تحویل سامانه: در نهایت اطلاعات اولیه مشتری متناسب با مستندات ارائه شده، در سامانه قرار داده می شوند و تنظیمات نهایی نصب BPMS در سرور انجام می گردد و سامانه به مشتری جهت بهره برداری تحویل می گردد.آموزش سیستم مدیریت فرآیند و سامانه: پس از اتمام و تحویل سامانه، جلسه آموزش راهبری سیستم مدیریت فرآنید و یا سامانه های پیاده سازی با کارشناسان مشتری برگزار خواهد گردید.2- آيكن: با پیاده‌سازی زیرساخت ICAN BPMS، سازمان دارای زیرساختی خواهد بود که بتواند مبتنی بر آن نرم‌افزارهای سازمانی خودش را طراحی کند و بدون وابستگی به تولیدکننده و همچنین با اندکی آموزش، پرسنل می‌توانند بدون نیاز به دانش کدنویسی پیشرفته، توسعه سیستم‌ها و تهیه نرم‌افزار در این زیرساخت را یاد بگیرند. به همین دلیل تهیه و تولید این نرم‌افزار موجب افزایش بهره‌وری سازمان و کاهش هزینه‌های مالی و زمانی خواهد بود. مي‌توان نمونه سيستم‌هاي پياده سازي شده را در سامانه جامع آمار و اطلاعات آبادي كشور(نهاد رياست جمهوري)، سامانه رسيدگي به تخلفات اداري(نهاد رياست جمهوري) و ... مشاهده كرد. 4- جمع‌بندي استفاده از ابزارهای مدیریت پروژه تجاری سازمان ها را قادر می سازد تا وظایف تجاری را با نیازهای مشتری هماهنگ کنند. استفاده از ابزارهای BPM می تواند کارایی و بهره وری را افزایش دهد. هزینه ها را کاهش می دهد و خطاها و خطرات را به حداقل می رساند.منابع:1- https://en.wikipedia.org/wiki/Business_process_management2- https://www.integrify.com/what-is-bpms/3- https://bpmapp.com/bpm-tools4- https://ebpm.ir/102425- https://kissflow.com/workflow/bpm/bpm-tools-comparison-features/6- https://www.irandnn.ir/mag/what-is-bpms/«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»</description>
                <category>faezeh montazerin</category>
                <author>faezeh montazerin</author>
                <pubDate>Thu, 23 Dec 2021 07:20:56 +0330</pubDate>
            </item>
                    <item>
                <title>آشنایی با الگوی CQRS</title>
                <link>https://virgool.io/@faezehmonta1995/%D8%A2%D8%B4%D9%86%D8%A7%DB%8C%DB%8C-%D8%A8%D8%A7-%D8%A7%D9%84%DA%AF%D9%88%DB%8C-cqrs-i2a2coo2ouq0</link>
                <description>مقدمهمخفف Command and Query Responsibility Segregation است، الگویی که عملیات خواندن و به روز رسانی را برای یک ذخیره داده جدا می کند. پیاده سازی CQRS در برنامه شما می تواند عملکرد، مقیاس پذیری و امنیت آن را به حداکثر برساند. انعطاف‌پذیری ایجاد شده با مهاجرت به CQRS به سیستم اجازه می‌دهد در طول زمان بهتر تکامل یابد و از ایجاد تداخل ادغام در سطح دامنه توسط دستورات به‌روزرسانی جلوگیری می‌کند[1].زمینه و مشکلدر معماری های سنتی، از همان مدل داده برای پرس و جو و به روز رسانی پایگاه داده استفاده می شود. این ساده است و برای عملیات اولیه CRUD به خوبی کار می کند. با این حال، در برنامه های پیچیده تر، این رویکرد می تواند دشوار باشد. به عنوان مثال، در سمت خواندن، برنامه ممکن است پرس و جوهای مختلفی را انجام دهد و اشیاء انتقال داده (DTO) را با اشکال مختلف برگرداند. نقشه برداری شی می تواند پیچیده شود. در سمت نوشتن، مدل ممکن است اعتبار سنجی پیچیده و منطق تجاری را پیاده سازی کند. در نتیجه، می توانید با یک مدل بیش از حد پیچیده مواجه شوید که بیش از حد کار می کند.حجم کار خواندن و نوشتن اغلب نامتقارن است، با عملکرد و مقیاس بسیار متفاوت الزامات[1].اغلب یک عدم تطابق بین نمایش خواندن و نوشتن داده ها وجود دارد، مانند ستون ها یا ویژگی های اضافی که باید به درستی به روز شوند، حتی اگر به عنوان بخشی از یک عملیات مورد نیاز نباشند.زمانی که عملیات به صورت موازی روی یک مجموعه از داده ها انجام شود، اختلاف داده ها ممکن است رخ دهد.رویکرد سنتی می تواند به دلیل بارگذاری روی ذخیره داده ها و لایه دسترسی به داده ها و پیچیدگی پرس و جوهای مورد نیاز برای بازیابی اطلاعات، تأثیر منفی بر عملکرد داشته باشد.مدیریت امنیت و مجوزها می‌تواند پیچیده شود، زیرا هر موجودی تابع عملیات خواندن و نوشتن است، که ممکن است داده‌ها را در زمینه نادرست نمایش دهد[1].راه حلCQRS خواندن و نوشتن را به مدل‌های مختلف جدا می‌کند، با استفاده از دستورات برای به‌روزرسانی داده‌ها و پرس و جو برای خواندن داده‌ها.دستورات باید مبتنی بر وظیفه باشند، نه داده محور. (&quot;رزرو اتاق هتل&quot;، نه &quot;تنظیم وضعیت رزرو روی رزرو شده&quot;).دستورات ممکن است در یک صف برای پردازش ناهمزمان قرار گیرند، نه اینکه به صورت همزمان پردازش شوند.کوئری ها هرگز پایگاه داده را تغییر نمی دهند. یک پرس و جو یک DTO را برمی گرداند که هیچ دانش دامنه را کپسوله نمی کند[1].سپس می‌توان مدل‌ها را جدا کرد، همانطور که در نمودار زیر نشان داده شده است، اگرچه این یک الزام مطلق نیست.داشتن مدل های پرس و جو و به روز رسانی جداگانه، طراحی و پیاده سازی را ساده می کند. با این حال، یکی از معایب این است که کد CQRS نمی تواند به طور خودکار از طرحواره پایگاه داده با استفاده از مکانیسم های داربست مانند ابزارهای O/RM تولید شود. برای جداسازی بیشتر، می توانید داده های خوانده شده را از داده های نوشتن به صورت فیزیکی جدا کنید. در آن صورت، پایگاه داده خوانده شده می تواند از طرح داده های خود استفاده کند که برای پرس و جوها بهینه شده است. به عنوان مثال، می تواند یک نمای مادی از داده ها را ذخیره کند تا از اتصالات پیچیده یا نگاشت O/RM پیچیده جلوگیری کند. حتی ممکن است از نوع دیگری از ذخیره داده استفاده کند. به عنوان مثال، پایگاه داده نوشتن ممکن است رابطه ای باشد، در حالی که پایگاه داده خوانده شده یک پایگاه داده سند است. اگر از پایگاه‌های اطلاعاتی جداگانه خواندن و نوشتن استفاده می‌شود، باید آنها را هماهنگ نگه داشت. این معمولاً با انتشار یک رویداد توسط مدل نوشتن هر زمان که پایگاه داده را به روز می کند، انجام می شود. برای اطلاعات بیشتر در مورد استفاده از رویدادها، به سبک معماری رویداد محور مراجعه کنید. به روز رسانی پایگاه داده و انتشار رویداد باید در یک تراکنش انجام شود[1].فروشگاه خواندنی می‌تواند یک کپی فقط خواندنی از فروشگاه نوشتن باشد، یا فروشگاه‌های خواندن و نوشتن می‌توانند ساختار متفاوتی داشته باشند. استفاده از چند کپی فقط خواندنی می تواند عملکرد پرس و جو را افزایش دهد، به خصوص در سناریوهای توزیع شده که در آن کپی های فقط خواندنی نزدیک به نمونه های برنامه قرار دارند.جداسازی فروشگاه‌های خواندن و نوشتن همچنین اجازه می‌دهد تا هر کدام به‌طور مناسب برای مطابقت با بار، مقیاس شوند. به عنوان مثال، فروشگاه‌های خواندنی معمولاً با بار بسیار بالاتری نسبت به فروشگاه‌های نوشتن مواجه می‌شوند.برخی از پیاده سازی های CQRS از الگوی Event Sourcing استفاده می کنند. با این الگو، وضعیت برنامه به عنوان یک توالی از رویدادها ذخیره می شود. هر رویداد نشان دهنده مجموعه ای از تغییرات در داده ها است. وضعیت فعلی با پخش مجدد رویدادها ساخته می شود. در زمینه CQRS، یکی از مزایای Event Sourcing این است که از همان رویدادها می توان برای اطلاع رسانی به اجزای دیگر استفاده کرد - به ویژه برای اطلاع رسانی به مدل خوانده شده. مدل خواندن از رویدادها برای ایجاد یک عکس فوری از وضعیت فعلی استفاده می کند که برای پرس و جوها کارآمدتر است. با این حال، Event Sourcing به طراحی پیچیدگی می‌افزاید[1].مزایای CQRS1- مقیاس بندی مستقل CQRS اجازه می دهد تا حجم کار خواندن و نوشتن به طور مستقل مقیاس شود و ممکن است منجر به اختلافات قفل کمتر شود.2- طرحواره های داده بهینه شده سمت خوانده شده می تواند از طرحی استفاده کند که برای پرس و جوها بهینه شده است، در حالی که سمت نوشتن از طرحی استفاده می کند که برای به روز رسانی بهینه شده است.3- امنیت: اطمینان از اینکه فقط موجودیت های دامنه مناسب روی داده ها نوشتن را انجام می دهند آسان تر است.4- تفکیک نگرانی ها جداسازی دو طرف خواندن و نوشتن می‌تواند منجر به مدل‌هایی شود که قابلیت نگهداری و انعطاف‌پذیری بیشتری دارند. بیشتر منطق پیچیده کسب و کار وارد مدل نوشتن می شود. مدل خواندن می تواند نسبتا ساده باشد.5- پرس و جوهای ساده تر با ذخیره یک نمای مادی در پایگاه داده خوانده شده، برنامه می تواند از اتصالات پیچیده هنگام پرس و جو جلوگیری کند.مسائل و ملاحظات اجراییبرخی از چالش های اجرای این الگو عبارتند از:پیچیدگی: ایده اصلی CQRS ساده است. اما می تواند منجر به طراحی برنامه پیچیده تری شود، به خصوص اگر شامل الگوی منبع رویداد باشد.پیام رسانی: اگرچه CQRS به پیام نیازی ندارد، استفاده از پیام برای پردازش دستورات و انتشار رویدادهای به روز رسانی معمول است. در این صورت، برنامه باید با شکست پیام ها یا پیام های تکراری مقابله کند. برای برخورد با دستوراتی که اولویت های متفاوتی دارند، راهنمای صف های اولویت را ببینید.ثبات نهایی: اگر پایگاه داده خواندن و نوشتن را از هم جدا کنید، داده های خوانده شده ممکن است کهنه شده باشند. فروشگاه مدل خوانده شده باید به روز شود تا تغییرات را در فروشگاه مدل نوشتن منعکس کند، و تشخیص زمانی که کاربر بر اساس داده های خوانده شده قدیمی درخواستی صادر کرده است، می تواند دشوار باشد[1].زمان استفاده از الگوی CQRSCQRS را برای سناریوهای زیر در نظر بگیرید:- دامنه های مشارکتی که در آن بسیاری از کاربران به طور موازی به داده های مشابه دسترسی دارند. CQRS به شما اجازه می دهد تا دستوراتی را با جزئیات کافی تعریف کنید تا تضادهای ادغام را در سطح دامنه به حداقل برسانید و تداخل هایی که به وجود می آیند را می توان با دستور ادغام کرد.- رابط های کاربری مبتنی بر وظیفه که در آن کاربران از طریق یک فرآیند پیچیده به عنوان یک سری مراحل یا با مدل های دامنه پیچیده هدایت می شوند. مدل نوشتن دارای یک پشته پردازش فرمان کامل با منطق تجاری، اعتبارسنجی ورودی و اعتبارسنجی تجاری است. مدل نوشتن ممکن است مجموعه‌ای از اشیاء مرتبط را به‌عنوان یک واحد واحد برای تغییرات داده‌ها (یک مجموع، در اصطلاح DDD) در نظر بگیرد و اطمینان حاصل کند که این اشیاء همیشه در یک حالت ثابت هستند. مدل خوانده شده هیچ منطق تجاری یا پشته اعتبار سنجی ندارد و فقط - یک DTO را برای استفاده در یک مدل view برمی گرداند. مدل خواندن در نهایت با مدل نوشتن سازگار است.سناریوهایی که عملکرد خواندن داده ها باید جدا از عملکرد نوشتن داده ها تنظیم شود، به خصوص زمانی که تعداد خواندن ها بسیار بیشتر از تعداد نوشتن ها باشد. در این سناریو، می توانید مدل خوانده شده را کوچک کنید، اما مدل نوشتن را تنها در چند نمونه اجرا کنید. تعداد کمی از نمونه های مدل نوشتن نیز به به حداقل رساندن وقوع تضادهای ادغام کمک می کند[1].- سناریوهایی که در آن یک تیم از توسعه دهندگان می توانند بر روی مدل دامنه پیچیده که بخشی از مدل نوشتن است تمرکز کنند و تیم دیگری می توانند بر روی مدل خواندن و رابط های کاربر تمرکز کنند.- سناریوهایی که در آن انتظار می‌رود سیستم در طول زمان تکامل یابد و ممکن است چندین نسخه از مدل را شامل شود، یا قوانین تجاری به طور منظم تغییر می‌کنند.- ادغام با سایر سیستم ها، به ویژه در ترکیب با منبع رویداد، که در آن خرابی موقت یک زیرسیستم نباید بر در دسترس بودن سایر سیستم ها تأثیر بگذارد.این الگو زمانی توصیه نمی شودکه[3]:1- دامنه یا قوانین تجارت ساده هستند.2- یک رابط کاربری ساده به سبک CRUD و عملیات دسترسی به داده کافی است.استفاده از CQRS را در بخش های محدودی از سیستم خود در نظر بگیرید که در آن بیشترین ارزش را دارد.رویداد منبع یابی و الگوی CQRSالگوی CQRS اغلب همراه با الگوی منبع رویداد استفاده می شود. سیستم‌های مبتنی بر CQRS از مدل‌های داده خواندن و نوشتن جداگانه استفاده می‌کنند که هر کدام برای وظایف مربوطه طراحی شده و اغلب در فروشگاه‌های فیزیکی مجزا قرار دارند. هنگامی که با الگوی منبع رویداد استفاده می شود، ذخیره رویدادها مدل نوشتن است و منبع رسمی اطلاعات است. مدل خواندنی یک سیستم مبتنی بر CQRS، نماهای واقعی داده‌ها را، معمولاً به‌عنوان نماهای بسیار غیرعادی‌شده، ارائه می‌کند. این نماها بر اساس واسط ها و الزامات نمایش برنامه طراحی شده اند، که به به حداکثر رساندن عملکرد نمایش و پرس و جو کمک می کند.استفاده از جریان رویدادها به‌عنوان ذخیره‌سازی نوشتن، به‌جای داده‌های واقعی در یک نقطه از زمان، از تضاد به‌روزرسانی در یک مجموع اجتناب می‌کند و عملکرد و مقیاس‌پذیری را به حداکثر می‌رساند. از رویدادها می توان برای تولید ناهمزمان نماهای واقعی داده هایی که برای پر کردن فروشگاه خوانده استفاده می شود استفاده کرد.از آنجایی که فروشگاه رویداد منبع رسمی اطلاعات است، می‌توان نماهای تحقق‌یافته را حذف کرد و همه رویدادهای گذشته را مجدداً پخش کرد تا زمانی که سیستم تکامل می‌یابد، یا زمانی که مدل خوانده شده باید تغییر کند، نمایش جدیدی از وضعیت فعلی ایجاد شود. نماهای تحقق یافته در واقع یک حافظه پنهان فقط خواندنی از داده ها هستند[4].هنگام استفاده از CQRS همراه با الگوی منبع رویداد، موارد زیر را در نظر بگیرید[4]:- مانند هر سیستمی که ذخیره‌های نوشتن و خواندن مجزا هستند، سیستم‌های مبتنی بر این الگو تنها در نهایت سازگار هستند. بین ایجاد رویداد و به‌روزرسانی ذخیره‌گاه داده تأخیر وجود خواهد داشت.- این الگو پیچیدگی می‌افزاید، زیرا کد باید برای راه‌اندازی و مدیریت رویدادها، و جمع‌آوری یا به‌روزرسانی نماها یا اشیاء مناسب مورد نیاز کوئری‌ها یا یک مدل خوانده شده ایجاد شود. پیچیدگی الگوی CQRS زمانی که با الگوی منبع یابی رویداد استفاده می‌شود، می‌تواند اجرای موفقیت‌آمیز را دشوارتر کند و به رویکرد متفاوتی برای طراحی سیستم‌ها نیاز دارد. با این حال، منبع رویداد می‌تواند مدل‌سازی دامنه را آسان‌تر کند، و بازسازی نماها یا ایجاد نماهای جدید را آسان‌تر می‌کند، زیرا هدف از تغییرات در داده‌ها حفظ می‌شود.- ایجاد نماهای تحقق یافته برای استفاده در مدل خوانده شده یا پیش بینی داده ها با پخش مجدد و مدیریت رویدادها برای موجودیت ها یا مجموعه هایی از موجودیت ها می تواند به زمان پردازش و استفاده از منابع قابل توجهی نیاز داشته باشد. این امر به ویژه در صورتی صادق است که به جمع بندی یا تجزیه و تحلیل مقادیر در دوره های طولانی نیاز داشته باشد، زیرا ممکن است همه رویدادهای مرتبط نیاز به بررسی داشته باشند. این مشکل را با اجرای عکس‌های فوری از داده‌ها در فواصل زمانی برنامه‌ریزی‌شده، مانند شمارش کل تعداد یک عمل خاص که رخ داده است، یا وضعیت فعلی یک موجودیت، حل کنید[4].اصول اصلیاصل اصلی CQRS جداسازی دستورات و کوئری ها و کارهایی است که انجام می دهند. آنها نقش‌های اساسی متفاوتی را در یک سیستم انجام می‌دهند، و تفکیک آنها به این معنی است که هر کدام می‌توانند در صورت نیاز بهینه شوند، که می‌تواند برای سیستم‌های توزیع شده بسیار مفید باشد.Alexey Zimarev تعریف کرده است که چگونه دستورات و پرس و جوها متفاوت هستند:در سطح بالایی، CQRS این واقعیت را بیان می‌کند که عملیات‌هایی که انتقال حالت را راه‌اندازی می‌کنند باید به‌عنوان دستورات توصیف شوند، و هر بازیابی داده‌ای که فراتر از نیاز اجرای دستور است، باید یک پرس و جو نامیده شود. از آنجایی که الزامات عملیاتی برای اجرای دستورات و پرس و جوها اغلب متفاوت است، توسعه دهندگان باید استفاده از تکنیک های ماندگاری مختلف را برای رسیدگی به دستورات و پرس و جوها در نظر بگیرند، بنابراین آنها را از هم جدا کنند[2].ارتباط با طراحی دامنه محورطراحی دامنه محور (DDD) روشی برای بهینه سازی درک تیم از یک فضای مشکل و نحوه کار در آن فضا است. این در مورد داشتن زبانی فراگیر است که توسط کاربران تجاری و تیم توسعه استفاده می شود. این یکسان سازی زبان می تواند در هنگام ترجمه مفهوم مشکل به نرم افزار کاربردی بسیار مفید باشد.CQRS و DDD مفاهیم مجزا و متعامد هستند. برای استفاده از DDD نیازی به استفاده از CQRS ندارید یا برعکس. هنگامی که آنها با هم استفاده می شوند، DDD می تواند یک زمینه محدود، مشتق شده از مکالمات کسب و کار را فراهم کند، و CQRS می تواند نحوه انتقال کار را در سیستم تعریف کند. DDD در اصل با CQRS هماهنگ است، اما قطعاً به یکدیگر وابسته نیست[5].در پایانالگوی تفکیک مسئولیت پرس و جو فرمان یک تکنیک طراحی ارزشمند است که برای برنامه هایی که نیاز به پشتیبانی از حجم بالایی از درخواست های ارائه شده در برابر منابع داده بسیار بزرگ دارند، مناسب است. جداسازی رفتار خواندن از نوشتن عملکرد سیستم را به طور کلی بهبود می بخشد. و به سیستم‌ها اجازه می‌دهد تا زمانی که عملکردها یا ساختارهای داده اضافه شوند، به سرعت افزایش پیدا کنند. هنگامی که CQRS در ارتباط با الگوی میانجی استفاده می شود، سیستم را انعطاف پذیرتر می کند و بازسازی آن را آسان تر می کند.با این حال، در حالی که CQRS قدرتمند است، ساده نیست. جداسازی داده ها بر اساس هدف به این معنی است که همیشه خطر سازگاری داده ها به خطر می افتد یا به دلیل درجات مختلف تأخیر در شبکه یا خرابی سیستم اپیزودیک. بنابراین، پیاده سازی CQRS با استفاده از یک معماری پایداری داده مبتنی بر رویداد که در آن کارگزار پیام سیستم می تواند هر پیام دریافتی را برای مدت بسیار طولانی ذخیره کند، راه معقولی است.CQRS می تواند عملکرد و کارایی سیستم را افزایش دهد. ترفند این است که مطمئن شوید که معماری برنامه کاربردی که در آن پیاده‌سازی می‌شود به‌طور سست جفت شده است و در صورت خرابی فاجعه‌بار می‌تواند به آخرین وضعیت خوب شناخته‌شده بازسازی شود[6].منابع[1]https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs[2]https://martinfowler.com/bliki/CQRS.html[3]https://en.wikipedia.org/wiki/Command%E2%80%93query_separation[4]https://www.eventstore.com/cqrs-pattern[5]https://sderosiaux.medium.com/cqrs-what-why-how-945543482313[6]https://www.baeldung.com/cqrs-event-sourcing-javaاین مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.</description>
                <category>faezeh montazerin</category>
                <author>faezeh montazerin</author>
                <pubDate>Fri, 03 Dec 2021 14:30:35 +0330</pubDate>
            </item>
                    <item>
                <title>آشنايي با Hexagonal Architecture</title>
                <link>https://virgool.io/@faezehmonta1995/%D8%A2%D8%B4%D9%86%D8%A7%D9%8A%D9%8A-%D8%A8%D8%A7-hexagonal-architecture-x1davh8mtlof</link>
                <description>[6]Hexagonal Architectureمعماری شش ضلعی یا معماری پورت ها و آداپتورها، یک الگوی معماری است که در طراحی نرم افزار استفاده می شود. هدف آن ایجاد مؤلفه‌های برنامه‌ای است که با اتصال آزاد به هم متصل می‌شوند که می‌توانند به راحتی با استفاده از پورت‌ها و آداپتورها به محیط نرم‌افزار خود متصل شوند. این باعث می شود اجزا در هر سطحی قابل تعویض باشند و اتوماسیون تست را تسهیل می کند.معماری شش ضلعی توسط Alistair Cockburn در تلاش برای جلوگیری از مشکلات ساختاری شناخته شده در طراحی نرم افزار شی گرا، مانند وابستگی های نامطلوب بین لایه ها و آلودگی کد رابط کاربر با منطق تجاری، ابداع شد و در سال 2005 منتشر شد.اصطلاح &quot;هگزاگونال&quot; از قراردادهای گرافیکی می آید که جزء برنامه را مانند یک سلول شش ضلعی نشان می دهد. هدف پیشنهاد این نبود که شش مرز/پورت وجود داشته باشد، بلکه باید فضای کافی برای نمایش رابط‌های مختلف مورد نیاز بین مؤلفه و دنیای خارجی باقی بماند[1].معماری شش ضلعی یک سیستم را به چندین مؤلفه قابل تعویض با اتصال آزاد تقسیم می کند، مانند هسته برنامه، پایگاه داده، رابط کاربر، اسکریپت های تست و رابط با سایر سیستم ها. این رویکرد جایگزینی برای معماری سنتی لایه‌ای است.هر مؤلفه از طریق تعدادی پورت در معرض دید به اجزای دیگر متصل می شود. ارتباط از طریق این پورت ها بسته به هدف آنها از یک پروتکل مشخص پیروی می کند. پورت‌ها و پروتکل‌ها یک API انتزاعی را تعریف می‌کنند که می‌تواند با هر ابزار فنی مناسب (مانند فراخوانی روش در یک زبان شی‌گرا، فراخوانی رویه‌های راه دور یا سرویس‌های وب) پیاده‌سازی شود.دانه بندی پورت ها و تعداد آنها محدود نیست. یک پورت واحد در برخی موارد می تواند کافی باشد (مثلاً در مورد مصرف کننده خدمات ساده).به طور معمول، پورت‌هایی برای منابع رویداد (رابط کاربری، تغذیه خودکار)، اعلان‌ها (اعلان‌های خروجی)، پایگاه داده (به منظور ارتباط مؤلفه با هر DBMS مناسب) و مدیریت (برای کنترل مؤلفه) وجود دارد.در یک حالت شدید، در صورت نیاز، ممکن است یک پورت متفاوت برای هر مورد استفاده وجود داشته باشد.آداپتورها اتصال دهنده بین اجزا و دنیای بیرون هستند. آنها مبادلات بین دنیای بیرونی و پورت هایی را که نشان دهنده الزامات داخل مؤلفه برنامه هستند، تنظیم می کنند. می‌تواند چندین آداپتور برای یک پورت وجود داشته باشد، برای مثال اگر داده‌ها توسط کاربر از طریق رابط کاربری گرافیکی یا یک رابط خط فرمان، توسط یک منبع داده خودکار، یا توسط اسکریپت‌های آزمایشی ارائه شوند.سازماندهي کد در داخل و خارج جدا از اصولی که در بالا مشاهده شد، ما کاملاً آزادیم که کد را در هر منطقه دقیقاً همانطور که می خواهیم سازماندهی کنیم.در مورد کد کسب و کار، در داخل، یک ایده خوب این است که ماژول ها (یا دایرکتوری ها) آن را بر اساس منطق تجاری سازماندهی کنید[6]. در زمان اجرادقیقاً چگونه همه اینها را برای ارضای وابستگی‌های زمان اجرا مثال می‌زنید؟ اگر از چارچوب تزریق وابستگی استفاده می کنید، ممکن است نیازی به پرسیدن این سوال از خود نداشته باشید. اما من فکر می کنم که برای درک معماری شش ضلعی، جالب است که ببینیم با شروع برنامه چه اتفاقی می افتد. و برای انجام این کار، حداقل برای زمان این مقاله از چارچوب تزریق وابستگی استفاده نکنید.به عنوان مثال، اگر همه چیز را با دست نمونه برداری کنیم، در اینجا چگونه نقطه ورود برنامه را می نویسیم:class Program{    static void Main(string[] args)    {        // 1. Instantiate right-side adapter (&quot;go outside the hexagon&quot;)        IObtainPoems fileAdapter = new PoetryLibraryFileAdapter(@&quot;.\Peoms.txt&quot;);        // 2. Instantiate the hexagon        IRequestVerses poetryReader = new PoetryReader(fileAdapter);        // 3. Instantiate the left-side adapter (&quot;I want ask/to go inside&quot;)        var consoleAdapter = new ConsoleAdapter(poetryReader);        System.Console.WriteLine(&quot;Here is some...&quot;);        consoleAdapter.Ask();        System.Console.WriteLine(&quot;Type enter to exit...&quot;);        System.Console.ReadLine();    }}ابتدا سمت سرور را نمونه سازی می کنیم، در اینجا fileAdapter که فایل را می خواند.ما کلاس Business Logic را که توسط برنامه هدایت می‌شود، نمونه‌سازی می‌کنیم، poetryReader که در آن fileAdapter را با تزریق به سازنده تزریق می‌کنیم.User-Side را نصب کنید، کنسول Adapter که شعرخوان را هدایت می کند و روی کنسول می نویسد. در اینجا poetryReader با تزریق به سازنده به آداپتور کنسول تزریق می شود.گفتیم داخل نباید به بیرون وابسته باشد. پس چرا فایل Adapter را که کدی از سمت سرور است به poetryReader که کدی از Business Logic است تزریق می کنیم؟ما می‌توانیم این کار را انجام دهیم زیرا با نگاه کردن به طرح‌واره‌ها و کدها، علاوه بر اینکه یک PoetryLibraryFileAdapter (سمت سرور) است، fileAdapter نیز نمونه‌ای از IObtainPoems به‌واسطه وراثت است.در عمل، PoetryReader به PoetryLibraryFileAdapter وابسته نیست، بلکه به IObtainPoems وابسته است که در کد Business Logic به خوبی تعریف شده است. می توانید آن را با نگاه کردن به امضای سازنده آن بررسی کنید[2].اصطلاح &quot;شش ضلعی&quot; به این معنی است که 6 بخش برای مفهوم وجود دارد، در حالی که تنها 4 بخش کلیدی وجود دارد. استفاده از این اصطلاح از قراردادهای گرافیکی ناشی می شود که جزء برنامه را مانند یک سلول شش ضلعی نشان می دهد. هدف پیشنهاد این نبود که شش مرز/پورت وجود داشته باشد، بلکه این بود که فضای کافی برای نمایش رابط‌های مختلف مورد نیاز بین جزء و دنیای خارجی باقی بماند.به گفته مارتین فاولر، معماری شش ضلعی این مزیت را دارد که از شباهت‌های بین لایه ارائه و لایه منبع داده برای ایجاد اجزای متقارن ساخته شده از یک هسته احاطه شده توسط رابط‌ها استفاده می‌کند، اما با این اشکال که عدم تقارن ذاتی بین ارائه‌دهنده خدمات و مصرف‌کننده خدمات را پنهان می‌کند. که بهتر است به عنوان لایه نشان داده شود[5].پورت هاما می‌توانیم یک پورت را به‌عنوان یک نقطه ورود فناوری-آگنوستیک ببینیم، آن رابطی را تعیین می‌کند که به بازیگران خارجی اجازه می‌دهد با برنامه ارتباط برقرار کنند، صرف نظر از اینکه چه کسی یا چه چیزی رابط مذکور را پیاده‌سازی خواهد کرد. همانطور که یک پورت USB به چندین نوع دستگاه اجازه می دهد تا زمانی که یک آداپتور USB دارند با یک کامپیوتر ارتباط برقرار کنند. پورت ها همچنین به برنامه اجازه می دهند تا با سیستم ها یا خدمات خارجی مانند پایگاه های داده، کارگزاران پیام، سایر برنامه ها و غیره ارتباط برقرار کند.نکته حرفه ای: یک پورت همیشه باید دو آیتم به آن متصل باشد، یکی همیشه آزمایشی است.آداپتورهایک آداپتور تعامل با برنامه را از طریق یک پورت، با استفاده از یک فناوری خاص آغاز می کند، برای مثال، یک کنترل کننده REST آداپتوری را نشان می دهد که به مشتری اجازه می دهد با برنامه ارتباط برقرار کند. می‌تواند به تعداد مورد نیاز برای هر پورت آداپتور وجود داشته باشد بدون اینکه خطری برای پورت‌ها یا خود برنامه ایجاد کند.کاربردبرنامه هسته سیستم است، شامل خدمات کاربردی است که عملکرد یا موارد استفاده را هماهنگ می کند. همچنین شامل مدل دامنه است که منطق تجاری است که در Aggregates، Entities و Value Objects تعبیه شده است. برنامه توسط یک شش ضلعی نمایش داده می شود که دستورات یا پرس و جوها را از پورت ها دریافت می کند و درخواست ها را از طریق پورت ها به دیگر بازیگران خارجی مانند پایگاه های داده نیز ارسال می کند.هنگامی که با طراحی دامنه محور جفت می شود، برنامه یا شش ضلعی شامل لایه های برنامه و دامنه است و لایه های رابط کاربری و زیرساخت را بیرون می گذارد[3].وارونگی وابستگی در زمینه معماری شش ضلعیاصل وارونگی وابستگی یکی از 5 اصل است که توسط (عمو) باب مارتین در Paper OO Design Quality Metrics و بعداً در کتاب Agile Software Development Principles, Patterns and Practices ابداع شده است، جایی که او آن را به شرح زیر تعریف می کند:ماژول های سطح بالا نباید به ماژول های سطح پایین وابسته باشند. هر دو باید به انتزاعات بستگی داشته باشند.انتزاع ها نباید به جزئیات بستگی داشته باشند. جزئیات باید به انتزاعات بستگی داشته باشد.همانطور که قبلا ذکر شد، سمت چپ و راست شش ضلعی شامل 2 نوع مختلف بازیگر است، Driving و Driven که هر دو پورت و آداپتور وجود دارند.دليل استفاده از پورت ها و آداپتورها استفاده از معماری پورت ها و آداپتورها مزایای زیادی دارد، یکی از آنها این است که بتوانید منطق برنامه و منطق دامنه خود را به صورت کاملاً آزمایشی ایزوله کنید. از آنجایی که به عوامل خارجی وابسته نیست، آزمایش آن طبیعی می شود.همچنین به شما این امکان را می‌دهد که تمام رابط‌های سیستم خود را بر اساس هدف و نه با فناوری، طراحی کنید، از قفل شدن شما جلوگیری می‌کند، و توسعه پشته فناوری برنامه‌تان را با گذشت زمان آسان‌تر می‌کند. اگر نیاز به تغییر لایه persistence دارید، آن را دنبال کنید. اگر باید اجازه دهید برنامه شما به جای انسان توسط ربات های Slack فراخوانی شود، متوجه شدید تنها کاری که باید انجام دهید این است که آداپتورهای جدید را پیاده سازی کنید و آماده هستید.معماری پورت ها و آداپتورها نیز با طراحی Domain-Driven بسیار خوب عمل می کند، مزیت اصلی آن این است که از منطق دامنه برای نشت از هسته برنامه شما محافظت می کند. فقط مراقب نشت بین لایه های Application و Domain باشید[4]. اجزای قابل تعویضماژول A می تواند از رابط برای ارسال پیام استفاده کند. هیچ راهی برای دانستن اینکه واقعاً چگونه یا چه چیزی پیام را دریافت می کند، ندارد. این بزرگترین مزیت معماری شش ضلعی است!معماری شش ضلعی همه چیز در مورد مبادله اجزا به ویژه اجزای خارجی است. در مثال بالا، میزبان ماژول IUserRepo را به کلاس UserAdmin تزریق می کند. میزبان می تواند یک برنامه وب، یک برنامه کنسول، یک چارچوب آزمایشی یا حتی یک برنامه دیگر باشد. نکته این است که هسته را از ورودی و خروجی آن مستقل کنیم.كوك برن بر اهمیت جدا کردن برنامه از رابط کاربری تأکید کرد. اینجاست که او واقعاً به دنبال متمایز کردن رویکرد خود از معماری لایه‌ای بود. از این گذشته، هدف اصلی جداسازی از طریق پورت ها و آداپتورها، تست درایو برنامه با استفاده از نرم افزار (یک مهار تست) است. تست درایوقبلاً مزایای استفاده از معماری شش ضلعی را در طراحی شما برشمردم. اکنون، اجازه دهید به صراحت توضیح دهم که چرا باید از این الگو استفاده کنید.نکته اصلی این است که برای آزمایش برنامه خود نیازی به تکیه بر عوامل خارجی ندارید. در عوض، فقط هسته سیستم را از طریق پورت ها در تعامل قرار دهید. به این ترتیب، چارچوب آزمایشی شما، برنامه را از طریق آن پورت ها هدایت می کند. حتی می توانید از فایل ها و اسکریپت ها برای درایو آن استفاده کنید.برای ارائه یک سناریوی متداول از نحوه عملکرد این در عمل، فرض کنید از یک چارچوب تست دات نت مانند xUnit استفاده می کنیم. دونده آزمون، در این مورد، میزبان است.چهار تعامل زیر بین تست ها و برنامه از طریق پورت ها انجام می شود[4]:تست ها ورودی را به برنامه ارسال می کنند.دوبل های تست خروجی را از برنامه دریافت می کنند.تست ورودی را به برنامه باز می گرداند.تست ها خروجی را از برنامه دریافت می کنند.تست‌ها و تست‌های دوگانه (مانند ساختگی، تقلبی و خرد) برنامه را از طریق پورت‌ها هدایت می‌کنند.نتيجه‌گيريمعماری شش ضلعی یا پورت‌ها و آداپتورها، معجزه‌اي برای همه برنامه‌ها نیست. این شامل سطح معینی از پیچیدگی است، که وقتی با دقت از آن استفاده شود، مزایای زیادی برای سیستم شما به همراه خواهد داشت. اما اگر شکستن شیشه ها مجاز باشد، ممکن است باعث سردردهای زیادی شود.پورت ها و آداپتورها هنگامی که به درستی پیاده سازی و با سایر متدولوژی ها، مانند طراحی دامنه محور، جفت شوند، می توانند پایداری و توسعه پذیری طولانی مدت برنامه را تضمین کنند و ارزش زیادی برای سیستم و سازمان به ارمغان بیاورند.تئوری اصلی پشت آن جدا کردن منطق برنامه از ورودی و خروجی است. هدف این است که برنامه را آسان تر آزمایش کنیم. آلیستر کاکبرن اصطلاحات را از &quot;معماری شش ضلعی&quot; به &quot;پورت ها و آداپتورها&quot; تغییر داد.«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»منابع1- https://en.wikipedia.org/wiki/Hexagonal_architecture_(software)2- https://blog.octo.com/en/hexagonal-architecture-three-principles-and-an-implementation-example/#inOut3- https://medium.com/ssense-tech/hexagonal-architecture-there-are-always-two-sides-to-every-story-bc0780ed7d9c4- https://dzone.com/articles/hexagonal-architecture-what-is-it-and-how-does-it5- https://alistair.cockburn.us/hexagonal-architecture/6- https://blog.allegro.tech/2020/05/hexagonal-architecture-by-example.html7- https://www.youtube.com/watch?v=fGaJHEgonKg8- https://www.youtube.com/watch?v=9b_sTDE8uKo</description>
                <category>faezeh montazerin</category>
                <author>faezeh montazerin</author>
                <pubDate>Tue, 30 Nov 2021 15:33:19 +0330</pubDate>
            </item>
                    <item>
                <title>آشنايي با Model-View-ViewModel (MVVM)</title>
                <link>https://virgool.io/@faezehmonta1995/%D8%A2%D8%B4%D9%86%D8%A7%D9%8A%D9%8A-%D8%A8%D8%A7-model-view-viewmodel-mvvm-yyrc1f0qg8yo</link>
                <description>در اين صفحه ميخواهيم با الگوي MVVM بيشتر آشنا شويم. معماري MVVMاين الگو، الگوي معماري براي طراحي واسط كاربر است. Model – view – viewmodel (MVVM) یک الگوی معماری نرم‌افزاری است که جداسازی توسعه رابط کاربری گرافیکی - چه از طریق یک زبان نشانه‌گذاری یا کد رابط کاربری گرافیکی - از توسعه منطق کسب‌وکار یا پشتیبان را تسهیل می‌کند. منطق پایان به طوری که دیدگاه به هیچ پلتفرم مدل خاصی وابسته نباشد. viewmodel MVVM یک مبدل مقدار است، به این معنی که viewmodel مسئول نمایش (تبدیل) اشیاء داده از مدل است به گونه ای که اشیا به راحتی مدیریت و ارائه شوند.  گونه‌ای از الگوی طراحی مدل ارائه مارتین فاولر است. این توسط معماران مایکروسافت کن کوپر و تد پیترز به طور خاص برای ساده کردن برنامه‌نویسی رویداد محور رابط‌های کاربری اختراع شد. این الگو در Windows Presentation Foundation (WPF) (سیستم گرافیکی دات نت مایکروسافت) و Silverlight (مشتق برنامه کاربردی اینترنتی WPF) گنجانده شد. جان گاسمن، یکی از معماران مایکروسافت WPF و Silverlight، MVVM را در وبلاگ خود در سال 2005 اعلام کرد.Model-view-viewmodel همچنین به عنوان model-view-binder شناخته می شود، به ویژه در پیاده سازی هایی که شامل پلتفرم دات نت نیستند. ZK (یک چارچوب برنامه کاربردی وب که به زبان جاوا نوشته شده است) و KnockoutJS (یک کتابخانه جاوا اسکریپت) از model–view–binder استفاده می‌کنند.الگوي MVVMاز این الگو زمانی استفاده کنید که نیاز دارید مدل‌ها را به نمایش دیگری برای نما تبدیل کنید. به عنوان مثال، می توانید از یک مدل view برای تبدیل یک تاریخ به یک رشته با قالب تاریخ، یک اعشار به یک رشته با قالب ارز یا بسیاری از تبدیل های مفید دیگر استفاده کنید.این الگو به خوبی MVC را تحسین می کند. بدون مدل‌های view، احتمالاً کد تبدیل مدل به مشاهده را در کنترل‌کننده مشاهده خود قرار می‌دهید. با این حال، کنترل‌کننده‌های view در حال حاضر کارهای زیادی انجام می‌دهند: مدیریت viewDidLoad و سایر رویدادهای چرخه حیات مشاهده، مدیریت تماس‌های مشاهده از طریق IBActions و چندین کار دیگر نیز.این منجر به چیزی می شود که توسعه دهندگان به شوخی از آن به عنوان &quot;MVC: Massive View Controller&quot; یاد می کنند.اجزاي الگوي MVVMمدلمدل یا به یک مدل دامنه اشاره دارد که محتوای حالت واقعی را نشان می دهد (رویکرد شی گرا)، یا به لایه دسترسی به داده که نشان دهنده محتوا است (رویکرد داده محور)ويوهمانطور که در الگوهای model-view-controller (MVC) و model-view-presenter (MVP)، نما، ساختار، طرح‌بندی، ظاهر چیزی است که کاربر روی صفحه می‌بیند، نمایشی از مدل را نمایش می‌دهد و تعامل کاربر با نما را دریافت می‌کند (کلیک‌های ماوس، ورودی صفحه‌کلید، حرکات ضربه روی صفحه، و غیره)، و مدیریت این موارد را از طریق اتصال داده (ویژگی‌ها، تماس‌های رویداد) به مدل view ارسال می‌کند.مدل ويومدل view یک انتزاع از نما است که ویژگی ها و دستورات عمومی را نشان می دهد. به جای کنترل‌کننده الگوی MVC یا ارائه‌دهنده الگوی MVP، MVVM دارای یک کلاسور است که ارتباط بین view و ویژگی‌های محدود آن در مدل view را خودکار می‌کند. مدل view به عنوان حالتی از داده ها در مدل توصیف شده است.تفاوت اصلی بین مدل view و Presenter در الگوی MVP این است که ارائه دهنده به یک view ارجاع دارد، در حالی که مدل view اینطور نیست. در عوض، یک view مستقیماً به ویژگی‌های مدل view متصل می‌شود تا به‌روزرسانی‌ها را ارسال و دریافت کند.بايندرداده های اعلامی و اتصال فرمان در الگوی MVVM ضمنی هستند. در پشته راه حل مایکروسافت، بایندر یک زبان نشانه گذاری به نام XAML است. بایندر توسعه‌دهنده را از موظف به نوشتن منطق صفحه دیگر برای همگام‌سازی مدل و نما آزاد می‌کند. هنگامی که خارج از پشته مایکروسافت پیاده‌سازی می‌شود، وجود یک فن‌آوری پیوند داده‌های اعلامی چیزی است که این الگو را ممکن می‌سازد و بدون یک بايندر، معمولاً می‌توان به جای آن از MVP یا MVC استفاده کرد.ديتا بايندينگ یک طرفه:وقتی اطلاعات مدل تغییر می‌کنه، بصورت خودکار اطلاعاتی که ویوو داره نمایش میده هم تغییر می‌کنه.ديتا بايندينگ دو طرفه:توی این روش وقتی اطلاعات نمایشی توی View تغییر می‌کنه، اطلاعات مدل بصورت خودکار و آنی هم تغییر پیدا می‌کنه.برای حذف تقریباً تمام کدهای رابط کاربری گرافیکی (&quot;code-behind&quot;) از لایه view، با استفاده از توابع اتصال داده در WPF (بنیاد ارائه ویندوز) طراحی شده است تا جداسازی توسعه لایه دید از بقیه الگو را بهتر تسهیل کند. به‌جای اینکه توسعه‌دهندگان تجربه کاربری (UX) را مجبور به نوشتن کد رابط کاربری گرافیکی کنند، می‌توانند از زبان نشانه‌گذاری چارچوب (مانند XAML) استفاده کنند و پیوندهای داده‌ای را به مدل view ایجاد کنند، که توسط توسعه‌دهندگان برنامه نوشته و نگهداری می‌شود. جداسازی نقش‌ها به طراحان تعاملی اجازه می‌دهد تا به جای برنامه‌نویسی منطق تجاری، بر نیازهای UX تمرکز کنند. بنابراین، لایه های یک برنامه کاربردی را می توان در جریان های کاری متعدد برای بهره وری بالاتر توسعه داد. حتی زمانی که یک توسعه‌دهنده منفرد بر روی کل پایه کد کار می‌کند، جداسازی مناسب نما از مدل مؤثرتر است، زیرا رابط کاربری معمولاً بر اساس بازخورد کاربر نهایی اغلب و در اواخر چرخه توسعه تغییر می‌کند.الگوی MVVM تلاش می کند تا هر دو مزیت جداسازی توسعه عملکردی ارائه شده توسط MVC را به دست آورد، در حالی که از مزایای اتصال داده ها و چارچوب با اتصال داده ها تا حد امکان به مدل کاربردی خالص استفاده می کند. نتیجه این است که مدل و چارچوب تا آنجا که ممکن است عملیات را هدایت می کند، منطق برنامه را که مستقیماً نمایش را دستکاری می کند، حذف یا به حداقل می رساند.تفاوت MVC و MVVMاين نكته مدنظر هست كه MVVM یک نسخه شخصی‌سازی شده از MVC هست. هدف اصلی MVC جداسازی و تفکیک قسمت‌های بی‌ربط برنامه هست (Separation of Concerns). کنترلر توی MVC کنترل جریان اطلاعات بین مدل و ویو را به عهده دارد. توی MVC یک ویو می‌تواند به صورت مستقیم اطلاعات مدل را بخواند و نمایش دهد. در برنامه‌نویسی وب از الگوی MVC بیشتر برای قسمت بک‌اند استفاده میشود.در MVVM مدل و ویو هیچ شناختی از هم دیگر ندارند. ویو مدل برخلاف کنترلر MVC، یک کنترلگر نیست. بلکه نقش یک پل بین مدل و ویو را بر عهده دارد. یک رابط بین اطلاعات مدل و اطلاعات ویو. توسط تکنیکی به اسم Data Binding که با اون مدل و ویو می‌توانند بطور مستقیم با هم در ارتباط باشند. با Data Binding ویومدل، مدل و ویو بصورت خودکار و راحت از تغییرات با خبر میشن.Data Binding ویو مدل می‌تواند بزرگ‌ترین نقص MVVM باشد. به گفته سازنده‌ی این الگو تکنیک Data Binding می‌تواند مقدار زیاد از حافظه را اشغال کند و استفاده از ان برای عملیات ساده UI یک افراط هست. پروژه‌های بزرگی که از MVVM استفاده می‌کنند اجرای اولیه سنگینی دارند. برای همین از این الگو بیشتر برای برنامه‌های تک صفحه‌ای (Single Page Application) استفاده میشود.مزایای استفاده از الگوی MVVMاگر یک مدل پیاده‌سازی موجود وجود داشته باشد که منطق تجاری موجود را در بر بگیرد، تغییر آن می‌تواند دشوار یا خطرناک باشد. در این سناریو، view model به عنوان یک آداپتور برای کلاس‌های مدل عمل می‌کند و شما را قادر می‌سازد تا از ایجاد هرگونه تغییر عمده در کد مدل خودداری کنید.توسعه‌دهندگان می‌توانند بدون استفاده از view، آزمایش‌های واحد را برای مدل view و مدل ایجاد کنند. تست‌های واحد برای مدل view می‌توانند دقیقاً همان عملکردی را اعمال کنند که توسط view استفاده می‌شود.رابط کاربری برنامه را می توان بدون لمس کد دوباره طراحی کرد، مشروط بر اینکه نما به طور کامل در XAML پیاده سازی شود. بنابراین، یک نسخه جدید از view باید با مدل view موجود کار کند.طراحان و توسعه دهندگان می توانند به طور مستقل و همزمان بر روی اجزای خود در طول فرآیند توسعه کار کنند. طراحان می توانند روی نما تمرکز کنند، در حالی که توسعه دهندگان می توانند روی مدل view و اجزای مدل کار کنند.چارچوب های MVVM از قبل موجوداکنون که ما ایده‌ای داریم که MVVM چیست، لازم نیست چرخ را دوباره اختراع کنید. تعدادی چارچوب خارج از جعبه وجود دارد که MVVM را پیاده سازی می کند. بدون ترتیب خاصی:MVVM Light Toolkit: این یک جعبه ابزار بسیار محبوب است که حاوی پشتیبانی خارج از جعبه برای نمای پایه، دستورات، پیام‌رسانی و قالب‌های پروژه برای شروع است. از هر دو پروژه WPF و Silverlight پشتیبانی می کند.SilverlightFX: اهداف اعلام شده برای این فریم ورک عبارتند از: فعال کردن مشخصات اجمالی واسط های کاربر، امکان جداسازی آسان تر دیدگاه و کد، و ارائه یک چارچوب ناب.کالیبرن: Caliburn یک فریمورک محبوب viewmodel-first است که از WPF و Silverlight پشتیبانی می کند. با این حال، فراتر از MVVM، یک چارچوب کاربردی کامل است.n مسیر: یکی دیگر از چارچوب‌های MVVM، این کتابخانه برای «فرمان‌های معکوس» منحصربه‌فرد است که اجازه می‌دهد دستورات اتصال به رویدادها در view را انجام دهد، نه اینکه view به سادگی دستورات را به viewmodel ارسال کند.MicroModels: یک رویکرد بسیار ناب و سبک به MVVM.کامپوزیت WPF/Prism: علیرغم نام، این فریم ورک از WPF و Silverlight پشتیبانی می کند. در حالی که به طور مستقیم پیاده سازی های MVVM را ارائه نمی دهد، پشتیبانی و راهنمایی زیادی برای نوشتن برنامه های کاربردی از جمله دستورات، تجمع رویداد، مدیریت منطقه و موارد دیگر ارائه می دهد.اتصال View Models به Viewsبا استفاده از قابلیت Data Binding Xamarin.Forms می توان مدل های View را به View ها متصل کرد. روش‌های زیادی وجود دارد که می‌توان برای ساخت نماها و مشاهده مدل‌ها و مرتبط کردن آنها در زمان اجرا استفاده کرد. این رویکردها به دو دسته تقسیم می‌شوند که به‌عنوان ترکیب اول view و ترکیب اول دیدگاه مدل شناخته می‌شوند. انتخاب بین ترکیب view first و view model first ترکیب یک موضوع اولویت و پیچیدگی است. با این حال، همه رویکردها یک هدف مشترک دارند، و آن این است که view یک مدل view به ویژگی BindingContext آن اختصاص داده شود.با ترکیب دیدگاه اول، برنامه از نظر مفهومی از نماهایی تشکیل شده است که به مدل‌های نمایشی که به آن‌ها وابسته هستند متصل می‌شوند. مزیت اصلی این رویکرد این است که ساخت اپلیکیشن‌های با جفت آزاد و واحد قابل آزمایش را آسان می‌کند زیرا مدل‌های view هیچ وابستگی به خود نماها ندارند. همچنین درک ساختار برنامه با پیروی از ساختار بصری آن آسان است، به جای اینکه مجبور باشید اجرای کد را ردیابی کنید تا بفهمید کلاس ها چگونه ایجاد و مرتبط می شوند. علاوه بر این، نمای اولین ساخت‌وساز با سیستم ناوبری Xamarin.Forms که مسئول ساخت صفحات در هنگام پیمایش است، همسو می‌شود، که باعث می‌شود اولین ترکیب مدل view پیچیده و با پلتفرم ناهماهنگ شود.با ترکیب اول مدل view، برنامه از نظر مفهومی از مدل‌های view تشکیل شده است، با سرویسی که مسئول مکان یابی نمای یک مدل view است. ترکیب اول مدل View برای برخی از توسعه‌دهندگان طبیعی‌تر است، زیرا ایجاد نما را می‌توان انتزاع کرد و به آنها اجازه می‌دهد بر ساختار منطقی غیر UI برنامه تمرکز کنند. علاوه بر این، این امکان را فراهم می کند که مدل های view توسط سایر مدل های view ایجاد شوند. با این حال، این رویکرد اغلب پیچیده است و درک نحوه ایجاد و مرتبط کردن بخش‌های مختلف برنامه ممکن است دشوار شود.به روز رسانی نماها در پاسخ به تغییرات در مدل یا مدل نمای زیربناییهمه مدل‌های view و کلاس‌های مدل که برای یک view قابل دسترسی هستند باید رابط INotifyPropertyChanged را پیاده‌سازی کنند. پیاده‌سازی این رابط در یک مدل view یا کلاس مدل به کلاس اجازه می‌دهد تا اعلان‌های تغییر را برای کنترل‌های وابسته به داده در نما، زمانی که مقدار ویژگی اساسی تغییر می‌کند، ارائه دهد.برنامه ها باید برای استفاده صحیح از اعلان تغییر دارایی، با رعایت شرایط زیر طراحی شوند:در صورت تغییر ارزش دارایی عمومی، همیشه یک رویداد PropertyChanged را افزایش دهید. تصور نکنید که افزایش رویداد PropertyChanged به دلیل آگاهی از نحوه اتصال XAML نادیده گرفته می شود.همیشه یک رویداد PropertyChanged برای هر ویژگی محاسبه شده ای که مقادیر آن توسط سایر ویژگی ها در مدل view یا مدل استفاده می شود، افزایش می دهد.همیشه رویداد PropertyChanged را در پایان متدی که تغییر خاصیت ایجاد می‌کند، یا زمانی که شی در حالت امن است، بالا می‌رود. بالا بردن رویداد، عملیات را با فراخوانی همزمان کنترل کننده های رویداد قطع می کند. اگر این در وسط یک عملیات اتفاق بیفتد، ممکن است زمانی که شی در وضعیت ناامن و تا حدی به روز شده باشد، آن را در معرض توابع پاسخ به تماس قرار دهد. علاوه بر این، ممکن است تغییرات آبشاری توسط رویدادهای PropertyChanged فعال شوند. تغییرات آبشاری معمولاً به تکمیل به‌روزرسانی‌ها نیاز دارند تا قبل از اینکه تغییر آبشاری اجرا شود.اگر ویژگی تغییر نکرد، هرگز یک رویداد PropertyChanged را مطرح نکنید. این بدان معناست که قبل از بالا بردن رویداد PropertyChanged باید مقادیر قدیمی و جدید را با هم مقایسه کنید.اگر یک ویژگی را مقداردهی اولیه می کنید، هرگز رویداد PropertyChanged را در طول سازنده یک مدل view بالا نمی برید. کنترل‌های محدود به داده در نما برای دریافت اعلان‌های تغییر در این مرحله مشترک نخواهند شد.هرگز بیش از یک رویداد PropertyChanged با آرگومان نام ویژگی یکسان در یک فراخوانی همزمان یک متد عمومی یک کلاس افزایش نمی‌یابد. به عنوان مثال، با توجه به یک ویژگی NumberOfItems که ذخیره پشتیبان آن فیلد _numberOfItems است، اگر متدی در طول اجرای یک حلقه، _numberOfItems را پنجاه بار افزایش دهد، پس از اتمام کار، فقط باید یک بار اعلان تغییر ویژگی را در ویژگی NumberOfItems افزایش دهد. برای روش‌های ناهمزمان، رویداد PropertyChanged را برای یک نام مشخصه در هر بخش همزمان از یک زنجیره ادامه ناهمزمان بالا ببرید.تعامل رابط کاربری با استفاده از دستورات و رفتارهادر برنامه های تلفن همراه، اقدامات معمولاً در پاسخ به یک اقدام کاربر، مانند کلیک روی دکمه، فراخوانی می شوند که می تواند با ایجاد یک کنترل کننده رویداد در فایل پشت کد اجرا شود. با این حال، در الگوی MVVM، مسئولیت اجرای عمل بر عهده مدل view است و باید از قرار دادن کد در کد پشت خودداری شود.دستورات روشی مناسب برای نمایش اقداماتی ارائه می‌دهند که می‌توانند به کنترل‌های موجود در رابط کاربری متصل شوند. آنها کدی را که عمل را اجرا می‌کند، محصور می‌کنند و کمک می‌کنند تا آن را از نمایش بصری‌اش در نما جدا نگه دارند. Xamarin.Forms شامل کنترل‌هایی است که می‌توانند به صورت اعلانی به یک فرمان متصل شوند و این کنترل‌ها هنگام تعامل کاربر با کنترل، فرمان را فراخوانی می‌کنند.رفتارها همچنین به کنترل‌ها اجازه می‌دهند تا به طور آشکار به یک فرمان متصل شوند. با این حال، رفتارها را می توان برای فراخوانی عملی استفاده کرد که با طیف وسیعی از رویدادهای مطرح شده توسط یک کنترل مرتبط است. بنابراین، رفتارها به بسیاری از سناریوهای مشابه کنترل‌های دارای فرمان پاسخ می‌دهند، در حالی که انعطاف‌پذیری و کنترل بیشتری را ارائه می‌کنند. علاوه بر این، رفتارها همچنین می توانند برای مرتبط کردن اشیاء یا روش های فرمان با کنترل هایی استفاده شوند که به طور خاص برای تعامل با دستورات طراحی نشده اند.اجرای رفتارهارفتارها به کنترل‌های UI اجازه می‌دهند بدون نیاز به زیر کلاس‌بندی، عملکردها را به آن‌ها اضافه کنند. در عوض، عملکرد در یک کلاس رفتار پیاده‌سازی می‌شود و به کنترل متصل می‌شود که گویی بخشی از خود کنترل است. رفتارها شما را قادر می سازند کدی را پیاده سازی کنید که معمولاً باید به صورت کد پشتی بنویسید، زیرا مستقیماً با API کنترل در تعامل است، به گونه ای که می تواند به طور خلاصه به کنترل متصل شود و برای استفاده مجدد در بیش از یک نما یا برنامه در زمینه MVVM، رفتارها یک رویکرد مفید برای اتصال کنترل ها به دستورات هستند.رفتاری که از طریق ویژگی های متصل به یک کنترل متصل می شود، به عنوان رفتار پیوست شناخته می شود. سپس رفتار می تواند از API آشکار عنصری که به آن متصل است برای افزودن عملکرد به آن کنترل یا سایر کنترل ها در درخت بصری نما استفاده کنند. نتيجه گيريالگوها یک مبحث ثابت و تغییر ناپذیر نیستن. می‌توانیم انها را شخصی‌سازی و یا با الگوهای دیگر مخلوط کنیم. همانطور که فریم‌ورکی مثل Vue.js فقط قسمتی از این الگو را پیاده‌سازی کرده است. یک الگو برايش فرقی نمی‌کند که از چه زبان و چه فریم‌ورکی استفاده میشود. الگوها فقط راه حل‌های عمومی برای مشکلات عمومی ارائه میدهند. استفاده از هر الگويي باید با دقت صورت گيرد. یک الگو می‌تواند نظم فوق‌العاده‌ای به یک برنامه بدهد و همچنین یک برنامه‌ی ساده را دچار پیچیدگی‌های غیر منطقی کند.منابع:1- https://docs.microsoft.com/en-us/xamarin/xamarin-forms/enterprise-application-patterns/mvvm2- https://ditty.ir/posts/mvvm-pattern/XpAPJ3- https://whatis.techtarget.com/definition/Model-View-ViewModel#:~:text=Model%2DView%2DViewModel%20(MVVM)%20is%20a%20software%20design,logic%20and%20user%20interface%20controls.&amp;text=The%20pattern%20is%20often%20used,)%2C%20which%20runs%20on%20Microsoft&#x27;s%20.4- https://www.wintellect.com/model-view-viewmodel-mvvm-explained/5- https://www.raywenderlich.com/34-design-patterns-by-tutorials-mvvm6- https://docs.microsoft.com/en-us/xamarin/xamarin-forms/enterprise-application-patterns/mvvm7- https://books.zkoss.org/zk-mvvm-book/8.0/introduction_of_mvvm.html8- https://www.tutorialspoint.com/mvvm/index.htmlاین مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است.</description>
                <category>faezeh montazerin</category>
                <author>faezeh montazerin</author>
                <pubDate>Mon, 29 Nov 2021 00:43:20 +0330</pubDate>
            </item>
                    <item>
                <title>مدل C4 برای تجسم معماری نرم افزار</title>
                <link>https://virgool.io/@faezehmonta1995/%D9%85%D8%AF%D9%84-c4-%D8%A8%D8%B1%D8%A7%DB%8C-%D8%AA%D8%AC%D8%B3%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-axk7hbmcbs0h</link>
                <description>معرفياز کسی در صنعت ساختمان بخواهید که به صورت بصری با معماری یک ساختمان ارتباط برقرار کند و نقشه های سایت، پلان های طبقه، نماهای ارتفاعی، نماهای مقطعی و نقشه های جزئیات به شما ارائه می شود. در مقابل، از یک توسعه‌دهنده نرم‌افزار بخواهید که معماری نرم‌افزار یک سیستم نرم‌افزاری را با استفاده از نمودارها به اشتراک بگذارد و احتمالاً با یک آشفتگی از جعبه‌ها و خطوط مواجه خواهید شد... نمادهای ناسازگار (کدگذاری رنگ، اشکال، سبک‌های خط و غیره)، نام‌گذاری مبهم. ، روابط بدون برچسب، اصطلاحات عمومی، انتخاب های فناوری از دست رفته، انتزاعات مختلط و غیره.به عنوان یک صنعت، ما زبان مدلسازی یکپارچه (UML)، ArchiMate و SysML را داریم، اما پرسیدن اینکه آیا اینها راه موثری برای برقراری ارتباط با معماری نرم‌افزار ارائه می‌دهند اغلب بی‌ربط است، زیرا بسیاری از تیم‌ها قبلاً آنها را به نفع جعبه‌های بسیار ساده‌تر کنار گذاشته‌اند. خطوط&quot; نمودارها کنار گذاشتن این زبان‌های مدل‌سازی یک چیز است، اما شاید در رقابت برای چابکی، بسیاری از تیم‌های توسعه نرم‌افزار توانایی برقراری ارتباط بصری را از دست داده‌اند.یک مدل C4 معماری نرم افزار را در سطوح مختلف جزئیات توصیف یا تعریف می کند. مدل C4 مجموعه ای از نمودارها است که زمینه، کانتینرها، اجزا و کد یک نرم افزار را نشان می دهد. سلسله مراتب این نمودارها به مخاطبان مختلف اجازه می دهد تا معماری نرم افزار را در سطح جزئیات مورد نیاز خود درک کنند.می‌توانید از یک مدل C4 برای میکروسرویس‌ها استفاده کنید، تا نشان دهید که چگونه می‌خواهید یک سیستم بسازید، یا یک سیستم موجود را توصیف کنید. نمودارهای C4 یک چارچوب جایگزین و ساده شده در مقایسه با نمودارهای UML هستند و می توانند چندین سیستم را توصیف کنند، برخلاف نمودارهای معماری AWS خاص، نمودارهای معماری GCP یا نمودارهای معماری Azure.مدل C4 توسط نویسنده Software Architecture for Developers، Simon Brown ساخته شده است.چهار نوع مدل C4 وجود دارد که هر کدام برای مخاطبان متفاوتی است و دارای سطح متفاوتی از جزئیات است. اینها زمینه، ظرف، اجزا و نمودارهای کد هستند که مدل معماری نرم افزار شما را می سازند.4 سطح از C4سطح 1: نمودارهای زمینهنمودارهای زمینه کلی ترین توصیفی هستند که سیستم شما چه کاری انجام می دهد، چه کسی از آن استفاده خواهد کرد و با چه سیستم های دیگری تعامل خواهد داشت. یک نمودار زمینه به شما کمک می کند تا محدوده پروژه خود را توصیف کنید و به شما کمک می کند تا مشخص کنید کاربر چه کسی است و چه مشکلی را می خواهید حل کنید.سطح 2: نمودارهای کانتینرنمودار ظرف اولین گام را برای توصیف سیستم نرم افزاری برداشته و API ها، برنامه های کاربردی، پایگاه های داده و میکروسرویس هایی را که سیستم از آنها استفاده خواهد کرد نشان می دهد. هر یک از این برنامه ها یا خدمات با یک ظرف نمایش داده می شوند و تعاملات بین آنها در سطح بالایی نشان داده می شود.سطح 3: نمودارهای مؤلفهیک گام عمیق‌تر از نمودار کانتینر، نمودار مؤلفه گروه‌های کد را در یک کانتینر به تفصیل شرح می‌دهد. این مؤلفه ها انتزاعی از پایگاه کد شما را نشان می دهند.این نوع نمودار با نمودار مؤلفه‌های UML قابل مقایسه است، اما برای ایجاد نمودار معماری نرم‌افزار، از مجموعه‌ای از «قوانین» کمتر دقیق‌تر پیروی می‌کند.سطح 4: نمایش کد با نمودارهای کلاسآخرین سطح به جزئیات زیادی نیاز دارد تا نشان دهد چگونه کد یک جزء واحد در واقع پیاده سازی می شود. برای انجام این کار، می‌خواهید یک نمودار کلاس UML یا نمودار رابطه موجودیت بسازید که مؤلفه را توصیف می‌کند.سطوح مختلف C4برای ایجاد این نقشه‌ها از کد شما، ابتدا به مجموعه‌ای از انتزاعات مشترک نیاز داریم تا زبانی فراگیر ایجاد کنیم که بتوانیم از آن برای توصیف ساختار ایستا یک سیستم نرم‌افزاری استفاده کنیم. مدل C4 ساختارهای ایستا یک سیستم نرم افزاری را از نظر کانتینرها، اجزا و کد در نظر می گیرد. و مردم از سیستم های نرم افزاری که ما می سازیم استفاده می کنند.یک سیستم نرم افزاری از یک یا چند کانتینر (برنامه های کاربردی وب، برنامه های موبایل، برنامه های کاربردی دسکتاپ، پایگاه های داده، سیستم های فایل و غیره) تشکیل شده است که هر کدام شامل یک یا چند جزء است که به نوبه خود توسط یک یا چند عنصر کد پیاده سازی می شوند. به عنوان مثال کلاس ها، رابط ها، اشیاء، توابع و غیره).پیوند نمودار چشم انداز سیستممدل C4 نمای ایستا از یک سیستم نرم افزاری واحد را ارائه می دهد، اما در دنیای واقعی، سیستم های نرم افزاری هرگز در انزوا زندگی نمی کنند. به همین دلیل، و به ویژه اگر مسئولیت مجموعه ای از سیستم های نرم افزاری را بر عهده دارید، اغلب مفید است که بفهمید چگونه همه این سیستم های نرم افزاری با هم در محدوده یک سازمان قرار می گیرند. برای انجام این کار، به سادگی نمودار دیگری را اضافه کنید که &quot;در بالای&quot; نمودارهای C4 قرار دارد تا چشم انداز سیستم را از منظر فناوری اطلاعات نشان دهد. مانند نمودار زمینه سیستم، این نمودار می تواند مرزهای سازمانی، کاربران داخلی/خارجی و سیستم های داخلی/خارجی را نشان دهد.اساساً این یک نقشه سطح بالا از سیستم‌های نرم‌افزاری در سطح سازمانی است که برای هر سیستم نرم‌افزاری مورد علاقه، یک بررسی C4 دارد. از منظر عملی، نمودار چشم انداز سیستم در واقع فقط یک نمودار زمینه سیستم بدون تمرکز خاص بر روی یک سیستم نرم افزاری خاص است.پیوند دیاگرام پویایک نمودار پویا زمانی می‌تواند مفید باشد که می‌خواهید نشان دهید چگونه عناصر در یک مدل استاتیک در زمان اجرا برای پیاده‌سازی یک داستان کاربر، استفاده از کیس، ویژگی و غیره با یکدیگر همکاری می‌کنند. نمودار همکاری&quot;). این شبیه به یک نمودار توالی UML است، اگرچه امکان آرایش آزاد عناصر نمودار با فعل و انفعالات شماره گذاری شده را برای نشان دادن ترتیب می دهد.پيوند نمودار استقراریک نمودار استقرار به شما امکان می دهد نشان دهید که چگونه سیستم های نرم افزاری و/یا کانتینرها در مدل استاتیک به زیرساخت نگاشت می شوند. این نمودار استقرار بر اساس یک نمودار استقرار UML است، اگرچه برای نشان دادن نگاشت بین کانتینرها و گره های استقرار کمی ساده شده است. یک گره استقرار چیزی شبیه زیرساخت فیزیکی (به عنوان مثال یک سرور فیزیکی یا دستگاه)، زیرساخت مجازی سازی شده (مانند IaaS، PaaS، یک ماشین مجازی)، زیرساخت کانتینری (مانند یک ظرف Docker)، یک محیط اجرا (به عنوان مثال یک سرور پایگاه داده، Java EE) است. سرور وب/برنامه، Microsoft IIS) و غیره. گره های استقرار را می توان تودرتو کرد.همچنین ممکن است بخواهید گره های زیرساختی مانند سرویس های DNS، متعادل کننده های بار، فایروال ها و غیره را شامل کنید.اگرچه نمودارهای مثال بالا با استفاده از نماد &quot;جعبه ها و خطوط&quot; ایجاد شده اند، نمودارهای اصلی را می توان با استفاده از UML با استفاده مناسب از بسته ها، مؤلفه ها و کلیشه ها نشان داد. نمودارهای UML به دست آمده معمولاً فاقد همان درجه متن توصیفی هستند، زیرا افزودن چنین متنی با برخی از ابزارهای UML ممکن نیست (یا آسان است).و در اینجا چند توصیه در رابطه با نمادگذاری وجود دارد.نمودارهاهر نمودار باید عنوانی داشته باشد که نوع و محدوده نمودار را توصیف کند (به عنوان مثال &quot;نمودار زمینه سیستم برای سیستم نرم افزار من&quot;).هر نمودار باید دارای یک کلید/افسانه باشد که نماد مورد استفاده را توضیح دهد (مانند اشکال، رنگ‌ها، سبک‌های حاشیه، انواع خطوط، سر فلش‌ها و غیره).کلمات اختصاری و اختصارات (کسب و کار/دامنه یا فناوری) باید برای همه مخاطبان قابل درک باشد یا در کلید/افسانه نمودار توضیح داده شود.عناصرنوع هر عنصر باید به صراحت مشخص شود (به عنوان مثال شخص، سیستم نرم افزار، ظرف یا جزء).هر عنصر باید توصیف کوتاهی داشته باشد، تا دیدگاهی &quot;در یک نگاه&quot; از مسئولیت های کلیدی ارائه شود.هر کانتینر و جزء باید دارای فناوری مشخص شده باشد.روابطهر خط باید نشان دهنده یک رابطه یک طرفه باشد.هر خط باید برچسب گذاری شود، برچسب با جهت و هدف رابطه (مثلاً وابستگی یا جریان داده) سازگار باشد. سعی کنید تا آنجا که ممکن است با برچسب مشخص باشید، به طور ایده آل از کلمات منفرد مانند &quot;استفاده می کند&quot; اجتناب کنید.روابط بین کانتینرها (معمولاً این ارتباطات بین فرآیندی را نشان می دهد) باید دارای یک فناوری/پروتکل باشد که به صراحت برچسب گذاری شده باشد.خلاصهمدل C4 به‌عنوان راهی برای کمک به تیم‌های توسعه نرم‌افزار برای توصیف و برقراری ارتباط معماری نرم‌افزار، هم در طول جلسات طراحی اولیه و هم هنگام مستندسازی گذشته‌نگر یک پایگاه کد موجود، ایجاد شد. این راهی است برای ایجاد نقشه هایی از کد شما، در سطوح مختلف جزئیات، به همان روشی که از چیزی مانند نقشه های گوگل برای بزرگنمایی و بزرگنمایی منطقه ای که به آن علاقه دارید استفاده می کنید.اگرچه هدف اصلی آن معماران و توسعه‌دهندگان نرم‌افزار است، مدل C4 راهی را برای تیم‌های توسعه نرم‌افزار فراهم می‌کند تا به طور کارآمد و مؤثر معماری نرم‌افزار خود را در سطوح مختلف از جزئیات، گفتن داستان‌های مختلف برای انواع مختلف مخاطب، هنگام انجام طراحی قبلی یا گذشته‌نگر، به اشتراک بگذارند. مدل C4 یک رویکرد &quot;اول انتزاعی&quot; برای نمودارسازی معماری نرم افزار است که بر اساس انتزاعیاتی است که نشان می دهد معماران و توسعه دهندگان نرم افزار چگونه در مورد نرم افزار فکر می کنند و می سازند. مجموعه کوچکی از انتزاعات و انواع نمودارها، یادگیری و استفاده از مدل C4 را آسان می کند. لطفاً توجه داشته باشید که نیازی به استفاده از هر 4 سطح نمودار نیست. فقط آنهایی که ارزش اضافه می کنند - نمودارهای System Context و Container برای بسیاری از تیم های توسعه نرم افزار کافی است.منابع:https://c4model.com/https://www.gliffy.com/blog/c4-modelhttps://www.youtube.com/watch?v=x2-rSnhpw0ghttps://www.youtube.com/watch?v=Ym9nhVZs89ohttps://en.wikipedia.org/wiki/C4_modelhttps://engineering.linecorp.com/en/blog/diagramming-software-architecture-using-c4-model-and-c4-plantuml/«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»</description>
                <category>faezeh montazerin</category>
                <author>faezeh montazerin</author>
                <pubDate>Sat, 20 Nov 2021 23:33:32 +0330</pubDate>
            </item>
            </channel>
</rss>