https://virgool.io/feed/@phateme_mirzaie fa 2026-04-14 21:42:52 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@phateme_mirzaie https://virgool.io/@phateme_mirzaie/assignment01-%D8%AF%D8%B1%D8%B3-%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-zzlezghuprof Modular Monolithicالگوی ماژولار مونولیتیک یا همون ماژرلار مونولوتیک یه روش طراحی نرم‌افزاره که برنامه رو به قسمت‌های کوچیک تقسیم می‌کنه. هر قسمت، یه ماژول جداگونه است و می‌تونه به صورت مستقل توسعه پیدا کنه و اجرا بشه. این روش باعث میشه که تغییرات توی هر قسمت به صورت جداگانه اعمال بشه و به بخش‌های دیگه وابستگی نداشته باشه. حتی تیم‌های مختلف هم می‌تونن روی هر کدام از این ماژول‌ها کار کنن. این باعث میشه وابستگی‌ها کمتر بشن و توسعه پروژه راحت‌تر بشه. حتی هر ماژول می‌تونه توی یه پروژه دیگه هم استفاده بشه، مثلاً ماژول یوزر و ...این روش باعث افزایش قابلیت استفاده مجدد از کد توسعه یافته، سازماندهی بهتر وابستگی‌های کد و افزایش قابلیت مشاهده و دسترسی به کد میشه. این الگو با میکروسرویس‌ها فرق داره، چون در میکروسرویس‌ها هر قسمت از برنامه می‌تونه به صورت جداگانه اجرا بشه.الگوی ماژولار مونولیتیک می‌تونه گزینه مناسبی برای سازمان‌هایی باشه که نمی‌توانند یا نمی‌خواهند به میکروسرویس‌ها تغییر بدن. این روش به آن‌ها کمک می‌کنه که یک سطح استقلال رو حفظ کنن، که در صورت نیاز به راه‌اندازی میکروسرویس‌ها مفید باشه.مثال‌های خوب از برنامه‌های ماژولار مونولیتیک، فروشگاه آنلاین یا برنامه مالی شخصی هستن. هر قسمت از این برنامه‌ها، به عنوان یک ماژول طراحی شده و مستقل از بقیه قسمت‌ها قابل توسعه و تست هستن. اما برنامه به صورت یک واحد قابل اجرا است و از یک پایگاه داده مشترک استفاده می‌کند.****AWSAWS یا سرویس‌های وب آمازون یک پلتفرم ابریه که بیش از 200 خدمت مختلف داره و در سراسر جهان استفاده میشه. با استفاده از AWS، میتونی برنامه‌هاتو تو یه محیط انعطاف‌پذیر، قابل اعتماد، امن و با کارایی بالا اجرا کنی. همچنین، میتونی از تکنولوژی‌های مختلفی مثل محاسبه، ذخیره‌سازی، پایگاه داده، هوش مصنوعی و تحلیل داده استفاده کنی.AWS دارای یه انجمن بزرگ از مشتریان و شرکای تجاریه که شامل میلیون‌ها کاربر فعال و ده‌ها هزار شرکت مشاوره و نرم‌افزاری میشه. این انجمن بهت کمک میکنه تا از تجربه، دانش و ابتکارات دیگران بهره ببری و راه‌حل‌های مناسب برای نیازات پیدا کنی.AWS همچنین سرعت بالایی در نوآوری داره و به طور مداوم خدمات و ویژگی‌های جدیدی رو ارائه میده. برای مثال، AWS در سال 2014 مفهوم برنامه‌نویسی بدون سرور رو با راه‌اندازی AWS Lambda معرفی کرد. همچنین با ساخت Amazon SageMaker، یک سرویس یادگیری ماشین کاملاً مدیریت شده رو فراهم کرد.به‌طورکلی، AWS شامل بیش از 100 خدمت ممتازه. قبل از آنکه شما برای دسترسی به هر چیزی به آن متصل شوید، باید بدانید که AWS در کار کردن با یک مشاور انتقال دیجیتال بهترین خواهد بود.AWS دسته‌بندی‌های اصلی محصولات خود را در زیر بیان کرده است:1. محاسبات: Elastic Compute Cloud (EC2) 2. ذخیره‌سازی: Simple Storage Service (S3)3. مدیریت داده: Amazon RDS, DynamoDB, Redshift4. شبکه: Virtual Private Cloud (VPC), Route 53علاوه بر این، AWS به شما امکان میده تا از ارتباط مستقیم بین cloud AWS و مرکز داده on-site استفاده کنید. همچنین، با سرویس‌ها و ابزارهای مختلف، AWS به شما کمک میکنه تا داده‌هات، پایگاه‌های دادت و برنامه‌ات رو به cloud منتقل کنید. AWS همچنین ابزارهای مانیتورینگ و مدیریت رو فراهم کرده تا به تیم‌های IT کمک کنه که سرویس‌های cloud خود رو بهینه‌سازی کنن.****API-first Approach API یعنی رابط برنامه نویسی کاربردی. یعنی یه چیزی شبیه به راهی که برنامه‌ها ازش استفاده می‌کنند تا با هم صحبت کنند و اطلاعات رو با هم به اشتراک بذارن. وقتی تو یه برنامه بلیط هواپیما رزرو می‌کنی، اون برنامه از یه راهی برای ارسال درخواستت به سیستم رزرواسیون استفاده می‌کنه. بعد اون سیستم از یه جور دیگه از اون API برای چک کردن اطلاعات پروازت با یه سیستم دیگه استفاده می‌کنه. در نهایت، برای پرداخت هم از یه API دیگه برای اتصال به سیستم پرداخت استفاده می‌شه. در واقع این APIها به برنامه‌های مختلف این امکان رو می‌دن که با هم ارتباط برقرار کنن و اطلاعات رو منتقل کنن.توی دنیای نرم‌افزار، مردم از APIها برای چیزهای مختلف استفاده می‌کنن. مثلاً وقتی برنامه‌نویسا می‌خوان از ویژگی‌های یه زبان برنامه‌نویسی خاص استفاده کنن، از API زبان اون استفاده می‌کنن. یا وقتی می‌خوان از کد‌های آماده در کتابخانه‌های نرم‌افزاری استفاده کنن، از API کتابخونه استفاده می‌کنن.روش API-first Approach یعنی اولین اولویت طراحی و توسعه API است. به این معنی که قبل از هر چیزی، خود API طراحی و ساخته می‌شه. این باعث میشه که برنامه‌ها بتونن به راحتی با هم ارتباط برقرار کنن و از APIهای دیگه که ارائه شده، استفاده کنن. روش API-first Approach مزایای زیادی داره. برای مثال، باعث میشه که تیم‌های توسعه بتونن به صورت موازی و مستقل روی APIهای مختلف کار کنن. این کمک می‌کنه که APIها قبل از نوشته شدن کد، آزمایش بشن. این روش همچنین باعث میشه که هزینه‌های توسعه کمتر بشه و بیشتر مشکلات قبل از نوشتن کد حل بشن.در این روش، API به صورت مرحله به مرحله طراحی و ارتقا می‌پذیره:‌ تعریف قرارداد API: در این مرحله، خصوصیات و ویژگی‌های API مشخص می‌شن؛ مثلاً چه نوع داده‌هایی می‌تونه رد و بدل بشه، یا چگونه می‌تونه ارتباط برقرار کنه و از چه پروتکل‌هایی استفاده کنه. این مرحله اهمیت بسیاری داره، چون از اینجا استفاده می‌شه تا اطمینان حاصل کرد که API به شکل مورد نیاز و مطابق با استفاده‌های برنامه‌های دیگه طراحی شده.• آزمایش API : بعد از تعریف API، باید اون رو آزمایش کرد. این کار به تیم‌ها کمک می‌کنه تا مطمئن بشن که API عملکرد درستی داره و با سایر APIها سازگاره.• مستندسازی API : API باید به شکل شفافی برای کاربران و توسعه‌دهندگان مستند شود. مستندسازی که شامل هدف، نحوه استفاده، محدودیت‌ها و نمونه‌های کد است، باعث می‌شه استفاده از API برای بقیه راحت‌تر باشه.• انتشار API : بعد از اطمینان از کارکرد صحیح API و مستندسازی، مرحله بعدی انتشارشه. API به صورت عمومی یا خصوصی منتشر می‌شه تا بقیه بتونن ازش استفاده کنن.• بهبود API : این مرحله همیشه در جریانه! API بر اساس بازخورد کاربران و توسعه‌دهندگان بهبود می‌بینه. افزودن ویژگی‌های جدید، رفع اشکالات و بهبود عملکرد و امنیت API از جمله تغییراتی هستن که ممکنه در این مرحله صورت بگیره.این روش باعث میشه که از ابتدا تا انتها، توسعه براساس API طراحی بشه و این امکان رو می‌ده که برنامه‌ها و خدمات مختلف با هم ارتباط داشته باشن و از هم استفاده کنن.****NoSQL DatabasesNoSQL یا پایگاه داده‌های غیر رابطه‌ای که از ساختارهای دیگر به جای جداول برای ذخیره و پرس‌وجوی داده‌ها استفاده می‌کنند. این نوع پایگاه داده‌ها، به جای استفاده از ساختارهای جدولی مانند پایگاه‌های داده رابطه‌ای یا SQL، از ساختارهایی مانند اسناد، کلید-مقدار، ستونی یا گرافی برای ذخیره اطلاعات استفاده می‌کنند. دلایل استفاده از NoSQL برای شرکت‌ها می‌تونه مختلف باشه: مثلاً برای مقیاس‌پذیری بیشتر و توزیع داده‌ها روی چندین سرور، انعطاف‌پذیری در ساختار داده‌ها، یا سرعت بالا در ذخیره و پرس و جو کردن داده‌ها.مراحل طراحی و توسعه پایگاه داده NoSQL هم ممکنه بر اساس نیازهای هر پروژه متفاوت باشن. مثلاً باید مدل داده و ساختار داده‌ای که می‌خوایم استفاده کنیم رو انتخاب کنیم، سپس پایگاه داده رو ایجاد و پیکربندی کنیم و بعدش آزمایش و مستندسازیش کنیم. در نهایت هم می‌تونیم اون رو منتشر کنیم تا بقیه بتونن استفاده کنن.****Serverless Architectureیک روش برنامه‌نویسی ت ابریه که به برنامه‌نویسا این اجازه رو می‌ده که بدون دغدغه‌ی مدیریت سرور، برنامه‌هاشون رو بنویسن و اجرا کنن. تو این روش، ابر کامپیوتری مسئولیت سرورها و دیتابیس‌ها رو برای اجرای برنامه‌ها به عهده می‌گیره. برنامه‌نویسا می‌تونن کدهاشون رو در قالب قطعه‌های کوچیک (کانتینر) بنویسن و اجرا کنن. برنامه‌ها بصورت خودکار وقتی نیاز باشه، می‌شن وقتی نیاز نباشه، خاموش می‌شن.Serverless Architecture چند نوع مختلف داره که از نظر اجراشون فرق می‌کنن. دو نوع مهمشون:• Backend-as-a-Service (BaaS): که به برنامه‌نویسا امکان می‌دهد از سرویس‌هایی که توسط ابر کامپیوتر ارائه می‌شه، استفاده کنن. مثلا سرویس‌های احراز هویت، پیام‌رسانی، و غیره. اینجور سرویس‌ها به برنامه‌نویسا کمک می‌کنن که بدون نوشتن کد زیاد، بخش‌هایی از برنامه‌هاشون رو ایجاد کنن.• Function-as-a-Service (FaaS): که به برنامه‌نویسا این اجازه رو می‌ده که توابع مختلفی رو بنویسن و استقرار بدن. هر تابع وقتی نیاز باشه، اجرا می‌شه برای وقایع خاص مثل یه درخواست اینترنتی. تامین‌کننده ابر کامپیوتری مسئول اجرای توابع هست و منابع مورد نیاز رو بهشون می‌ده.Serverless Architecture مزایا و معایبی داره که بسته به نوع پروژه، ممکنه تغییر کنن. برخی مزایایش:• کاهش هزینه: به برنامه‌نویسا اجازه می‌ده که فقط وقتی که برنامه‌هاشون در حال اجرا هستن، پرداخت کنن. این باعث کاهش هزینه‌های مربوط به مدیریت سرورها می‌شه.• افزایش بهره‌وری: برنامه‌نویسا می‌تونن تمرکزشون رو بر روی نوشتن کد برنامه‌هاشون بزارن و نگران مسائل سرور نباشن.• افزایش مقیاس‌پذیری: برنامه‌ها به صورت خودکار وقتی که نیاز باشه، می‌تونن مقیاس‌پذیر باشن و این باعث افزایش قابلیت دسترسی و عملکرد برنامه‌ها می‌شه.معایبش هم می‌تونه افزایش پیچیدگی و کاهش کنترل برای برنامه‌نویسا باشه، وقتی که از چندین سرویس بدون سرور استفاده می‌کنن.****Domain Driven DesignDomain Driven Design یا DDD یک روش طراحی نرم افزاره که باهاش می‌تونی نحوه‌ی ساختار داده‌ها و زبان کدت رو با دامنه کاری که بهش مربوطه هماهنگ کنی. این دامنه مربوط به موضوع یا کاری هست که نرم افزارت براش ساخته شده.به عنوان مثال، اگه نرم افزارت درخواست وام‌ها رو پردازش می‌کنه، ممکنه کلاس‌ها و متدهایی مثل "درخواست وام"، "مشتریان" و "پذیرش پیشنهاد" و "انصراف" داشته باشه. در DDD، یه مدل دامنه می‌سازی که یه سیستم از مفاهیم مهم دامنه رو توصیف می‌کنه و می‌تونه بهت کمک کنه مشکلات مربوط به اون دامنه رو حل کنی.مدل دامنه شامل منطق کاریه که واقعیت‌های مربوط به محصول رو به کد مرتبط می‌کنه. هدف اصلی DDD اینه که یه زبان مشترک بین کارشناسان دامنه، کاربران و توسعه‌دهنده‌ها پیدا کنه که باهاش می‌شه نیازهای سیستم رو توصیف کرد.از مثال‌هایی مثل پروژه library در GitHub (https://github.com/ddd-by-examples/library)می‌شه استفاده کرد که یه نمونه خوب از اجزای مختلف DDD رو نشون می‌ده.DDD مزایای زیادی داره مثل ارتباط بهتر بین افراد، انعطاف‌پذیری بیشتر در مقابل تغییرات، و قابلیت نگهداری بهتر. اما همراه با این مزایا، معایبی مثل پیچیدگی بالا، هزینه بیشتر و محدودیت در استفاده در برخی پروژه‌ها هم داره.****Hexagonal Architectureمعماری هگزاگونال یا Hexagonal Architecture، یک الگوی طراحی نرم‌افزاره که می‌خواد قسمت مهم و اصلی نرم‌افزار (همون قلبش) رو از چیزای خارجی جدا کنه. تو این الگو، ورودی‌ها و خروجی‌ها در کنارهای طراحی قرار می‌گیرن و با استفاده از درگاه‌ها و مبدل‌ها با بیرون نرم‌افزار ارتباط برقرار می‌کنن. این کار باعث می‌شه اجزای نرم‌افزار، قابل تعویض و آزمون بشن.از جلوه‌های خوب استفاده از معماری هگزاگونال، اینه که می‌تونی کدهایت رو آسون‌تر تست کنی. می‌تونی برای تست، جایگزین‌هایی برای بخش‌های واقعی استفاده کنی که باعث میشه تست‌ها قوی‌تر و پایدارتر بشن.این معماری یه گام جلوتر از معماری لایه‌ای هست. در این الگو، حتی می‌تونی رابط کاربری رو هم عوض کنی. این الگو توسط آلیستر کاکبرن در سال ۲۰۰۵ معرفی شده. اصلی‌ترین ایده اون از کتاب Object Design: Roles, Responsibilities, and Collaborations برداشته شده. در این کتاب، نویسندگان به درگاه‌ها و مبدل‌ها به عنوانInterfacers اشاره کردن که نقش ارتباط اجزای نرم‌افزار رو نشون میدن.تو معماری هگزاگونال، سیستمت رو به چند قسمت کوچیک تقسیم می‌کنی که می‌شه جایگزین‌شون کرد و ارتباطشون کمه. مثلاً هسته نرم‌افزار، پایگاه داده، رابط کاربری و اجزای تست. این الگو یه جایگزین برای معماری لایه‌ای هست. هر قسمت از طریق چندین درگاه قابل دسترسیه. این درگاه‌ها و پروتکل‌ها یه رابطی انتزاعی تعریف می‌کنن که می‌شه با هر روش مناسبی (مثلاً فراخوانی متد، فراخوانی رویه از راه دور و یا وب سرویس) پیاده‌سازیشون کرد.معماری هگزاگونال به کمک درگاه‌ها و مبدل‌ها ارتباط جزء‌ها رو با دنیای خارجی مدیریت می‌کنه. این مبدل‌ها نقش تعامل بین جزء‌های نرم‌افزار و بیرون رو ایفا می‌کنن. ممکنه برای هر درگاه چندین مبدل وجود داشته باشه که به عنوان مثال، یه جایی داده می‌تونه از طریق رابط کاربری یا رابط خط فرمان و یا از طریق تست تولید بشه.یک مقاله با نام Hexagonal architecture tutorial: Build maintainable web apps وجود داره که بهت یاد می‌ده چطور یه وب اپلیکیشن با استفاده از معماری هگزاگونال و زبان پایتون بسازی. تو این مقاله نحوه تعریف درگاه‌ها، مبدل‌ها و مدل دامنه رو نشون میده.****Event Sourcingیک روش ثبت تغییرات در داده‌های یک کسب و کار است. به جای اینکه تنها وضعیت فعلی داده‌ها را نگه دارد، هر تغییر در داده‌ها به عنوان یک رویداد ثبت می‌شود. مانند یک لیست که هر عملیاتی را ذخیره می‌کند. این رویدادها نشان‌دهنده تغییراتی در داده‌ها هستند، مثلاً افزودن یک مورد به یک سفارش. این رویدادها در یک مکان مخصوص ذخیره می‌شوند که به عنوان سیستم ثبت رسمی عمل می‌کند و می‌توان از آن برای مدیریت وضعیت فعلی داده‌ها استفاده کرد.این روش می‌تواند کار با داده‌های پیچیده را ساده‌تر کند و همچنین برای بهبود عملکرد و پاسخگویی مفید باشد. علاوه بر این، می‌تواند تاریخچه کامل و ردیابی تغییرات را حفظ کرده و برای جبران عملیات مهم استفاده شود.Event Sourcing چندین مزیت داره:- تاریخچه: می‌تونیم لاگ تمام تغییرات رو ببینیم و چگونگی رسیدن به وضعیت فعلی رو بفهمیم.- قابلیت بازگشت: می‌تونیم وضعیت گذشته رو بازسازی کنیم.- قابلیت تغییر: می‌تونیم تغییرات رو به صورت retroactive اعمال کنیم.البته این روش هم معایبی داره:- پیچیدگی: پیاده‌سازی Event Sourcing نیازمند تجربه و همکاری با کارشناسان دامنه و ایجاد یک زبان مشترکه.- هزینه: پیاده‌سازی و نگهداری این روش هزینه‌بره.این روش می‌تونه با هر زبان برنامه‌نویسی استفاده بشه، اما برخی از زبان‌ها ابزارهای مناسبتری برای این کار دارن. برخی از زبان‌های معمول برای استفاده از Event Sourcing:- جاوا اسکریپت: استفاده زیادی در توسعه وب داره و ابزارهای زیادی برایش ارائه شده مثل Node.js و React.- پایتون: به خاطر سادگی و خواناتیش خوبه و کتابخانه‌هایی مثل EventSourcing .****Low code platformsپلتفرم‌های کم کد، ابزارهای نرم افزاری هستند که به افراد معمولی اجازه می‌دهند برنامه‌هایی بدون نیاز به کدنویسی پیچیده بسازند. این ابزارها با ارائه قالب‌های آماده، قابلیت‌های کشیدن و رها کردن، و اجزا قابل استفاده مجدد، فرآیند ساخت برنامه را آسان می‌کنند. به عبارت دیگر، کاربران می‌توانند بدون دانستن زبان‌های برنامه‌نویسی، برنامه‌های مختلفی مثل برنامه‌های وبی، موبایلی، دسکتاپی و حتی ابری ایجاد کنند. این پلتفرم‌ها برای ایجاد برنامه‌هایی که سریع، آسان و برای همه قابل دسترس طراحی شده‌اند.بعضی از مزایای استفاده از پلتفرم‌های کم کد عبارتند از:• کاهش زمان و هزینه توسعه برنامه از طریق خودکارسازی و ساده‌سازی فرآیند‌های مختلف مانند تست، اشکال‌زدایی و نصب برنامه.• قابلیت تغییر و سفارشی‌سازی برنامه‌ها بر اساس نیازها و ترجیحات کاربران، بدون افت کیفیت یا عملکرد برنامه.• افزایش همکاری و نوآوری از طریق به اشتراک‌گذاری و دوباره استفاده از برنامه‌ها و سیستم‌های مختلف.• حل مشکلات تجاری و برآورده کردن نیازهای مشتریان بدون وابستگی به تیم‌های فناوری اطلاعات یا فروشندگان خارجی.همچنین، برخی از چالش‌هایی که پلتفرم‌های کم کد دارند:• محدودیت‌هایی در اموری مانند مقیاس‌پذیری، عملکرد، امنیت و یکپارچگی، به خصوص برای برنامه‌های پیچیده یا در مقیاس بزرگ.• نیاز به مهارت‌های کدنویسی یا فنی برای ویژگی‌های پیشرفته یا سفارشی‌سازی، بسته به پلتفرم و نیازهای برنامه.• خطراتی مانند قطع پشتیبانی یا تغییرات ارائه‌دهنده پلتفرم ممکن است به مسائل انطباق یا از دست دادن داده‌ها منجر شود.چند نمونه از پلتفرم‌های کم کد عبارتند از:• Creatio: یک پلتفرم کم کد برای ایجاد برنامه‌های مدیریت فرآیند کسب و کار و مدیریت ارتباط با مشتری با ویژگی‌های طراحی ساده، ویژگی‌های کشیدن و رها کردن و اتوماسیون.‌ Microsoft Power Apps: یک پلتفرم با کد کم برای ساخت برنامه‌های وب و موبایل با قابلیت‌های اتصال دهنده‌های داده، الگوهای آماده و استفاده از سرویس‌های ابری.• Google AppSheet: یک پلتفرم کم کد برای ایجاد برنامه‌های مبتنی بر داده‌های مختلف با قابلیت‌های مثل پردازش زبان طبیعی و یادگیری ماشینی.• Salesforce Platform: یک پلتفرم کم کد برای ساخت برنامه‌های اکوسیستم Salesforce با ویژگی‌هایی مانند اجزای Lightning و ادغام با AppExchange و Heroku."****سیستم‌های مدیریت فرآیند کسب و کار (BPMS) ابزارهای نرم‌افزاری هستن که به شما کمک می‌کنند فعالیت‌های مختلفی که برای دستیابی به هدفی خاص انجام می‌شه (مثلاً ساخت محصول یا ارائه خدمات به مشتری) رو طراحی، اجرا، نظارت و بهینه‌سازی کنید. این ابزارها می‌تونن به شما کمک کنن فرآیندهای کاری رو خودکارتر، ساده‌تر و بهتر انجام بدین و اونها رو کارآمدتر، مؤثرتر و سازگارتر کنین.بعضی ویژگی‌ها و مزایای BPMS:• به شما اجازه می‌ده که از ابزارهای گرافیکی مثل نمودارها و فلوچارت‌ها استفاده کنید و فرآیندهای کاری‌تون رو مدل کنید. می‌تونید مراحل، نقش‌ها، قوانین، داده‌ها و منابع مورد استفاده در هر فرآیند رو تعریف کنید.‌ شما رو قادر می‌سازند که فرآیندهای کاری‌تون رو با استفاده از فناوری‌های مختلف مثل وب سرویس‌ها، پایگاه داده‌ها و برنامه‌های کاربردی اجرا کنید و با سیستم‌ها و پلتفرم‌های مختلف ادغامشون کنید.• ابزارهای مختلفی رو برای نظارت و تجزیه و تحلیل فرآیندهای کاری‌تون مثل داشبورد، گزارش‌ها و هشدارها در اختیار شما قرار می‌دهند. می‌تونید عملکرد، وضعیت و نتایج فرآیندهای خودتون رو ردیابی کنید و مشکلات یا فرصت‌های بهبود رو شناسایی کنید.• این ابزارها به شما امکان می‌دهند که با اعمال تغییرات یا نوآوری‌ها، فرآیندهای کاری‌تون رو بهبود ببخشید. می‌تونید به سرعت و آسونی تغییرات رو آزمایش و اعمال کنید و با تغییر نیازهای کسب‌وکار، انتظارات مشتریان یا شرایط بازار سازگارشون کنید.چند نمونه از BPMS:• Creatio: یک BPMS که به شما امکان می‌دهد برنامه‌های مدیریت فرآیند کسب‌وکار و مدیریت ارتباط با مشتری رو با ویژگی‌های مدل‌سازی بصری و اتوماسیون مبتنی بر هوش مصنوعی ایجاد کنید.• Microsoft Power Automate: یک BPMS بر پایه ابر که به شما اجازه می‌دهد گردش‌کارها و وظایف رو در برنامه‌ها و سرویس‌های مختلف اجرا کنید.• Oracle BPM Suite: یک BPMS سازمانی که به شما امکان می‌دهد فرآیندهای کاری‌تون رو مدیریت و بهینه‌سازی کنید.****Message Queue (such as Kafka and RabbitMQ)سیستم پیام‌رسانی (MQ) یه نرم‌افزاره که به برنامه‌ها اجازه میده با هم پیام بفرستن و بگیرن. پیام‌ها که واحدهای جداگانه از داده ها هستن، مثل دستورات، درخواست‌ها یا پاسخ‌ها، توی این سیستم ارسال و دریافت میشن. MQ ارتباط ناهمزمان رو ممکن می‌کنه، به این معنی که ارسال‌کننده و گیرنده نیاز نیست همزمان آنلاین یا در دسترس باشن. همچنین ویژگی‌هایی مثل بافر، مسیریابی، ماندگاری و اطمینان از تحویل صحیح پیام‌ها رو هم داره.بعضی مزایای استفاده از MQ:• کاهش وابستگی بین برنامه‌ها؛ چون MQ به برنامه‌ها اجازه میده بدون اطلاعات دقیق در مورد هم، مثل مکان یا فرمت، کار کنن. این باعث میشه برنامه‌ها انعطاف‌پذیرتر و مواجه با تغییرات سازگارتر باشن.• بهبود عملکرد برنامه‌ها؛ چون می‌تونند پیام‌ها رو بدون مسدود شدن یا منتظر موندن ارسال و دریافت کنن. همچنین MQ کار رو بین چند برنامه توزیع می‌کنه و از مشکلات و خرابی‌ها جلوگیری می‌کنه.• افزایش انعطاف‌پذیری و تحمل خطا؛ چون MQ می‌تونه با خرابی‌ها و خطاها کنار بیاد و بدون از دست دادن داده‌ها یا عملکرد کار کنه. همچنین مکانیزم‌هایی برای تلاش مجدد، بازیابی و جبران پیام‌ها فراهم می‌کنه.چند نمونه از سیستم پیام‌رسانی:• کافکا: یک پلتفرم پخش توزیع‌شده که به برنامه‌ها امکان میده جریان پیام‌ها رو منتشر کنن و با هم به اشتراک بذارن. کافکا بهترین ویژگی‌های یک سیستم پیام‌رسانی رو داره، مانند پردازش داده، تکرار، و یکپارچه‌سازی.• RabbitMQ: یک واسطه پیام توزیع‌شده که داده‌ها رو از چند منبع جمع‌آوری کرده و به مقصدهای مختلف برای پردازش هدایت می‌کنه. RabbitMQ از الگوهای پیام‌رسانی مختلف پشتیبانی می‌کنه و ویژگی‌هایی مثل خوشه‌بندی، در دسترس بودن و امنیت داره.****Container orchestration (such as Kubernetes)روش خودکار برای مدیریت و استفاده بهینه از کانتینرها. کانتینرها واحدهای جداگانه ای از نرم افزارن که توشون کد و وابستگی‌های مورد نیاز برای اجرای برنامه‌ها هستن. ارکستراسیون کانتینر به شما این امکان رو میده که چندین کانتینر رو به صورت خودکار و بدون دردسر، روی چندین ماشین اجرا کنید.مزایای استفاده از Container orchestration:س کارایی: ارکستراسیون کانتینر منابع رو بهینه کنه و هزینه های عملیاتی رو کم می‌کنه. همچنین بهترین شکل استقرار و به‌روزرسانی برنامه‌ها رو فراهم می‌کنه.• مقیاس پذیری: این روش به شما این امکان رو میده که برنامه هاتون رو بر اساس نیازتون تغییر سایز بدین. همچنین با توزیع ترافیک و قرار دادن سرویس‌ها در سراسر شبکه، از برخی مشکلات هم جلوگیری می‌کنه.• قابلیت اطمینان: مطمئن میشید که برنامه هاتون همیشه در دسترس و مقاوم در برابر خطا هستن. این روش ویژگی‌هایی مثل بررسی سلامت و برگشت به حالت پیشین رو داره که در مواقع ناخواسته، کمک می‌کنه مشکلات رو حل کنید.چند نمونه ابزار Container orchestration:• Kubernetes: این ابزار به شما کمک می‌کنه تا مجموعه‌ای از کانتینرها رو با استفاده از مفاهیمی مثل پادها، سرویس‌ها و گره‌ها مدیریت کنید. Kubernetes از ویژگی‌های زیادی مثل زمان‌بندی، شبکه‌سازی و امنیت پشتیبانی می‌کنه.• Docker Swarm: این ابزار از مفاهیمی مثل سرویس‌ها و گره‌ها استفاده می‌کنه تا مجموعه‌ای از گره‌های Docker رو مدیریت کنه. Docker Swarm از ویژگی‌هایی مثل کشف سرویس و متعادل‌سازی بار پشتیبانی می‌کنه.• Apache Mesos: این ابزار یه سیستم توزیع شده است که به شما کمک می‌کنه که کانتینرها و بارهای کاری دیگه رو هماهنگ کنید. Apache Mesos از ویژگی‌هایی مثل تخصیص منابع و تحمل خطا پشتیبانی می‌کنه.****Log Management Tools (such as ELK)ابزارهای مدیریت گزارش، کمک می‌کنند داده‌های گزارش مثل خطاها، هشدارها و اطلاعات دیگه از برنامه‌ها و سیستم‌هاتون رو جمع‌آوری و نظارت کنید. با استفاده از این ابزارها، می‌تونید داده‌ها رو تجزیه و تحلیل کرده و به صورت گزارش یا نمودار نشون دید.ELK Stack یه از معروف‌ترین ابزارهای این دسته‌ست. این پشته شامل Elasticsearch، Logstash و Kibana هست. Elasticsearch یه موتور جستجو و تجزیه و تحلیله، Logstash داده‌ها رو جمع‌آوری و ارسال می‌کنه و Kibana اون داده‌ها رو به صورت نمودار یا گزارش نشون می‌ده.ELK Stack بهتون کمک می‌کنه داده‌های گزارش رو جمع‌آوری کنید و ببینید چه اتفاقاتی تو برنامه‌هاتون میوفته. به علاوه، با این ابزار می‌تونید داده‌ها رو از منابع مختلف جمع‌آوری کنید و به شکل نمودارهایی روشن و زیبا نشون بدید.اگه به دنبال جایگزینی برای ELK هستید، می‌تونید Sematext Logs رو امتحان کنید. این ابزار مدیریت Log هست که داده‌هاتون رو جمع‌آوری و نمایش می‌ده، بدون اینکه نیاز به مدیریت پیچیده‌ترین قسمت‌های ELK باشه. Sematext Logs همچنین ویژگی‌های امنیتی و نظارتی خوبی داره که ممکنه مورد نیازتون باشه.****Monitoring tools (such as Prometheus)ابزارهای نظارتی سیستم‌های نرم‌افزاری، بهتون کمک می‌کنند ببینید که برنامه‌ها یا سیستم‌هاتون چجوری عمل می‌کنن و مشکلاتشون رو پیدا کنید. این ابزارها می‌تونن انواع داده‌ها مثل گزارش‌ها، رویدادها، یا اطلاعات مربوط به کارکرد برنامه رو جمع‌آوری و نمایش بدن. با ویژگی‌هایی مثل هشدارها و داشبوردها، بهتون کمک می‌کنند که مشکلات رو پیدا کرده و سیستم‌هاتون رو بهتر کنید.یکی از ابزارهای محبوب برای نظارت، Prometheus هست. این ابزار کمک می‌کنه تا داده‌های مربوط به عملکرد برنامه‌هاتون رو جمع‌آوری کنید و اطلاعات مهمی رو نشون بدید. با استفاده از این ابزار، می‌تونید:• اطلاعات مهم از سرویس‌های مختلف رو جمع‌آوری کنید و از Prometheus برای نمایش اونها استفاده کنید.• معیارهای مهمی رو ذخیره و نمایش بدید و هشدار بگیرید.• اعلان‌ها رو به کانال‌های مختلف ارسال کنید.• از ابزارهایی مثل Grafana برای ساخت داشبورد و نمودارهایی استفاده کنید که بهتون کمک کنه معیارهای Prometheus رو بهتر بفهمید.****Static Code Analysis (such as SonarQube)"تجزیه و تحلیل کد استاتیک (SCA) یعنی چک کردن کدهای یک نرم‌افزار که نوشته شده و برای پیدا کردن و رفع اشکالات، مشکلات و نقاط ضعفشون هست. SCA با استفاده از قوانین و استانداردها کمک می‌کنه تا کیفیت و امنیت نرم‌افزار بهتر بشه.بعضی مزایای SCA اینجوری هستن:• می‌تونه مشکلاتی که ممکنه وقتی نرم‌افزار اجرا میشه پیش بیان و جلوگیریشون کرده.• می‌تونه زمان و هزینه تست و رفع مشکلات کدها رو با استفاده از روش‌های خودکار کم کنه.• با پیروی از قوانین و دستورالعمل‌های مشخص، می‌تونه کد رو با مقررات و استانداردهای مشخصی سازگار کنه.اما چند مشکل هم داره:• ممکنه گزارشات اشتباهی رو بده که مشکلات حقیقی نیستن یا مشکلات واقعی رو نادیده بگیره.• پیکربندی و سفارشی کردن ابزارها و گزارشات بسته به نوع پروژه و زبان‌های برنامه‌نویسی ممکنه زمان‌بر باشه.• پوشش دادن همه جنبه‌های کدها مثل ورودی‌های کاربر یا رفتارهای مختلف ممکنه دشوار باشه.SonarQube یکی از ابزارهای معروف برای SCA هست. این ابزار کدهای نوشته شده به زبان‌های مختلف رو چک می‌کنه و گزارش‌هایی در مورد کیفیت کد، تست‌ها، باگ‌ها و آسیب‌پذیری‌های امنیتی می‌ده. همچنین از ویژگی‌هایی مثل داشبورد و هشدارها برای اطلاعات بیشتر و ادغام با ابزارهای دیگه هم پشتیبانی می‌کنه.منابع:https://www.mongodb.com/nosql-explainedhttps://www.g2.com/articles/serverless-architecturehttps://www.redhat.com/en/topics/cloud-native-apps/what-is-serverlesshttps://www.datadoghq.com/knowledge-center/serverless-architecture/https://domaindrivendesign.org/ddd-domain-driven-design/https://en.wikipedia.org/wiki/Domain-driven_designhttps://dzone.com/articles/hexagonal-architecture-what-is-it-and-how-does-ithttps://martinfowler.com/eaaDev/EventSourcing.htmlhttps://powerapps.microsoft.com/en-us/low-code-platform/https://www.g2.com/categories/low-code-development-platformshttps://www.processmaker.com/blog/what-is-a-bpms-a-guide-to-business-process-management-systems/https://aws.amazon.com/compare/the-difference-between-rabbitmq-and-kafka/https://medium.com/@ramekris/message-queues-rabbitmq-vs-kafka-335076a5ff88https://sematext.com/blog/best-log-management-tools/https://en.wikipedia.org/wiki/Prometheus_(software) فاطمه میرزایی فاطمه میرزایی Tue, 21 Nov 2023 23:33:54 +0330 https://virgool.io/@phateme_mirzaie/%D8%AA%D9%85%D8%B1%DB%8C%D9%86-%D8%AE%D9%88%D8%A7%D9%86%D8%B4-%D9%81%D8%B5%D9%84%D9%87%D8%A7%DB%8C-15-%D8%AA%D8%A7-29-%DA%A9%D8%AA%D8%A7%D8%A8-%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C-%D8%AA%D9%85%DB%8C%D8%B2-k6a655jfclq0 فصل 15: معماری چیست؟در ابتدا تعریفی از معماری نرم‌افزار ارائه می‌دهد و توضیح می‌دهد که شامل تصمیم‌گیری‌های سطح بالا در مورد ساختار و سازمان یک سیستم نرم‌افزاری است. همچنین تأکید می‌کند که ارزش ساختار یک سیستم نرم‌افزاری از ارزش رفتار آن بیشتر است و یک معماری خوب طراحی شده می‌تواند هزینه‌های نگهداری را تا حد زیادی کاهش دهد و تغییر سیستم را در طول زمان آسان‌تر کند. وظایف یک معمار نرم‌افزار از جمله طراحی ساختار کلی سیستم، تصمیم‌گیری در مورد فناوری و ابزار‌ها و برقراری ارتباط با ذینفعان است. در ادامه اهمیت جداسازی تصمیمات خط مشی سطح بالا از جزئیات اجرای سطح پایین را مورد بحث قرار می‌دهد. توضیح می‌دهد که این جداسازی می‌تواند به کاهش هزینه تعمیر و نگهداری کمک کند و تغییر سیستم را در طول زمان آسان‌تر کند.همچنین اشاره می‌کندکه همیشه لازم نیست درباره جزئیات خاص در اوایل فرآیند توسعه تصمیم‌گیری کنید. با باز نگه داشتن گزینه‌ها و تأخیر در تصمیم‌گیری‌ها، می‌توانید اطلاعات بیشتری را جمع‌آوری کنید و قبل از تصمیم‌گیری نهایی، آزمایش‌های مختلفی را امتحان کنید.در آخر مثالی از اوایل دهه ۱۹۷۰ از یک سیستم حسابداری بزرگ برای اتحادیه کامیون‌داران را شرح می‌دهد. این سیستم سوابق نمایندگان، کارفرمایان و اعضا را روی یک درایو دیسک ۲۵ مگابایتی ذخیره می‌کرد. توضیح می‌دهد که ارزش استقلال دستگاه بسیار زیاد بود، زیرا به تیم اجازه می‌داد برنامه‌هایی بنویسند بدون اینکه بدانند یا اهمیت بدهند از کدام دستگاه استفاده می‌شود. این تیم می‌تواند آن برنامه‌ها را با استفاده از یک چاپگر خط محلی متصل به رایانه آزمایش کند و سپس به سیستم عامل بگوید که روی نوار مغناطیسی «چاپ» کند و صد‌ها هزار فرم را اجرا کند. این پاراگراف تأکید می‌کند که تیم تصمیم‌گیری در مورد استفاده از دستگاه را به تعویق انداخت و خط مشی (دستگاه) را از جزئیات (قالب‌بندی سوابق نام و آدرس) جدا کرد.فصل 16 : استقلالاین فصل بر اهمیت استقلال در معماری نرم افزار تاکید می کند. معماری باید از use case و بهره برداری از سیستم ، نگهداری سیستم، توسعه و استقرار سیستم پشتیبانی کند. باید use case را به وضوح نشان دهد و از هدف سیستم پشتیبانی کند. معماری همچنین باید توان عملیاتی و زمان پاسخ دهی بالایی داشته باشد و حالت های مختلف عملکرد را در اختیار داشته باشد. این باید اقدامات مستقل توسط تیم های مختلف در محیط توسعه را تسهیل کند. علاوه بر این، معماری باید استقرار آسان را بدون پیکربندی دستی امکان پذیر کند. جداسازی لایه ها و موارد استفاده برای دستیابی به استقلال بسیار مهم است، اما تمایز بین تکرار واقعی و تکراری تصادفی مهم است. حالت های مختلف جداسازی، مانند سطح منبع، سطح استقرار و سطح سرویس، بر اساس نیازهای سیستم قابل استفاده است. نویسنده همچنین چالش ها و هزینه های مرتبط با جداسازی سطح خدمات را مورد بحث قرار می دهد و یک رویکرد انعطاف پذیر را پیشنهاد می کند. آنها اهمیت یک معماری خوب را برجسته می کنند که به سیستم اجازه می دهد از یکپارچه به واحدها یا خدمات مستقل قابل استقرار تکامل یابد و بالعکس. نویسنده با بیان اینکه حالت جداسازی یک سیستم احتمالاً در طول زمان تغییر می کند، نتیجه گیری می کند و یک معمار خوب این تغییرات را پیش بینی و تسهیل می کند.فصل 17 : خط مرزی :خطوط طراحیاین فصل بر اهمیت ترسیم مرزها در معماری نرم افزار تاکید می کند. مرزها برای جدا کردن عناصر نرم افزار و جلوگیری از داشتن دانش بیش از حد در مورد یکدیگر عمل می کنند. تصمیمات زودهنگام، مانند انتخاب چارچوب ها یا پایگاه های داده، می تواند منجر به جفت شدن و افزایش تلاش برای توسعه شود. این فصل نمونه‌هایی از شرکت‌هایی را ارائه می‌دهد که به دلیل تصمیم‌های زودهنگام با پیامدهای منفی مواجه شدند، و همچنین نمونه‌ای از معماری موفقی که تصمیم‌گیری‌ها را به تعویق انداخت و در زمان و تلاش صرفه‌جویی کرد.این فصل همچنین اهمیت تمایز بین چیزهایی که مهم هستند و چیزهایی که مهم نیستند، مانند رابط کاربری گرافیکی و قوانین کسب و کار، یا پایگاه داده و قوانین تجاری را برجسته می کند. رابط کاربری گرافیکی و قوانین تجاری باید با یک مرز از هم جدا شوند و رابط کاربری گرافیکی افزونه ای است که می تواند به راحتی با رابط های مختلف جایگزین شود. این معماری پلاگین مقیاس پذیری و نگهداری را امکان پذیر می کند.رابطه بین اجزاء باید نامتقارن باشد و ماژول‌های خاصی نسبت به سایرین مصون باشند. مرزها باید در جایی ترسیم شوند که محور تغییر وجود دارد، و اصل مسئولیت واحد باید برای تعیین محل ترسیم مرزها اعمال شود. این فصل تاکید می کند که ورودی و خروجی (IO) یک سیستم، مانند یک رابط کاربری گرافیکی، نباید به عنوان خود سیستم اشتباه گرفته شود. قوانین تجاری اصلی سیستم باید از IO جدا شود و پایگاه داده باید به عنوان ابزاری در نظر گرفته شود که قوانین تجاری می توانند به طور غیر مستقیم از آن استفاده کنند. این فصل راهنمایی هایی در مورد چگونگی ترسیم موثر مرزها بین این مؤلفه ها ارائه می دهد.فصل 18: تشریح خط مرزیاین فصل بر اشکال مختلف مرزها در معماری نرم افزار از جمله مرزهای فیزیکی و منطقی تمرکز دارد. اهمیت مدیریت وابستگی‌های کد منبع و جداسازی اجزا برای افزایش انعطاف‌پذیری، سهولت توسعه، آزمایش و استقرار را برجسته می‌کند. این فصل همچنین انواع مختلف مرزها مانند گذرگاه های مرزی، یکپارچه ها، اجزای استقرار، رشته ها، فرآیندهای محلی و خدمات را مورد بحث قرار می دهد. این بر نیاز به در نظر گرفتن الزامات خاص سیستم هنگام برقراری ارتباط در سراسر مرزها تأکید می کند، زیرا هزینه و تأخیر ارتباط می تواند متفاوت باشد.فصل 19: خط مشی و سطحاین فصل بر نیاز به تجزیه خط مشی یک برنامه به بیانیه های کوچکتر و سازماندهی دقیق آنها بر اساس نحوه تغییر آنها تأکید می‌کند. وابستگی بین اجزاء باید بر اساس سطح آنها تعیین شود، با اجزای سطح پایین بسته به اجزای سطح بالا. این رویکرد به جداسازی سیاست‌های سطح بالا از سیاست‌های ورودی/خروجی سطح پایین کمک می‌کند و تأثیر تغییر را کاهش می‌دهد. این فصل همچنین چندین اصل را ذکر می‌کند که معماری نرم‌افزار خوب را راهنمایی می‌کند، از جمله اصل مسئولیت منفرد، اصل باز-بسته، اصل بسته مشترک، اصل وارونگی وابستگی، اصل وابستگی‌های پایدار، و اصل انتزاعات پایدار.فصل 20: قوانین کسب و کاراین فصل مفهوم قوانین کسب و کار و اهمیت آنها در پس انداز یا کسب درآمد برای یک کسب و کار را مورد بحث قرار می دهد. انواع مختلفی از قوانین تجاری وجود دارد، از جمله قوانین تجاری حیاتی که بدون توجه به اتوماسیون وجود دارند و مواردی را استفاده می کنند که عملکرد یک سیستم خودکار را تعریف و محدود می کنند. موجودیت ها اشیایی را نشان می دهند که قوانین تجاری حیاتی را در بر می گیرند و بر روی داده های تجاری حیاتی عمل می کنند. موارد استفاده، از سوی دیگر، قوانین تجاری خاص برنامه را توصیف می کنند و تعامل بین کاربران و موجودیت ها را کنترل می کنند. توجه به این نکته ضروری است که موارد استفاده رابط کاربری سیستم را توصیف نمی کنند. مدل‌های درخواست و پاسخ در موارد استفاده برای مدیریت داده‌های ورودی و خروجی استفاده می‌شوند و باید مستقل از هر چارچوب یا رابط کاربری خاصی باشند. این فصل بر لزوم جدا ماندن قوانین تجاری از سایر نگرانی‌ها و مستقل‌ترین و قابل استفاده‌ترین کد در سیستم تأکید می‌کند.فصل 21: معماری شگفت انگیزاین فصل بر اهمیت طراحی معماری که با موارد استفاده خاص یک برنامه همسو باشد، به جای اینکه صرفاً بر اساس چارچوب ها باشد، تأکید می کند. آنها استدلال می‌کنند که چارچوب‌ها را باید به‌عنوان ابزاری برای استفاده به‌جای پایه‌ی معماری در نظر گرفت. علاوه بر این، نویسنده پیشنهاد می کند که تصمیم گیری در مورد نحوه ارائه یک برنامه از طریق وب باید به تعویق بیفتد، زیرا نباید معماری را دیکته کند. فصل با بیان این که یک معماری خوب باید سیستم و موارد استفاده از آن را اولویت بندی کند، به جای چارچوب های به کار گرفته شده، به پایان می رسد.فصل 22: معماری تمیزThe Clean Architecture یک معماری نرم افزاری است که بر جداسازی نگرانی ها و ایجاد سیستم هایی مستقل از چارچوب ها و عناصر خارجی تمرکز دارد. این شامل چهار لایه است: موجودیت ها، موارد استفاده، آداپتورهای رابط، و چارچوب ها/درایورها. این معماری از قانون وابستگی پیروی می‌کند، که بیان می‌کند که وابستگی‌های کد منبع فقط باید به سمت سیاست‌های سطح بالاتر به سمت داخل باشند. این رویکرد سیستم ها را قادر می سازد تا به راحتی آزمایش شوند و با تغییرات در رابط کاربری، پایگاه داده یا سایر عناصر خارجی سازگار شوند.فصل 23: presenter و شی Humbleاین فصل مفهوم ارائه‌دهنده و اشیاء Humble را به عنوان راهی برای شناسایی و محافظت از مرزهای معماری معرفی می‌کند. الگوی Object Humble یک الگوی طراحی است که رفتارهای آزمون سخت را از رفتارهای آسان برای آزمایش جدا می کند. رفتارها را به دو ماژول یا کلاس تقسیم می‌کند: شی Humble، که شامل رفتارهای آزمایش‌شدنی است، و شی قابل آزمایش، که شامل رفتارهای آزمایش‌پذیر حذف‌شده است. در زمینه رابط‌های کاربری گرافیکی، View شیء Humbleی است که آزمایش آن سخت است، در حالی که Presenter شیء قابل آزمایشی است که داده‌های برنامه را می‌پذیرد و آن را برای ارائه قالب‌بندی می‌کند. جداسازی رفتارها به بخش‌های آزمایش‌پذیر و غیرقابل آزمایش، اغلب یک مرز معماری را مشخص می‌کند. نمونه‌های دیگر از مرزهای معماری شامل دروازه‌های پایگاه داده، نقشه‌برداران داده و شنوندگان خدمات است. استفاده از الگوی Object Humble در مرزهای معماری، آزمایش پذیری سیستم را افزایش می دهد.فصل 24: مرزهای جزئیاین فصل رویکردهای مختلفی را مورد بحث قرار می دهد که معماران می توانند در هنگام ایجاد مرزهای معماری اتخاذ کنند. این نشان می دهد که در برخی موارد، ایجاد یک مرز کامل می تواند گران و زمان بر باشد. در چنین شرایطی، معماران ممکن است انتخاب کنند که یک مرز جزئی را به عنوان یک مکان نگهدار برای یک مرز بالقوه آینده اجرا کنند. این شامل نگه داشتن تمام اجزای ضروری با هم در یک کامپوننت است، حتی اگر بتوان آنها را به طور مستقل کامپایل و مستقر کرد. در حالی که این رویکرد بار اداری را کاهش می دهد، همچنین خطر عبور وابستگی ها از مرزها را در طول زمان به همراه دارد.از طرف دیگر، معماران می توانند از ساختارهای ساده تری مانند الگوی استراتژی یا الگوی نما استفاده کنند. این الگوها سطح پایه ای از جداسازی را فراهم می کنند اما ممکن است مشتری را به طور کامل از پیاده سازی جدا نکنند. این فصل تاکید می کند که معماران باید هزینه ها و مزایای هر رویکرد را به دقت در نظر بگیرند و تصمیم بگیرند که آیا یک مرز کامل یا جزئی برای زمینه خاص آنها مناسب است یا خیر.فصل 25:لایه ها و مرزهااین فصل به بررسی مفهوم لایه ها و مرزها در سیستم های نرم افزاری می پردازد. آنها از یک بازی کامپیوتری ساده به عنوان مثال استفاده می کنند تا چگونگی تعامل اجزای مختلف مانند رابط کاربری، قوانین تجاری و پایگاه داده با یکدیگر را نشان دهند. نویسنده بر اهمیت مدیریت وابستگی بین این مؤلفه ها به طور مؤثر تأکید می کند و استفاده از API ها را برای جدا کردن آنها پیشنهاد می کند. همچنین ایده مرزهای معماری و چگونگی تعریف آنها را بر اساس محورهای مختلف تغییر، مانند زبان یا مکانیسم ارتباطی، معرفی می کند. این مرزها به جداسازی و سازماندهی بخش‌های مختلف سیستم کمک می‌کنند و درک و نگهداری آن را آسان‌تر می‌کنند.نویسنده نیاز معماران به پیش بینی نیاز به انتزاع و تصمیم گیری آگاهانه در مورد اجرای مرزهای معماری را برجسته می کند. آنها تاکید می کنند که معماران باید هزینه ها و خطرات مربوط به اجرای این مرزها را در نظر بگیرند.به طور کلی، این فصل بر اهمیت مدیریت صحیح وابستگی‌ها، استفاده از APIها برای جداسازی اجزا، تعریف مرزهای معماری و تصمیم‌گیری آگاهانه در مورد اجرای این مرزها بر اساس هزینه‌ها و ریسک‌ها تاکید می‌کند.فصل 26 : کامپوننت اصلیاین فصل اهمیت مؤلفه اصلی در یک سیستم و نقش آن در ایجاد، هماهنگی و نظارت بر سایر اجزا را مورد بحث قرار می دهد. مؤلفه اصلی به عنوان نقطه ورود اولیه سیستم عمل می کند و مسئول بارگیری منابع و تنظیمات است. باید از یک چارچوب تزریق وابستگی برای تزریق وابستگی استفاده کند. Main Component به عنوان افزونه ای عمل می کند که شرایط و تنظیمات اولیه برنامه را تنظیم می کند. همچنین اشاره می کند که چندین مؤلفه اصلی را می توان برای پیکربندی ها یا استقرارهای مختلف استفاده کرد.فصل 27: سرویس ها : بزرگ و کوچکاین فصل محبوبیت معماری های سرویس گرا و میکرو سرویس را مورد بحث قرار می دهد و برخی از مزایای فرضی آنها را به چالش می کشد. این استدلال می کند که سرویس ها به تنهایی یک معماری را تعریف نمی کنند و هنوز هم می توان خدمات را با منابع و داده های مشترک همراه کرد. این فصل مفهوم خدمات مبتنی بر مؤلفه را معرفی می کند که امکان افزودن ویژگی های جدید را بدون تغییر مؤلفه های موجود فراهم می کند. تأکید می کند که معماری یک سیستم با مرزها و وابستگی های آن تعریف می شود، نه فقط مکانیسم های فیزیکی ارتباط و اجرا.فصل 28 : مرز تستاین فصل بر اهمیت ادغام تست ها در معماری سیستم و طراحی آنها به گونه ای که به خوبی یکپارچه و به طور مستقل قابل استقرار باشند، تاکید می کند. این قانون وابستگی را برجسته می کند، که بیان می کند که تمام تست ها باید به اجزای مورد آزمایش بستگی داشته باشند. این فصل همچنین بر نیاز به آزمایش پذیری برای جلوگیری از شکنندگی و استحکام در آزمایش ها تأکید می کند. پیشنهاد می‌کند از یک API آزمایشی برای جدا کردن تست‌ها از ساختار برنامه استفاده کنید، که امکان تکامل آسان‌تر تست‌ها و کد تولید را فراهم می‌کند. همچنین بر اهمیت جدا نگه داشتن API آزمایشی از سیستم تولید برای اطمینان از امنیت تأکید می کند. این فصل هشدار می‌دهد که نگهداری آزمایش‌هایی که طراحی ضعیفی دارند ممکن است دشوار باشد و ممکن است دور انداخته شوند.فصل 29 : معماری توکار تمیزاین فصل معماری جاسازی شده پاک توسط جیمز گرنینگ اهمیت مدیریت وابستگی به سیستم عامل و سخت افزار در توسعه نرم افزار تعبیه شده را مورد بحث قرار می دهد. نویسنده بر نیاز به ساختار نرم‌افزار تعبیه‌شده برای عمر طولانی و مفید، به جای صرفاً به کار انداختن آن، تأکید می‌کند. گرنینگ سه فعالیت را در ساختن نرم‌افزار شرح می‌دهد: کارآمد کردن آن، درست کردن آن و سریع‌تر کردن آن. او استدلال می‌کند که به نظر می‌رسد بسیاری از نرم‌افزارهای سیستم‌های جاسازی‌شده‌ای که در طبیعت می‌بیند، با در نظر گرفتن «آن را بساز» نوشته شده‌اند، و تأکید کافی بر ساختار آن برای عمر مفید طولانی‌مدت نشده است. نویسنده همچنین در مورد تعریف سیستم عامل و چگونگی منسوخ شدن آن با تکامل سخت افزار بحث می کند. گرنینگ توضیح می‌دهد که چگونه وابستگی‌های مدیریت نشده می‌توانند نرم‌افزار را از درون نابود کنند و چگونه یک معماری جاسازی شده تمیز برای سلامت بلندمدت محصول مفید است. در نهایت، نویسنده به این نتیجه می‌رسد که افرادی که در حال توسعه نرم‌افزارهای تعبیه‌شده هستند، چیزهای زیادی برای یادگیری از تجربیات خارج از نرم‌افزار تعبیه‌شده دارند. فاطمه میرزایی فاطمه میرزایی Fri, 20 Oct 2023 23:00:02 +0330