https://virgool.io/feed/@m_46173657 fa 2026-06-18 09:35:55 https://static.virgool.io/images/default-avatar.jpg https://virgool.io/@m_46173657 https://virgool.io/@m_46173657/%DA%AF%D8%B2%D8%A7%D8%B1%D8%B4-%D9%86%D9%87%D8%A7%DB%8C%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%DB%8C-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-xvgnye7ucrwm گزارش نهایی پروژه درس معماری نرم‌افزاردانشگاه شهید بهشتیمقدمهREST API یک ابزار قدرتمند برای توسعه وب سرویس ها و اپلیکیشن ها است. با استفاده از استانداردهای وب، REST API انعطاف پذیری بالایی دارد که به توسعه دهندگان اجازه می دهد به راحتی با آن کار کنند. این روش به دلیل سادگی و قابل فهم بودنش، در جامعه توسعه دهندگان بسیار محبوب شده است. REST API را می توان به عنوان یک راه حل قابل اعتماد و قابل استفاده در توسعه نرم افزار های مدرن در نظر گرفت.چرا معماری REST API مهم است؟معماری REST API نقش کلیدی در توسعه اپلیکیشن‌های مدرن و تعاملی بازی می‌کند. طراحی مناسب REST API نه تنها بر کارایی و قابلیت استفاده از اپلیکیشن تأثیر می‌گذارد، بلکه بر امنیت، نگهداری و توسعه‌پذیری سیستم نیز اثر می‌گذارد.یک معماری REST API نامناسب می‌تواند منجر به مشکلات متعددی شود:- کاهش کارایی: پاسخ‌های کند یا بارگذاری غیرضروری داده‌ها.- مشکلات امنیتی: آسیب‌پذیری‌های امنیتی به دلیل طراحی نادرست احراز هویت و مجوز.- دشواری در نگهداری: کد ناکارآمد یا پیچیده که نگهداری و به‌روزرسانی را دشوار می‌کند.- محدودیت در مقیاس‌پذیری: ناتوانی در توسعه و پاسخگویی به نیازهای رو به رشد کاربران.از سوی دیگر، یک معماری REST API خوب مزایای قابل توجهی به همراه دارد:- کارایی بالا: تبادل داده‌ها به صورت کارآمد و سریع.- امنیت قوی: کاهش آسیب‌پذیری‌ها از طریق روش‌های معتبر احراز هویت و مجوز.- انعطاف‌پذیری و نگهداری آسان: کد سازمان‌یافته و واضح که اجازه می‌دهد سیستم به راحتی توسعه یابد و به‌روز شود.- قابلیت مقیاس‌پذیری: توانایی پاسخگویی به رشد کاربران و نیازهای تغییرپذیر بدون کاهش عملکرد.اهمیت معماری REST API در این است که یک طراحی خوب نه تنها به ایجاد اپلیکیشن‌های با عملکرد بالا کمک می‌کند، بلکه اطمینان حاصل می‌کند که اپلیکیشن در طول زمان قابل توسعه و نگهداری است. این یک عنصر حیاتی در توسعه وب‌سرویس‌های مدرن است که به توسعه‌دهندگان اجازه می‌دهد سیستم‌های پیچیده و تعاملی را به صورت کارآمد و ایمن ایجاد کنند.ما در ادامه قصد داریم یک معماری مناسب برای api ها ارائه کنیم که بتواند به بهبود ویژگی‌های کیفی از جمله Availability, Maintainability, Performance, Testability کمک کند.در این راستا یک ابزاری به نام euler طراحی میکنیم که بتواند تمامی وابستگی‌های موجود در کل یک سیستم نرم افزاری را استخراج کرده و نمایش دهد. هدف این است که تا حد امکان و مناسب این وابستگی‌ها کمتر کنیم و به شکل درستی اصلاح کنیم. منظور از شکل درست به اصل Dependency Inversion و Interface Segregation (از اصول solid) اشاره دارد.پیش زمینهREST API، که به معنای نمایندگی وضعیت انتقالی (Representational State Transfer) است، یک الگوی معماری برای توسعه وب‌سرویس‌ها می‌باشد. این روش بر پایه‌ی معماری بدون حالت (stateless)، استانداردهای وب مانند HTTP، و استفاده از فرمت‌های متداول مانند JSON یا XML برای تبادل داده‌ها استوار است.REST API نقش مهمی در تسهیل ارتباط میان کلاینت‌ها و سرورها بازی می‌کند. این ارتباط اغلب از طریق درخواست‌های HTTP مانند GET برای دریافت داده‌ها، POST برای ایجاد داده‌ها، PUT برای به‌روزرسانی داده‌ها و DELETE برای حذف داده‌ها صورت می‌گیرد.پیش از محبوبیت REST API، روش‌هایی مانند SOAP و XML-RPC برای تبادل داده‌ها مورد استفاده قرار می‌گرفتند. این روش‌ها اغلب سنگین‌تر و کمتر انعطاف‌پذیر نسبت به REST بودند و استفاده از آن‌ها ممکن بود پیچیدگی‌هایی را به همراه داشته باشد.تفاوت اصلی میان REST و روش‌های قدیمی‌تر در سبک‌واری و انعطاف‌پذیری آن است. REST به‌طور گسترده‌ای از JSON استفاده می‌کند که نسبت به XML خوانایی و کارایی بیشتری دارد. همچنین، REST با تکیه بر استانداردهای وب، همگام‌سازی و توسعه را آسان‌تر می‌کند.در معماری‌های قبلی مانند SOAP، ارتباط بین کلاینت و سرور معمولاً سفت و محکم بود، به این معنی که تغییرات در سرور می‌توانست نیازمند تغییرات عمده در کلاینت باشد. در مقابل، REST API با ارائه یک ارتباط انعطاف‌پذیرتر، به کلاینت‌ها و سرورها اجازه می‌دهد که به‌صورت مستقل توسعه یابند.در کل، REST API نقش کلیدی در تسهیل توسعه مدرن وب‌سرویس‌ها و اپلیکیشن‌ها دارد. با انعطاف‌پذیری و سازگاری بالایی که با استانداردهای وب ارائه می‌دهد، این روش به یکی از راه‌حل‌های محبوب در بین توسعه‌دهندگان تبدیل شده است.هدف از انجام این تحقیقطراحی یک معماری خوب برای RESTful API‌ها بر کارایی، امنیت، مقیاس‌پذیری و قابلیت استفاده تمرکز دارد. هدف اصلی این است که API‌ها ساده و قابل فهم برای توسعه‌دهندگان باشند، به طوری که به راحتی بتوانند با آن‌ها ارتباط برقرار کنند و از آن‌ها استفاده کنند. کارایی بالا و پاسخگویی سریع، اطمینان از امنیت داده‌ها در برابر حملات و نفوذهای امنیتی، و قابلیت اطمینان در برابر بارهای سنگین و خطاهای احتمالی، از جمله مؤلفه‌های کلیدی در این زمینه هستند.علاوه بر این، معماری RESTful API باید به گونه‌ای طراحی شود که به راحتی بتواند با رشد و تغییرات کسب‌وکار تکامل یابد. بتواند به آسانی با سیستم‌های موجود و سایر API‌ها ادغام شود، با تکنولوژی‌های جدید و استانداردهای صنعتی همگام‌سازی شود، و قابلیت نگهداری و به‌روزرسانی آسان را دارا باشد. مستندسازی دقیق و جامع نیز نقش مهمی در ارتقاء قابلیت استفاده و کمک به توسعه‌دهندگان برای استفاده مؤثر از API دارد.یک معماری نامناسب برای API‌ها می‌تواند کیفیت تمامی موارد ذکر شده را کاهش دهد و نگهداری آن را دشوار کند. این می‌تواند در نهایت منجر به تجربه کاربری ناخوشایند شود. علاوه بر این، سختی در نگهداری و به‌روزرسانی API می‌تواند هزینه‌های بیشتری را به همراه داشته باشد و به اعتبار و اطمینان کاربران آسیب بزند.بنابراین ما در این تحقیق قصد داریم یک معماری مناسب، که تمام موارد گفته شده را برآورده می‌کند، ارائه دهیم.یک پیش مطالعهدر مقاله‌ی Microsoft Azure Architecture Center به تعریف و مفاهیم اصلی Representational State Transfer (REST)، که یک رویکرد معماری برای طراحی وب‌سرویس‌ها است، می‌پردازد. تأکید می‌شود که REST یک سبک معماری برای ساخت سیستم‌های توزیع‌شده بر اساس هایپرمدیا است و از هر پروتکل زیربنایی، از جمله HTTP، مستقل است. مزیت اصلی REST بر HTTP در استفاده از استانداردهای باز و عدم وابستگی پیاده‌سازی API یا اپلیکیشن‌های کلاینت به هر پیاده‌سازی خاصی است.در ادامه تأکید بر این است که طراحی API باید متمرکز بر منابع تجاری باشد که API آن‌ها را در معرض نمایش قرار می‌دهد. این شامل ایجاد URI‌هایی برای منابع و کلکسیون‌ها و استفاده از متدهای HTTP مانند GET، POST و DELETE برای تعامل با این منابع است. همچنین توصیه می‌شود که از نام‌گذاری‌های منسجم در URI‌ها استفاده شود و روابط بین انواع مختلف منابع در نظر گرفته شود.این نوشته توضیح داده می‌دهد که طراحی API باید با معناشناسی HTTP سازگار باشد. این شامل استفاده از متدهای HTTP مانند GET، POST، PUT، PATCH و DELETE برای انجام عملیات‌های مختلف بر روی منابع است. هر متد HTTP معنای خاصی دارد که باید در طراحی API مورد توجه قرار گیرد. به عنوان مثال، GET برای بازیابی منابع، POST برای ایجاد منابع جدید، و DELETE برای حذف منابع استفاده می‌شود. این بخش همچنین به اهمیت تطابق با مشخصات و قوانین HTTP اشاره دارد.API‌ها باید قادر به مدیریت داده‌های بزرگ و ارائه اطلاعات محدود و مرتبط به کاربران باشند. این شامل استفاده از فیلترها در رشته‌های کوئری URI برای بازگرداندن نتایج فیلترشده و پشتیبانی از صفحه‌بندی (pagination) برای محدود کردن تعداد آیتم‌های بازگردانده شده در هر درخواست است. این روش‌ها به کاهش بار شبکه و افزایش کارایی کمک می‌کنند.بحث بعدی که در این نوشته مورد بررسی قرار میگیرد چگونگی پشتیبانی از پاسخ‌های جزئی برای منابع بزرگ باینری مانند تصاویر یا فایل‌ها است. این شامل امکان بازیابی بخش‌هایی از یک منبع بزرگ به صورت جزئی، به ویژه در شرایطی که اتصالات ناپایدار هستند یا برای بهبود زمان پاسخگویی است. API باید از هدرهای Accept-Ranges برای GET درخواست‌ها پشتیبانی کند تا کلاینت‌ها بتوانند درخواست‌هایی با محدوده‌ی مشخص از بایت‌ها ارسال کنند.HATEOAS یک اصل مهم در طراحی RESTful API‌هاست که به کلاینت‌ها امکان می‌دهد از طریق هایپرلینک‌های موجود در پاسخ‌های API به منابع مرتبط دسترسی یابند و از عملیات‌های موجود بر روی آن منابع مطلع شوند. این رویکرد به ناوبری و کشف منابع جدید از طریق API کمک می‌کند و برای تحقق این هدف، استفاده از نمایندگی منابع در پاسخ‌ها با لینک‌های مربوطه توصیه می‌شود.ورژن‌بندی در API‌های RESTful مورد مهمی است که این کتاب در بخشی به اهمیت آن می‌پردازد و روش‌های آن را بیان میکند. ورژن‌بندی برای مدیریت تغییرات در API و اطمینان از اینکه کلاینت‌های موجود بدون نیاز به تغییر همچنان کار می‌کنند، ضروری است. مقاله راه‌های مختلفی برای ورژن‌بندی را بررسی می‌کند و به توصیه‌ها و راهنمایی‌هایی برای انتخاب روش مناسب ورژن‌بندی می‌پردازد.ابتکار Open API ایجاد شده است تا توصیفات API‌های REST را بین فروشندگان مختلف استانداردسازی کند. در این راستا، مشخصات Swagger 2.0 به OpenAPI Specification (OAS) تغییر نام داده و زیر نظر Open API Initiative قرار گرفت. استفاده از OpenAPI برای API‌های وب ممکن است مفید باشد. این ابتکار رویکرد مبتنی بر قرارداد (Contract-first) را ترویج می‌دهد، به این معنی که ابتدا قرارداد API (رابط) طراحی شده و سپس کدی نوشته می‌شود که این قرارداد را پیاده‌سازی کند. ابزارهایی مانند Swagger می‌توانند کتابخانه‌های مشتری یا مستندات را از قراردادهای API تولید کنند.مشکلات REST API هادر حالی که RESTful API‌ها مزایای قابل توجهی دارند و در بسیاری از پروژه‌های توسعه وب نقش مهمی بازی می‌کنند، چالش‌هایی به همراه دارد که درک این چالش‌ها و رویارویی با آن‌ها به توسعه‌دهندگان کمک می‌کند تا راهکارهای مؤثرتری ایجاد کنند.مدیریت حالت Statelessمدیریت حالت Stateless یکی از اصول اساسی REST است که در عین حال می‌تواند چالش‌برانگیز باشد. در معماری RESTful API، هر درخواست باید تمام اطلاعات لازم برای فهم و پردازش آن درخواست را داشته باشد. این بدان معناست که سرور هیچ حالت یا اطلاعاتی از درخواست‌های قبلی را نگه نمی‌دارد:· نیاز به ارسال اطلاعات تکراری در هر درخواست، مانند توکن‌های احراز هویت، می‌تواند کارایی سیستم را کاهش دهد و ترافیک شبکه را افزایش دهد.· در هر درخواست، احراز هویت کاربر باید مجدداً انجام شود، که می‌تواند فرآیند را پیچیده‌تر کند و به امنیت بیشتری نیاز داشته باشد.· در اپلیکیشن‌هایی که نیاز به حفظ جلسات کاربری دارند، مدیریت حالت بدون حالت می‌تواند به شکل چالش‌برانگیزی درآید.راهکارهاتوکن‌های احراز هویت: استفاده از توکن‌هایی مانند JWT (JSON Web Tokens) برای احراز هویت کاربر در هر درخواست به جای مدیریت حالت سنتی.· کش سمت کلاینت: ذخیره اطلاعات در سمت کلاینت برای کاهش تکرار اطلاعات در درخواست‌ها.· ساختاردهی دقیق: طراحی API به گونه‌ای که اطلاعات تکراری به حداقل برسد و اطلاعات مورد نیاز برای پردازش هر درخواست به طور مؤثر ارسال شود.محدودیت‌های پروتکل HTTPدر حالی که پروتکل HTTP برای RESTful API‌ها مزایای زیادی دارد، اما همچنین با محدودیت‌هایی همراه است که نیازمند درک و مدیریت دقیق است. توسعه‌دهندگان باید این محدودیت‌ها را شناسایی کرده و راهکارهای مناسبی را برای مواجهه با آن‌ها ارائه دهند تا اطمینان حاصل شود که API‌های آن‌ها کارآمد، امن و قابل مقیاس‌پذیری هستند:· یک‌طرفه بودن: HTTP یک پروتکل درخواست-پاسخ است و به طور ذاتی برای ارتباطات دوطرفه یا پیوسته (مانند WebSocket) طراحی نشده است. این محدودیت برای برخی از کاربردها، مانند اپلیکیشن‌های realtime، ممکن است مشکل‌ساز باشد.· HTTP از حالت stateless پیروی می‌کند، که در آن هر درخواست به صورت مستقل پردازش می‌شود. این امر مدیریت وضعیت و جلسات کاربری را دشوار می‌کند.· Over-fetching Under-fetching مبتنی بر HTTP ممکن است داده‌های بیشتر یا کمتر از آنچه که کلاینت نیاز دارد را بازگردانند. این موضوع می‌تواند منجر به افزایش بار شبکه و کاهش کارایی شود.· بهینه‌سازی پاسخ‌ها: کاهش بارگذاری‌های غیرضروری و بهینه‌سازی اندازه پاسخ‌ها در محیط‌های مبتنی بر HTTP می‌تواند پیچیده باشد.· مدیریت ورژن‌بندی API‌ها در HTTP می‌تواند دشوار باشد. تعیین چگونگی مدیریت تغییرات API و اطمینان از اینکه کلاینت‌های موجود همچنان کارایی دارند، نیازمند برنامه‌ریزی دقیق است.راهکارها برای مواجهه با محدودیت‌های HTTP· برای مواردی که نیاز به ارتباطات دوطرفه یا پیوسته است، می‌توان از WebSocket یا سایر پروتکل‌های تکمیلی استفاده کرد.· طراحی API مبتنی بر نیازهای کلاینت: کاهش over-fetching و under-fetching با طراحی API‌ها بر اساس نیازهای دقیق کلاینت.امنیتامنیت در RESTful API‌ها یک موضوع پیچیده و مستمر است که نیازمند توجه دقیق به جزئیات و پیاده‌سازی استراتژی‌های امنیتی قوی است. توسعه‌دهندگان باید به طور مداوم از بهترین شیوه‌ها و ابزارهای امنیتی پیروی کرده و آماده پاسخگویی به تهدیدات امنیتی متغیر باشند.· تعیین هویت (Authentication)کاربران یا سیستم‌هایی که درخواست‌ها را ارسال می‌کنند، اغلب پیچیده است. RESTful API‌ها باید از روش‌های معتبر احراز هویت مانند توکن‌های JWT یا OAuth استفاده کنند.· تعیین سطح دسترسی کاربران(Authorization) پس از احراز هویت، برای جلوگیری از دسترسی غیرمجاز به داده‌ها و منابع، حیاتی است.· حفظ امنیت داده‌ها در حین انتقال با استفاده از HTTPS برای جلوگیری از حملات میان‌بر (Man-in-the-Middle) و سایر حملات امنیتی.· اطمینان از اینکه اطلاعات حساس مانند گذرواژه‌ها و اطلاعات شخصی به درستی رمزنگاری می‌شوند و فاش نمی‌شوند.· اطمینان از اینکه API در برابر حملات مختلف، مانند بارگذاری بیش از حد داده‌ها (DoS) و حملات نفوذ، مقاوم است.بهینه‌سازی معماری APIکارایی و بهینه‌سازی در RESTful API‌ها موضوعات مهمی هستند که نیازمند توجه به جزئیات و درک دقیق نیازهای کلاینت و محدودیت‌های سیستم هستند. با بهینه‌سازی دقیق و استفاده از روش‌های مدرن، می‌توان کارایی API‌ها را به طور قابل توجهی افزایش داد و تجربه کاربری بهتری را فراهم کرد.· طراحی API به نحوی که کارآمد و قابل استفاده باشد، با کمترین تعداد درخواست برای انجام یک کار خاص.· در مواردی که over-fetching و under-fetching مسائل اصلی هستند، استفاده از GraphQL می‌تواند به کلاینت‌ها امکان دهد دقیقاً مشخص کنند که چه داده‌هایی نیاز دارند.راهکارها برای بهبود کارایی· ارائه پاسخ‌های متناسب با نیاز کلاینت‌ها برای کاهش over-fetching و under-fetching.· کاهش حجم داده‌های انتقالی با استفاده از فشرده‌سازی مانند GZIP.· استفاده از روش‌های caching مؤثر برای کاهش تعداد درخواست‌های تکراری.· تجمیع چندین درخواست به یک درخواست جامع برای کاهش بار شبکه.مدیریت ورژن‌بندیمدیریت ورژن‌بندی در RESTful API‌ها یک جنبه حیاتی در اطمینان از پایداری و تکامل مداوم API است. انتخاب روش مناسب ورژن‌بندی و اطمینان از اینکه تغییرات به درستی مدیریت و به کاربران اطلاع‌رسانی می‌شوند، می‌تواند به حفظ یکپارچگی API و ارتباط موثر با کاربران کمک کند.· افزودن شماره ورژن به URL API، مانند `/api/v1/resource`.· استفاده از هدرهای سفارشی HTTP برای تعیین ورژن.· انتخاب یک روش ورژن‌بندی که بهترین تعادل بین قابلیت دسترسی، سهولت استفاده و فنی را دارد.· سازگاری پسرو (Backward Compatibility): حفظ سازگاری با نسخه‌های قبلی در هنگام افزودن ویژگی‌های جدید یا ایجاد تغییرات.· اطمینان از اینکه تغییرات ورژن‌های جدید به خوبی مستند و به کاربران اطلاع‌رسانی می‌شوند.· فراهم کردن دوره‌های گذار برای کاربران تا بتوانند به نسخه جدید انتقال یابند.· حفظ سازگاری: اجتناب از شکستن تغییرات که ممکن است بر کاربران فعلی تأثیر منفی بگذارد.انعطاف‌پذیری و تطابقانعطاف‌پذیری و تطابق در طراحی و توسعه RESTful API‌ها اطمینان می‌دهد که API‌ها می‌توانند با تغییر نیازها و فناوری‌ها رشد کنند و همچنان مؤثر و مرتبط باقی بمانند. این امر نیازمند توجه مداوم به تجربه کاربری، ادغام‌پذیری و قابلیت توسعه‌پذیری است.•اطمینان از اینکه API برای انواع مختلف کلاینت‌ها، از جمله وب، موبایل، و سایر دستگاه‌های متصل، مناسب و قابل استفاده است.•توانایی سازگاری با تغییر نیازها و خواسته‌های کاربران بدون نیاز به بازطراحی کامل.•اطمینان از اینکه API به راحتی با سیستم‌های موجود و زیرساخت‌های نرم‌افزاری دیگر ادغام می‌شود.•به‌روز نگه داشتن API با تکنولوژی‌های جدید و استانداردهای صنعت.•طراحی API به شکلی که اجزای مختلف به راحتی قابل افزودن، تغییر یا حذف باشند.•درک دقیق نیازهای کاربران و پاسخگویی به آن‌ها در طراحی API.این چالش‌ها نشان‌دهنده‌ی طیف وسیعی از موضوعاتی است که توسعه‌دهندگان در هنگام کار با RESTful API‌ها با آن‌ها روبرو هستند. حل این چالش‌ها اغلب نیازمند ترکیبی از دانش فنی، تجربه عملی و درک عمیق از نیازهای کسب‌وکار است.پیچیدگی با نداشتن معماریمشکلاتی که ممکن است در نتیجه نداشتن یک معماری مناسب برای RESTful API‌ها ایجاد شود:1. کاهش کارایی و عملکرد: بدون یک معماری منظم، API‌ها ممکن است بار اضافی را بر روی سرور ایجاد کنند، منجر به پاسخ‌های کند و زمان بیشتر انتظار برای کاربران می‌شوند. این امر به ویژه در محیط‌های با ترافیک بالا به چشم می‌خورد.2. آسیب‌پذیری‌های امنیتی: معماری ناکافی می‌تواند باعث شود API‌ها در برابر حملات امنیتی مانند SQL Injection، Cross-Site Scripting (XSS)، و حملات Man-in-the-Middle آسیب‌پذیر باشند. مشکلات در مدیریت احراز هویت و مجوزها می‌توانند داده‌های حساس را در معرض خطر قرار دهند.3. پاسخ‌های نامناسب API: API‌هایی که به درستی طراحی نشده‌اند ممکن است داده‌های ناکافی یا بیش از حد لازم را بازگردانند، که منجر به کاهش کارایی و تجربه کاربری ضعیف می‌شود.به طور خلاصه، نداشتن یک معماری مناسب برای RESTful API‌ها می‌تواند به مجموعه‌ای از مشکلات عمده منجر شود که عملکرد کلی، امنیت، قابلیت نگهداری، و تجربه کاربری سیستم را تحت تأثیر قرار می‌دهد.مشکلات نگه‌داری و مقایس‌پذیریبدون یک معماری مناسب، نگهداری API‌ها می‌تواند به شکل‌های زیر دچار مشکل شود:1. کد ناکارآمد: کد نوشته شده بدون توجه به بهترین شیوه‌ها و استانداردها می‌تواند پیچیده، دشوار برای فهم و نگهداری باشد. این امر می‌تواند به افزایش زمان لازم برای شناسایی و رفع اشکالات منجر شود.2. به‌روزرسانی‌های دشوار: در صورتی که API به طور مداوم توسعه نیابد یا اگر ساختار API اجازه تغییرات آسان را ندهد، به‌روزرسانی‌ها می‌توانند بسیار دشوار و زمان‌بر باشند.3. وابستگی‌های پیچیده: در مواردی که API‌ها دارای وابستگی‌های پیچیده یا نامنظم با سایر بخش‌های سیستم هستند، تغییر یک جزء می‌تواند اثرات غیرمنتظره‌ای بر سایر اجزا داشته باشد.مشکلات مقیاس‌پذیری در RESTful API‌ها:1. عدم تحمل بارهای سنگین: API‌هایی که برای مقیاس‌پذیری طراحی نشده‌اند، ممکن است در برابر افزایش تعداد کاربران یا حجم درخواست‌ها نتوانند به خوبی عمل کنند، که منجر به کاهش سرعت پاسخگویی یا حتی خرابی‌های سیستم می‌شود.2. عدم انعطاف‌پذیری در برابر تغییرات: API‌هایی که نمی‌توانند به راحتی با تغییرات در محیط‌های تکنولوژی یا نیازهای کاربر تکامل یابند، ممکن است به سرعت منسوخ شوند.3. مدیریت منابع ناکارآمد: در صورتی که API‌ها به درستی منابع را مدیریت نکنند، ممکن است در شرایط بار بالا با محدودیت‌های منابع مواجه شوند، مانند کمبود حافظه یا CPU.بنابراین می‌توان گفت نگهداری و مقیاس‌پذیری هر دو جنبه‌های حیاتی در طراحی و توسعه RESTful API‌ها هستند. معماری نامناسب نه تنها می‌تواند منجر به افزایش هزینه‌ها و زمان صرف شده برای نگهداری شود، بلکه ممکن است اثر منفی بر عملکرد کلی سیستم داشته باشد، به ویژه در شرایطی که نیاز به مقیاس‌بندی و پاسخگویی به تقاضای افزایش یافته وجود دارد.مشکلات گسترش کد و انعطاف پذیریگسترش کد در API‌ها بدون یک برنامه‌ریزی و معماری مناسب می‌تواند به مشکلات زیر منجر شود:1. پیچیدگی افزایشی: افزودن ویژگی‌های جدید به API بدون در نظر گرفتن معماری کلی می‌تواند منجر به افزایش پیچیدگی کد شود. این امر می‌تواند خوانایی و نگهداری کد را دشوار کند.2. وابستگی‌های نامناسب: توسعه‌ی بی‌رویه API‌ها ممکن است به ایجاد وابستگی‌های پیچیده بین کامپوننت‌های مختلف منجر شود، که تغییر یک بخش می‌تواند اثرات غیرمنتظره‌ای بر سایر بخش‌ها داشته باشد.3. تست و اعتبارسنجی دشوار: با افزایش پیچیدگی کد، تست و اعتبارسنجی API‌ها می‌تواند بیشتر زمان‌بر و دشوار شود، که احتمال خطاها و نقایص را افزایش می‌دهد.انعطاف‌پذیری نامناسب در طراحی API می‌تواند منجر به چالش‌های زیر شود:1. عدم تطابق با تغییرات: API‌هایی که با انعطاف‌پذیری کافی طراحی نشده‌اند، ممکن است نتوانند به راحتی با تغییر نیازهای کاربران یا تکنولوژی‌های جدید سازگار شوند.2. ادغام دشوار با سیستم‌های دیگر: کمبود انعطاف‌پذیری می‌تواند ادغام API با سایر سیستم‌ها و اپلیکیشن‌ها را دشوار کند، که این امر می‌تواند بر کارآمدی کلی سیستم تأثیر منفی بگذارد.3. توسعه محدود: بدون انعطاف‌پذیری کافی، توسعه‌ی ویژگی‌های جدید یا تغییرات در API ممکن است محدود شود، که می‌تواند سیستم را از پیشرفت و به‌روزرسانی باز دارد.بنابراین، مشکلات گسترش کد و انعطاف‌پذیری در RESTful API‌ها می‌تواند به کاهش کارایی، افزایش پیچیدگی و کاهش قابلیت نگهداری منجر شود. برای مقابله با این چالش‌ها، طراحی دقیق و معماری مناسب، همراه با رعایت استانداردها و بهترین شیوه‌ها، برای اطمینان از یک سیستم پایدار، قابل اطمینان و قابل توسعه حیاتی است.معماری تدوین شدهانواع کامپوننت‌هاقبل از اینکه بخواهیم معماری رو بیان کنیم باید بلاک‌های سازنده API را بدانیم. در یک API کامپوننت‌‌های مختلفی وجود دارد که به صورت کلی میتوان به کامپوننت‌های اصلی و کمکی تقسیم‌بندی کرد. کامپوننت‌های کمکی مانند کامپوننت اتصال به دیتابیس، ارسال پیامک، درگاه پرداخت، و غیره می‌باشند و عملا منطقی از کسب و کار درون آن وجود ندارد.در مقابل کامپوننت‌های اصلی هستند که از کامپوننت‌های کمکی استفاده میکنند تا یک منطقی از کسب و کار را پیاده‌‌سازی کنند. از این دسته میتوان به کامپوننت‌هایی مثل کامپوننت کاربران، سفارشات، انبارداری، و غیره اشاره کرد.معماری سه لایهدر معماری سه لایه اصلی وجود دارد که بخش‌های اصلی API درون آنها خلاصه میشود.لایه Handlerاین لایه نقطه اتصال به API است که ورودی و خروجی متناسب با درخواست کاربر اتفاق پردازش میشود. هر چیزی که شامل بررسی درخواست ورودی، اعتبارسنجی کاربر، بررسی سطح دسترسی، اعتبارسنجی درخواست کاربر، محدود کردن درخواست‌ها و غیره در این لایه اتفاق می‌افتد. پس به صورت کلی در هندلرها سه کار مهم صورت میگیرد: ۱. پردازش ورودی۲. صدا کردن فانکشن مرتبط از لایه پایین‌تر۳. پردازش خروجیلایه اصلیدر این لایه منطق اصلی کسب و کار اتفاق می‌افتد یعنی قواعد در این بخش پیاده‌سازی شده‌اند و ارزش API بیشتر به این لایه مربوط میشود. به عنوان نمونه ــ یک کاربر میتواند یک کالا را رزرو کند و تا ۲۴ ساعت مهلت پرداخت داشته باشد ــ یک قاعده کسب و کار است. یا به عنوان مثال API یک فروشگاه اینترنتی میتواند کامپوننت‌های اصلی کاربران، سفارشات، سابقه، انبارداری، و مدیریت را در لایه اصلی خود داشته باشد.لایه وابستگیاین لایه شامل دو بخش دیتا که مربوط به دیتابیس و هر نوع ارتباطی با مخازن داده و شامل بخش کامپوننت‌های کمکی می‌باشد.قواعد و طراحی کلیبه صورت کلی نکاتی وجود دارد که در ادامه آمده است و باید رعایت شوند تا از موارد مثل tight coupling یا cyclic dependency جلوگیری شود:۱. زمانی که میخواهیم از یک کامپوننت اصلی استفاده کنیم، باید از اینترفیس آن کامپوننت استفاده کنیم تا از وابستگی به concrete جلوگیری کنیم. اینکار کمک میکند تا testability را افزایش دهیم.۲. زمانی که از یک کامپوننت اصلی A میخواهیم به یک کامپوننت اصلی دیگری B وابسته باشیم باید یک اینترفیس از فانکشنالیتی‌های محدودی از B نیاز داریم را سمت A ایجاد کنیم و از آن استفاده کنیم. بدین صورت کامپوننت اصلی به یک اینترفیس وابسته است. کامپوننت اصلی نیز چون signature مشابه با اینترفیس را دارد آن را پیاده‌سازی کرده در نتیجه موقع پاس دادن وابستگی‌ها میتوانیم به راحتی A را در جای اینترفیس قرار دهیم.۳. برای تغییرات مناسب باشند و روی کامپوننت‌های دیگر تاثیر نگذارند، میتوانیم هر بخشی که منطق مجزایی دارد را یک کامپوننت اصلی جدا در نظر بگیریم. و مواردی که منطق‌های وابسته دارند را زیر مجموعه یک کامپوننت‌اصلی به عنوان یک sub component تعریف کنیم.۴. هر کامپوننت یک ساختار دیتای کانفیگ دارد که تنظیمات مربوط به کامپوننت درون آن وجود دارد.کامپوننت‌های حیاتی و وظایف آن‌هاکامپوننت loggerکامپوننتی است که برای لاگ زدن اتفاقات درون نرم‌افزار استفاده میشود. میتواند یک پیاده‌سازی و نسخه extend شده از لاگر استاندارد باشد یا instatiation و کانفیگ کردن یک لاگر خارجی که در نهایت به ما یک interface میدهد تا بتوانیم از آن در کل پروژه برای لاگ زدن استفاده بکنیم.کامپوننت modelکامپوننتی است که در‌ آن مدل‌های مختلف نرم‌افزار تعریف شده است. مدل‌ درخواست‌های ورودی و خروجی، خطا‌های مختلف درون برنامه، و مدل‌های دیتابیس شامل این دسته میشوند.کامپوننت databaseکامپوننتی است که برای ارتباط با دیتابیس استفاده میشود در اینجا تمامی فانکشنالیتی‌های مختلف مرتبط با دیتا پیاده‌سازی میشود.کامپوننت configیک کامپوننت اصلی است که تنظیمات کامپوننت‌های مختلف برنامه و نحوه دریافت آن به عنوان ورودی تعریف شده است.کامپوننت utilsتمامی فانشکنالیتی‌های کوچک برنامه که برای یک کامپوننت بسیار کوچک هستند را درون اینجا به صورت کلی تعریف میکنیم.کامپوننت httpاز این کامپوننت برای جواب دادن به درخواست هایی که به سمت API می‌آید استفاده میشود. همچنین درون آن middleware هایی که مربوط به rate limiting, authentication, authorization و غیره مربوط میشود، وجود دارد.معماری ارائه شده در عملنمونه پیاده‌سازی پروژهیک پروژه نمونه ایجاد شده برای اینکه بررسی کنیم با اعمال قوانین معماری چه اتفاقی می‌افتد. در ادامه یک پروژه از یک اپلیکیشن خرید انلاین میبینیم که سه بخش اصلی انبارداری، کاربران، و سفارشات درون آن وجود دارد. هر یال درون گراف از وابستگی به وابسته حرکت میکند. در حال حاضر از دیتابیس به صورت مستقیم درون کامپوننت‌های اصلی استفاده شده است که وابستگی منطق بیزینس را به پیاده‌سازی دیتابیس وابسته میکند.بعد از اعمال یکی از قوانین وابستگی، ارتباط بین دیتابیس و کامپوننت‌های اصلی از بین رفته است. این اتفاق به ما کمک میکند تا به راحتی بتوانیم کامپوننت‌های اصلی را تست کنیم و همچنین در صورت تغییر فانکشنالیتی دیتابیس، تغییرات بر روی کامپوننت‌های اصلی اثر نگذارند. در نتیجه testability و maintainability بهبود پیدا میکند.مقایسه عملکردبه صورت کلی پیاده‌سازی این معماری overhead کمی دارد در نتیجه بر روی performance تاثیری نمیگذارد. همچنین به maintainability و testability نیز کمک میکند. دیتابیس می‌تواند حاوی بخش‌های گوناگونی از جمله بخش کاربران، بخش محصولات، بخش سفارشات و غیره باشد. هر بخش از یک برنامه کاربردی لزوماً به تمام اطلاعات موجود در پایگاه داده نیاز ندارد و تنها به برخی از آن‌ها وابسته است. بنابراین به جای ارتباط مستقیم با کل پایگاه داده، یک رابط (Interface) تعریف می‌کنیم که تنها شامل متدهای مورد نیاز برای دسترسی به بخش‌های مورد نیاز باشد. این کار باعث می‌شود فقط بخش لازم از پایگاه داده برای این بخش از برنامه فراخوانی شود. در نتیجه هر گونه تغییر در بخش‌های دیگر پایگاه داده، تاثیری روی این بخش ندارد. این موضوع باعث افزایش انعطاف‌پذیری و تغییر پذیری و قابلیت نگهداری برنامه می‌شود. همچنین باعث سهولت در تست و اشکال‌زدایی برنامه می‌گردد، زیرا در زمان تست نیازی به پیاده‌سازی کل پایگاه داده نیست و تنها کافی است قسمت‌های مورد نیاز شبیه‌سازی شوند.قابل ذکر است که در این معماری امکان اضافه کردن تاکتیک‌های مختلف فراهم شده است و به راحتی قابل اضافه کردن می‌باشد که میتوان برای Availability و دیگر bility ها استفاده کرد. به عنوان مثال، در ماژول HTTP، استفاده از اینترفیس‌ها امکان ادغام آسان میان‌افزارها (middleware) را فراهم می‌آورد. به این صورت که هر میان‌افزاری که این اینترفیس را پیاده‌سازی کند، می‌تواند به راحتی در معماری سیستم جایگزین شود یا اضافه گردد. این رویکرد، سازگاری و قابلیت توسعه‌ی سیستم را بهبود بخشیده و امکان تنظیم و شخصی‌سازی عملکرد سیستم بر اساس نیازهای خاص را فراهم می‌آورد.ارزیابی و اعتبارسنجیدر طراحی RESTful API‌ها، به‌کارگیری یک معماری پیشرفته که سطح بالایی از انتزاع را فراهم می‌کند، تست‌پذیری و قابلیت نگهداری را به طرز چشمگیری افزایش می‌دهد. انتزاع به توسعه‌دهندگان امکان می‌دهد تا پیچیدگی‌های داخلی سیستم را پنهان کرده و رابط‌های ساده‌تری برای تعامل با سیستم فراهم آورند. این رویکرد موجب می‌شود که ماژول‌ها بتوانند با حداقل وابستگی به یکدیگر توسعه یابند و به صورت مستقل فعالیت کرده و در برابر تغییرات محافظت شوند، به طوری که تغییر در یک بخش، بقیه‌ی سیستم را تحت تأثیر قرار نمی‌دهد و این همان تغییر پذیریِ بالا است. استقلال ماژول‌ها نه تنها تست‌کردن را آسان‌تر می‌کند، بلکه با امکان موک کردن واحدها در زمان تست، اطمینان بیشتری از صحت عملکرد API در شرایط مختلف فراهم می‌آورد. این دستاوردها نشان می‌دهد که چگونه یک طراحی دقیق و مبتنی بر استانداردهای مدرن، می‌تواند به توسعه‌دهندگان کمک کند تا API‌هایی قابل اعتماد، قابل نگهداری و آسان برای تست ایجاد کنند.ارزیابی معماری ارائه شدهدر این تحقیق یک نمونه پروژه را به عنوان سمپل در نظر گرفته و معماری ارائه شده را پیاده سازی کردیم. بکارگیری معماری پیشنهادی در پروژه‌ به ما اجازه داد تا کانفلیکت را به طور مؤثری کاهش دهیم و فرآیند ایجاد تغییرات را روان‌تر کنیم. این تجربه نشان داد که با اجرای یک ساختار مناسب، می‌توانیم کد را به شیوه‌ای سازماندهی کنیم که وابستگی‌ها کاهش یافته و به طور مؤثر تری مدیریت شوند.یکی از نتایج قابل توجه دیگر اجرای این معماری این بود که شکل وابستگی ها به میزان زیادی بهبود یافت. ما مشاهده کردیم که به طور کلی وابستگی های کمتری وجود دارد و آنها به شیوه ای صحیح تر ساختار یافته بودند. این تأثیر مثبتی بر روی تغییر پذیری و قابلیت نگهداری پایگاه کد داشت.به کارگیری این معماری نه تنها به کاهش کانفلیکت کمک کرد بلکه به ما اجازه داد تا از تاکتیک‌های مختلف برای بهبود ویژگی‌های کیفی سیستم به راحتی بهره ببریم و امکان ادغام عملکردهای جدید را فراهم آورد، در حالی که انعطاف‌پذیری ساختاری پروژه حفظ شد.به طور کلی، اتخاذ این معماری ارائه شده نه تنها کانفلیکت‌ها را کاهش داد، بلکه قابلیت نگهداری کد را نیز افزایش داد و به ما این امکان را داد که از تاکتیک‌های مختلف به طور موثر در سراسر سیستم خود استفاده کنیم. با اطمینان از مدیریت وابستگی مناسب با وابستگی‌های کمتر، می‌توانیم به طور یکپارچه عملکردهای اضافی را با حفظ انعطاف‌پذیری در ساختار پروژه خود ادغام کنیم.مقایسه با روش‌های موجودمیتوان گفت در حال حاضر قالب و معماری مشخصی در این زمینه تعریف نشده و در هر نرم افزاری روشی مناسب به کار برده می‌شود و حالت استانداردی وجود ندارد. با استفاده از این معماری تعریف شده، میتوان تا حدودی شرایط را بهبود داد.پروژه‌های متعددی می‌توانند از این معماری استفاده کنند که به مرور این معماری به عنوان یک قالب استانداردی استفاده شود و کد یک ساختار مشخصی پیدا میکند.این استراتژی نه تنها کیفیت کلی نرم‌افزار را بهبود می‌بخشد، بلکه زمینه‌ساز ایجاد یک استاندارد صنعتی می‌شود که می‌تواند به عنوان یک قالب عمومی برای طراحی API‌ها استفاده شود. این معماری، با ایجاد ساختاری ثابت و قابل پیش‌بینی، تسهیل در فرایند یادگیری و هماهنگی برای اعضای جدید تیم را ممکن می‌سازد(میتواند learning curve را آسان‌تر و سریع‌تر کند) که این رویکرد به افزایش تست‌پذیری و قابلیت نگهداری کمک می‌کند.محدودیت‌‌ها و چالش‌هامواجهه با منطق پیچیده در طراحی نرم‌افزار، به ویژه در توسعه API‌ها، یک چالش بزرگ است. وقتی که منطق درونی برنامه پیچیده می‌شود، مدیریت ارتباطات بین کامپوننت‌های مختلف دشوارتر شده و ممکن است به افزایش نامتناسب تعداد اینترفیس‌ها منجر شود. این امر می‌تواند ساختار کد را پیچیده کند و تعریف واضح و منسجم اینترفیس‌ها را به چالش بکشد. به عنوان مثال، در بخش منطق، ممکن است نیاز داشته باشیم که مستقیماً از چندین مؤلفه دیگر استفاده کنیم. این پیچیدگی هنگام تلاش برای برقراری ارتباط بین این مؤلفه ها به وجود می آید زیرا آنقدر پیچیده می شود که تعریف اینترفیس‌ها تقریباً بی معنی به نظر می رسد.برای توضیح بیشتر این چالش، اجازه دهید مثالی را در نظر بگیریم که در آن یک کامپوننت A داریم. در این کامپوننت A، باید تابعی از کامپوننت B را وارد کنیم. با این حال، کامپوننت B خود به تابعی از کامپوننت C متکی است که به نوبه خود به تابع دیگری بستگی دارد. تابع از کامپوننت D...و غیره. همانطور که می توانید تصور کنید، این اثر آبشاری منجر به این می شود که ما مجبور باشیم چندین اینترفیس‌ را فقط برای یک اتصال واحد تعریف کنیم.در چنین موقعیت‌هایی، تعریف اینترفیس‌های متعدد برای مدیریت ارتباطات می‌تواند به افزایش نامناسب تعداد اینترفیس‌های مورد نیاز ،که overhead زمانی ایجاد می‌کند، و به افزایش پیچیدگی معماری کلی و دشواری در فهم و نگهداری کد و ایجاد تغییرات در آن منجر شود. این مشکل، در زمانی که یک کامپوننت به توابع متعدد از کامپوننت‌های دیگر وابسته است نیز، نمایان می‌شود.برای مقابله با این چالش‌ها، استفاده از الگوهای طراحی و معماری مانند میکروسرویس‌ها، که تاکید بر استقلال و کاهش وابستگی‌های متقابل دارند، توصیه می‌شود. این رویکرد می‌تواند به کاهش پیچیدگی‌های مرتبط با منطق پیچیده و بهبود قابلیت نگهداری و تست‌پذیری کد کمک کند. یک راهکار دیگر که میتواند به کار برده شود merge کردن مناسب کامپوننت ها است که مشکل افزایش بیش از حد تعداد اینترفیس‌ها تا حدودی بهبود می‌دهد.مشکلات احتمالی و محدودیت‌هادر عرصه توسعه نرم‌افزار، پیاده‌سازی یک معماری استاندارد برای RESTful API‌ها به عنوان یک چالش عمده مطرح است، به ویژه با توجه به تنوع وسیع API‌ها و مدل‌های متفاوتی که در پروژه‌های متعدد استفاده می‌شوند. با این حال، معماری پیشنهادی می‌تواند به عنوان یک الگوی اصلی در نظر گرفته شود. استفاده از این معماری در پروژه‌های مختلف، علی‌رغم اینکه فرصتی برای شناسایی و رفع نقاط ضعف فراهم می‌آورد، یک فرآیند زمان‌بر است که نیازمند بررسی‌های مداوم و بازخورد‌های عملی برای بهینه‌سازی است. این پروسه می‌تواند مدت زمان زیادی به طول بیانجامد که یک محدودیت اساسی محسوب میشود.جمع‌بندیدر ابتدای این تحقیق، مطالعات کلی در خصوص ساختار و معماری APIها انجام شد. سپس برای درک بهتر وابستگی‌ها ،ابزاری طراحی و پیاده‌سازی شد که قادر است وابستگی‌های بین کامپوننت‌ها را تجزیه و تحلیل کند. این ابزار با دریافت ساختار و معماری یک API، وابستگی‌های موجود در آن را شناسایی و به صورت گرافیکی نمایش می‌دهد.همان‌طور که در بخش‌های قبلی نیز بحث شده است، وابستگی‌های نامناسب و زیاد می‌تواند مشکلات و آسیب‌پذیری‌هایی را در API ایجاد کند. بنابراین، معماری مناسب برای API بسیار حائز اهمیت است تا بتوان این مشکلات را به حداقل رساند.به منظور اعتبارسنجی معماری پیشنهادی، آن را به صورت عملی بر روی یک پروژه نمونه پیاده‌سازی کردیم.پس از پیاده‌سازی معماری پیشنهادی، مشاهده کردیم که ویژگی‌هایی همچون تست‌پذیری، قابلیت نگهداری و تغییرپذیری بهبود قابل‌توجهی پیدا کرد. به عنوان مثال، نوشتن تست‌های واحد برای هر اندپوینت به راحتی امکان‌پذیر شد. همچنین در صورت نیاز به تغییر در یک اندپوینت، تاثیر آن محدود به همان اندپوینت بود و بقیه اندپوینت‌ها تحت تاثیر قرار نمی‌گرفتند.البته هنوز چالش‌ها و محدودیت‌هایی وجود دارد که باید در تحقیقات آینده بررسی شوند. به عنوان مثال، می‌توان با بهینه‌سازی‌های بیشتر، ویژگی‌هایی مانند دسترس‌پذیری و عملکرد سیستم را نیز بهبود بخشید.با این حال، نتایج حاصل از پیاده‌سازی این پروژه نشان می‌دهد که معماری پیشنهاد شده می‌تواند به نحو چشمگیری کیفیت سیستم‌های مبتنی بر وب‌سرویس را ارتقا دهد و شرایط کلی توسعه، تست و نگهداری آن‌ها را بهبود بخشد.مراجع· RESTful web API designhttps://www.freecodecamp.org/news/rest-api-design-best-practices-build-a-rest-api/· کتاب clean architecture· کتاب رفرنس درس· https://hackernoon.com/go-design-patterns-an-introduction-to-solid· https://en.m.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenterاین مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است فاطمه عصمتی فاطمه عصمتی Fri, 02 Feb 2024 22:29:39 +0330 https://virgool.io/@m_46173657/%D9%85%D8%B1%D9%88%D8%B1%DB%8C-%D8%A8%D8%B1-%DA%86%D9%86%D8%AF%DB%8C%D9%86-%D8%B3%D8%AE%D9%86%D8%B1%D8%A7%D9%86%DB%8C-%D9%86%D8%B3%D8%A8%D8%AA%D8%A7%D9%8B-%D8%AC%D8%AF%DB%8C%D8%AF-%D9%85%D8%B1%D8%AA%D8%A8%D8%B7-%D8%A8%D8%A7-%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-mj9zpahayina در اینجا خلاصه‌ای از ویدئو با عنوان " Keynote by Magnus Martensson at Software Architecture Conference 2023" بیان شده است:در این ویدئو، مگنوس مارتنسون خود را معرفی کرده و علاقه‌مندی اش به فناوری‌های ابری و شرکت در جامعه Global Azure را بیان کرده است. او همچنین به اهمیت رویدادهای جامعه و به اشتراک‌گذاری دانش در زمینه معماری نرم‌افزار توجه دارد.در طول سخنرانی به طور مکرر به تکنولوژی‌های ابری اشاره می‌شود .ارائه دهنده تأکید دارد که اگرچه بحث‌های او اغلب شامل مثال‌های مرتبط با ابر است، اصولی که او بحث می‌کند به طور کلی به معماری نرم‌افزار قابل اعمال هستند.در ادامه، مگنوس مارتنسون به نقش معماران نرم‌افزار پرداخته و آنها را به عنوان "نگهدارندگان شعله" توصیف می‌کند. معماران نرم‌افزار مسئولیت دارند که اطمینان حاصل کنند معماری نرم‌افزار با اهداف و نیازهای پروژه هماهنگ باشد. این نقش اصلی معماران در تضمین کیفیت و انطباق معماری نرم‌افزار با اهداف پروژه است و آنها باید به عنوان یک پل ارتباطی میان تیم توسعه و اهداف کسب‌وکار عمل کنند. همچنین او به موضوع اجتناب از فناوری‌های مد روز می‌پردازد. او توصیه می‌کند که معماران نرم‌افزار نباید به صورت کورانه و بدون تفکر به موضوعات مد روز پیوند بخورند یا فناوری‌هایی را انتخاب کنند فقط به خاطر اینکه محبوب هستند. به عنوان مثال، او از Kubernetes استفاده می‌کند و توجه می‌کند که این ابزار قدرتمندی است، اما نباید بدون درک واضح از تبعات و انطباق آن با نیازهای پروژه به کار گرفته شود. معماران نرم‌افزار باید با دقت و اهمیت به انتخاب فناوری‌ها و ابزارها پرداخته و تصمیم‌گیری‌های آنها را بر اساس نیازهای واقعی پروژه انجام دهند، به جای اینکه به صورت بی‌تفکر و مطلق به رویکردهای مد روز عمل کنند.در ادامه موضوع "قفل شدن به تامین‌کننده (Vendor Lock-In)" در زمینه خدمات ابری صحبت میشود که اهمیت انتخاب آگاهانه خدمات ابری بسیار مهم است. شرکت‌ها باید موازنه‌گرانه و با دقت تصمیم‌هایی در مورد استفاده از خدمات ابری بگیرند، زیرا وابستگی به تامین‌کنندگان خاص می‌تواند به مشکلات و ریسک‌هایی مانند مشکلات مالی و عملیاتی، محدودیت‌های استراتژیک، و کاهش انعطاف‌پذیری منجر شود. معماران نرم‌افزار باید تصمیم‌های معماری بگیرند که امکان حمل و تطبیق برنامه‌ها را با فناوری‌ها یا خدمات مختلف فراهم کنند. از انتزاعات مانند رابط‌ها و پروکسی‌ها استفاده شود تا برنامه‌ها به طور زیادی به یک فناوری یا خدمت خاص وابسته نشوند. این رویکرد امکان مهاجرت یا تطبیق برنامه‌ها با تغییرات درخواستی یا فناوری‌ها را بهبود می‌بخشد و ریسک‌های مرتبط با وابستگی نادرست به تامین‌کنندگان را کاهش می‌دهد.مگنوس مارتنسون به اهمیت مسئولیت‌های رهبری معماران تأکید می‌کند. او بیان می‌کند که معماران باید الگوی صحیحی برای تیم‌های خود قرار دهند و در تصمیم‌گیری‌ها، به ویژه در انتخاب فناوری‌های جدید، مسئولیت پذیر باشند.یکی از مسائل مهمی که در سخنرانی مطرح شده، تغییرات مداوم در معماری نرم‌افزار است. معماران نرم‌افزار باید برنامه‌ریزی کنند تا به تغییرات آینده آماده باشند و واکنشگرا باشند؛ به این معنا که بتوانند زمانی که نیاز باشد، تغییراتی را در معماری نرم‌افزار اعمال کنند. در سخنرانی خود مثال‌هایی واقعی در مورد نکات گفته شده بیان میشود. این مثال‌ها به عنوان نمونه‌های واقعی نشان می‌دهند که تصمیمات معماری چگونه تأثیرات واقعی و ملموسی در عملکرد و موفقیت یا شکست یک پروژه می‌توانند داشته باشند.بنابراین تصمیم‌گیری‌های مسئولانه و رهبری در معماری نرم‌افزار بسیار اهمیت دارند. به معماران توصیه میشود که به انتخاب‌های دقیق در فناوری، انعطاف‌پذیری، و رهبری مسئولانه اهمیت داده و تیم‌ها را به سمت رویکردهای معماری پایدار هدایت کنند.در اینجا خلاصه‌ای از ویدئو با عنوان " Democratising Software Architecture • Eoin Woods • GOTO 2023" بیان شده است:اوین وودز خود را معرفی کرده و پس‌زمینه حرفه‌ای خود در مهندسی نرم‌افزار و معماری را به اشتراک گذاشته است. او تأکید دارد که به اشتراک‌گذاری دانش و تجربیات در جامعه نرم‌افزاری اهمیت دارد. سپس به تحلیل تغییراتی که در توسعه نرم‌افزار در طول سال‌ها رخ داده است، به ویژه به تبدیل دیجیتال، پرداخته است. این تبدیل دیجیتال منجر به ظهور پلتفرم‌های نرم‌افزاری شده است که از برنامه‌های مستقل به عنوان اساسی برای ارائه خدمات و قابلیت‌ها استفاده می‌شوند..ویژگی‌های پلتفرم های نرم افزاری که در ویدئو به آن ها اشاره شده است شامل همیشه روشن بودن، تکامل غیرقابل پیش بینی، نیاز به رفتار هوشمند، به روز رسانی مداوم، اتصال بالا، رابط های متعدد و توسعه پذیری است. وودز بر اهمیت این پلتفرم ها در حمایت از enterprises های بزرگ و خدمات متصل به اینترنت تاکید می کند. او همچنین چالش های پیش روی در توسعه پلتفرم ها را مورد بحث قرار می دهد، به ویژه زمانی که اهداف نهایی یا مشکلات تجاری در ابتدا به وضوح تعریف نشده باشند. توجه به نیاز به ساخت پلتفرم هایی با قابلیت تکامل و تطبیق بسیار مهم است.تأثیر خدمات چابک و ابری: سخنران به چگونگی تأثیر قابل توجه روش های چابک و در دسترس بودن خدمات ابری را بر روی شیوه های مهندسی نرم افزار مدرن اشاره میکند. این پیشرفت‌ها تیم‌ها را قادر می‌سازد تا در ارائه راه‌حل‌های نرم‌افزاری، چابک‌تر، مقرون‌به‌صرفه‌تر و کارآمدتر باشند و در عین حال هنگام استفاده از سرویس های ابری و روش های چابک، مهم است که خطر وابستگی بیش از حد به خدمات یک ارائه دهنده خاص در نظرگرفته شوند.اوین وودز به چالش کشیدن رویکرد سنتی برنامه‌ریزی معماری جزئی و پیشنهاد یک رویکرد پویا و قابل تطبیق به معماری می‌پردازد. این بدان معناست که به جای ایجاد یک برنامه معماری دقیق در ابتدای یک پروژه و پایبندی محکم به آن، او تشویق می‌کند که معماران تغییرات را به عنوان بخشی از فرآیند معماری در نظر بگیرند و تصمیمات معماری را با پیشرفت پروژه تطابق دهند. باید انعطاف‌پذیری داشته باشیم و به تغییراتی که در نیازها و شرایط پروژه رخ می‌دهد، پاسخ دهیم و به معماری به صورت پیوسته فرصت دهیم تا تطور کند. شش اصل مهم "معماری پیوسته" بیان شده است. این اصول شامل سازماندهی بر اساس محصولات، تمرکز بر ویژگی‌های کیفی، پذیرش تغییر، طراحی برای تغییر، ساخت با مدنظر داشتن استقرار و عملیات، و هماهنگی ساختار تیم با ساختار نرم‌افزاری می‌شوند. این اصول به انعطاف‌پذیری و تطبیق بهتر نرم‌افزار با تغییرات و نیازهای پروژه کمک میکند.در ادامه، اوین وودز به ایده "معماری به عنوان یک مسئولیت مشترک" اشاره می‌کند. او تأکید می‌کند که معماری نرم‌افزار نباید تنها مسئولیت معماران باشد و باید به عنوان یک وظیفه مشترک بین تمام اعضای تیم معنا شود. وی به اهمیت درک و تطبیق معماری با تغییرات و نیازهای متغیر پروژه تأکید می‌کند. این مفهوم به تشویق همکاری و تعامل بین اعضای تیم برای تحقیق بهترین معماری نرم‌افزار و پیشبرد اهداف پروژه کمک می‌کند.به طور کلی هدف این کنفرانس تأکید به این است که معماران نرم‌افزار و تیم‌ها باید تغییر و انعطاف‌پذیری را در رویکرد به معماری نرم‌افزار خود پذیرا باشند. به اهمیت یادگیری پیوسته و تطور در زمینه معماری نرم‌افزار اشاره میشود. وودز به تغییرات در منظر معماری نرم‌افزار اشاره می‌کند و اهمیت یک رویکرد همکارانه و قابل تطبیق به مسئولیت‌های معماری را تأکید می‌کند.در اینجا خلاصه‌ای از ویدئو با عنوان "Programming's Greatest Mistakes • Mark Rendle • GOTO 2023" بیان شده است:رندل محتوای آموزنده را با صحبت‌های سرگرم کننده ترکیب می کند و درس های ارزشمندی در مورد اهمیت برنامه نویسی دقیق و عواقب احتمالی خطاهای نرم افزار در این کنفرانس ارائه می دهد.او با یک داستان شخصی از حرفه خود شروع می کند، جایی که به طور تصادفی فایل های پرس و جو را در نرم افزار HR خراب کرد. این حکایت زمینه را برای بحث در مورد خطاهای جدی تر و تاثیرگذارتر در صنعت فراهم می کند.او به بررسی باگ Y2K می پردازد. این اشکال نتیجه استفاده از دو رقم برای سال در تاریخ بود که با نزدیک شدن به سال 2000 منجر به خرابی احتمالی سیستم شد. تلاش های بسیاری برای رفع این اشکال انجام شد و حدود نیم تریلیون دلار هزینه داشت. رندل یک باگ جدیدتر در Microsoft Exchange را بیان می‌کند، که در آن سیستم نمی‌تواند تبدیل تاریخ خاصی را انجام دهد. این مثال نشان می دهد که مشکلات مشابه با باگ Y2K هنوز در سیستم های مدرن رخ می دهد. همچنین در این ویدئو مشکل 2038 Unix Time Overflow بیان شده است، جایی که مقدار زمان 32 بیتی یونیکس سرریز می شود و باعث ایجاد مشکلاتی مشابه Y2K می شود.یک مشکلی که در ویدئو اشاره شده بود این بود که در جایی اسامی سگ‌ها با اعداد رومی ذخیره میشدند ولی سیستم نمی‌توانست نام‌های فراتر از عدد 37 را مدیریت کند، که نشان‌دهنده یک مشکل غیرعادی اما واقعی است که ناشی از انتخاب نمایش داده‌های خاص است.رندل با انتقاد از پیچیدگی و ناکارآمدی نرم افزارها و فرآیندهای سازمانی، به Scaled Agile Framework به عنوان نمونه ای از پیچیدگی بیش از حد در صنعت اشاره میکند. او استدلال می کند که چنین چارچوب هایی می توانند پیچیدگی های غیرضروری را به توسعه نرم افزار اضافه کنند.خطای ممیز شناور Intel Pentium: رندل با بحث درباره اشتباه پرهزینه اینتل توضیح می دهد که چگونه واحد ممیز شناور پردازنده پنتیوم آنها منجر به محاسبات نادرست شده است. این خطا منجر به ایجاد هزینه‌ی 475 میلیون دلاری شد که نشان دهنده ریسک بالای اشکالات سخت افزاری بود.مفهوم «Null» یک اشتباه میلیارد دلاری در این ویدئو خوانده شده است. Null توسط تونی هور معرفی شده است و دلیل خوانده شدن آن به عنوان یک اشتباه، ایجاد خطاها و مسائل متعددی در برنامه نویسی است. این بخش از گفتگو بر تأثیر مفاهیم اساسی برنامه نویسی بر قابلیت اطمینان نرم افزار تأکید می کند.رندل به فروپاشی مرکز مدنی هارتفورد اشاره میکند که در آن خطاهای برنامه نویسی در نرم افزار CAD منجر به خرابی ساختاری در یک ساختمان شد که 90 میلیون دلار هزینه داشت. این مورد ضررهای دنیای واقعی را نشان می دهد که می تواند از خطاهای نرم افزاری ناشی شود.در پایان ویدئو از داستان نایت کپیتال گروپ، یک شرکت خدمات مالی که 440 میلیون دلار در کمتر از یک ساعت به دلیل نقص نرم افزاری در الگوریتم های معاملاتی خود از دست داد، گفته شده است.هدف رندل از بیان این، برجسته کردن پتانسیل زیان مالی فاجعه بار ناشی از خطاهای نرم افزاری است.در اینجا خلاصه‌ای از ویدئو با عنوان " Software Design in the 21st Century - Martin Fowler - XConf Thailand 2019" بیان شده است:فاولر با تضاد توسعه نرم افزار چابک با رویکردهای برنامه ریزی محور دهه 1990 شروع می کند. او توضیح می‌دهد که روش‌های چابک به عنوان پاسخی به محدودیت‌های فرآیندهای سنتی و سخت مبتنی بر برنامه‌ریزی پدیدار شدند. Agile به جای پایبندی دقیق به یک برنامه از پیش تعریف شده، بر سازگاری و پاسخگویی به تغییرات تاکید دارد.در رویکردهای برنامه ریزی محور، برنامه ریزی و اجرا جدا از هم هستند که اغلب توسط افراد مختلف انجام می شود. اما Agile، برنامه ریزی و اجرا را ادغام می کند و بر سازگاری و پاسخگویی تأکید دارد. روش های سنتی بر برنامه ریزی پیش بینی کننده تمرکز می کنند، جایی که موفقیت با پایبندی به برنامه سنجیده می شود. چابک این را به برنامه‌ریزی تطبیقی تغییر می‌دهد، جایی که موفقیت با توانایی پاسخگویی به تغییرات سنجیده می‌شود. روش های برنامه ریزی محور اغلب فرآیندها را مستقل از افرادی که آنها را اجرا می کنند می بینند. Agile این را تغییر می دهد و از فرآیندهایی حمایت می کند که توسط تیم ها بر اساس شرایط خاص آنها طراحی شده است.مارتین فاولر به مدل Agile Fluency اشاره می‌کند. این مدل یک چارچوب است که تأکید دارد تیم‌ها از طریق مراحل مختلفی از چابکی (Agility) پیشرفت می‌کنند و در مراحل مختلف چابکی تکامل می‌یابند، که هر کدام به مجموعه‌ای از مهارت‌ها و تمرکز نیاز دارند. او در این بخش تأکید می‌کند که مهارت‌ها و تمرین‌های فنی در دستیابی به چابکی بسیار اهمیت دارند و به تعدادی از تمرین‌ها و مهارت‌های کلیدی اشاره می‌کند که نقش مهمی در دستیابی به چابکی ایفا می‌کنند:· (Continuous Integration) یکی از مهمترین تمرینات در روش‌های چابک است. این تمرین به معنای ادغام مکرر تغییرات کد به شاخه اصلی کد یا مخزن اصلی می‌باشد. این تمرین به جلوگیری از ادغام‌های پیچیده و خطاگیرانه کمک می‌کند و با تضمین ادغام مکرر تغییرات، مشکلات ادغام را در زمان به موقع شناسایی می‌کند و تضمین می‌کند که پایگاه کد در طول چرخه توسعه پایدار و قابل اعتماد باشد.· در روش‌های چابک، تست‌های مکرری برای هر بخش از عملکرد نرم‌افزار نوشته میشود و کد به صورت مداوم بازنویسی شود. به این معنی که توسعه‌دهندگان به صورت مداوم تست می‌نویسند و کد را بهبود می‌بخشند تا کیفیت و قابلیت تغییر آسان نرم‌افزار را تضمین کنند. این کار منجر به داشتن یک کد قابل نگهداری تر و امکان تطبیق سریع‌تر کد با تغییرات و نیازهای جدید می‌شود.· Self-Testing Code به معنای نوشتن تست‌هایی است که به عنوان یک سیستم تشخیص خطا در کد عمل می‌کنند و به حفظ کیفیت کد و امکان بازنویسی کد کمک می‌کنند.مارتین فاولر به چالش‌هایی که در اتخاذ روش‌های چابک وجود دارد اشاره می‌کند و تأکید دارد که این انتقال نیاز به تغییر فرهنگ در تیم‌ها و سازمان‌ها دارد. او تاکید می‌کند که مسیر چابکی آسان نیست و به تعهد و تلاش نیاز دارد. فرآیندهای چابک باید به شرایط خاص تیم یا پروژه تطابق پیدا کنند. در چابکی هیچ راه حل یک‌اندازه ‌برای‌همه وجود ندارد و تیم‌ها باید تکنیک‌ها را بر اساس نیازها و متن خاص خود انتخاب کنند.به طور خلاصه میتوان گفت در این سخنرانی به توسعه نرم‌افزار چابک پرداخته و تأکید شده است که این رویکرد همچنان در حال تکامل و تغییر است. همچنین تاریخچه، اصول اساسی و اهمیت تمرینات فنی در توسعه نرم‌افزار چابک بررسی میشود و به نیاز به تطبیق، یادگیری مداوم و رویکرد منطبق با شرایط خاص تیم‌ها و پروژه‌ها تأکید میشود.در اینجا خلاصه‌ای از ویدئو با عنوان " Software Architecture and Design InfoQ Trends Report 2022" بیان شده است:در این ویدئو درباره‌ی اهمیت رشد داده در معماری نرم‌افزار بحث میشود و بر اهمیت کیفیت داده تأکید می‌کنند، به ویژه وقتی که کسب‌وکارها برای تصمیم‌گیری‌های خود از داده‌ها استفاده می‌کنند. در این بحث بیان می‌شود که کیفیت نادرست داده می‌تواند منجر به زیان‌های مالی قابل توجهی شود و اهمیت شناسایی زودهنگام و رفع مشکلات مرتبط با داده در مراحل ابتدایی فرآیند توسعه نرم‌افزار تأکید می‌شود. در ادامه به تأثیر مقررات جدید در استفاده از داده‌ها، به خصوص در مدل‌های هوش مصنوعی اشاره می‌شود. این مقررات شامل قوانینی مانند قانون هوش مصنوعی اتحادیه اروپا و قانون پاسخگویی الگوریتمی ایالات متحده است. این مقررات نیازمندی‌های بیشتری را در مورد نحوه آموزش و استفاده از مدل‌های هوش مصنوعی ایجاد می‌کنند، به ویژه در حوزه‌های با مخاطره بالا مانند مالی و سلامت، و از سازمان‌ها و توسعه‌دهندگان می‌خواهند مسئولیت بیشتری در این زمینه به عهده بگیرند.مفهوم Data Mesh و Data Gateway به عنوان یک رویکرد نوین در مورد سازماندهی داده بررسی میشود. این مفهوم مشابه طراحی محور حوزه (Domain-Driven Design) است، اما در اینجا برای داده‌ها به کار می‌رود. اصلی‌ترین ایده این است که تیم‌ها را بر اساس حوزه‌های داده تشکیل داده تا مدیریت و کیفیت داده‌ها بهبود یابد. این رویکرد داده‌ها را به عنوان یک منبع مستقل و توزیع‌شده در نظر میگیرد و دسترسی به داده‌ها و مدیریت آنها را آسان میکند.همینطور در مورد تغییر نقش معماران در توسعه مدرن صحبت شده است. این تغییر نگرش به این معناست که معماران دیگر به عنوان افرادی که از بالا به تصمیمات نگاه می‌کنند، شناخته نمی‌شوند. آنها حالا جزء تیم توسعه می‌شوند و به تیم‌ها اختیار داده می‌شود تا تصمیمات معماری بگیرند و در عین حال با تعیین استانداردها و راهنماها تیم‌ها را در مسیر درست هدایت کنند.در این ویدئو، اهمیت راهنمایی و توسعه مهارت‌های معماری در تیم‌ها برجسته شده است و در مورد چالش‌های اطمینان از تطابق عملیات معماری در تیم‌های مختلف و نیاز به وجود یک ساختار برای پشتیبانی و هدایت تیم‌ها در زمینه معماری بحث کرده‌اند.در رابطه با سوابق تصمیمات معماری (ADRs) یک ابزار برای ثبت و انتقال تصمیمات معماری صحبت شده است. این رویکرد به تیم‌ها کمک می‌کند تا یک سوابق دقیق از دلایلی که باعث انتخاب یک معماری خاص شدند، نگهداری کنند. به این ترتیب، اطلاعات مهمی در مورد چرایی‌های تصمیمات معماری در دسترس تیم‌ها قرار می‌گیرد و ارتباط و تبادل دانش در مورد معماری تسهیل می‌شود. مورد دیگر اینکه نیاز به تقویت تیم‌ها برای انجام تصمیمات معماری مورد تأکید قرار می‌گیرد و اختیار دادن به تیم‌ها برای تصمیم‌گیری در مسائل معماری از اهمیت ویژه‌ای برخوردار است.در ادامه به اهمیت ادغام معماری در فرهنگ DevOps پرداخته شده است. آنها میگویند در آینده معماری به طور شفاف و بدون مشکل در فرآیندهای توسعه و عملیات تداخل می‌یابد و معماری به طور موثرتری در جریان توسعه و عملیات نرم‌افزار جای خواهد گرفت، این امر به بهبود تجربه توسعه نرم‌افزار و افزایش کارایی فرآیند DevOps کمک می‌کند.به طور خلاصه، این ارائه موضوعات متنوعی مرتبط با نقش در حال تغییر معماری نرم‌افزار و معماران در توسعه نرم‌افزار مدرن را پوشش می‌دهد و تقویت تیم‌ها، و ادغام عملیات معماری در فرآیندهای توسعه گسترده‌تر را برجسته می‌کند.این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است فاطمه عصمتی فاطمه عصمتی Fri, 05 Jan 2024 00:52:04 +0330 https://virgool.io/@m_46173657/%D9%85%D8%A8%D8%A7%D8%AD%D8%AB%DB%8C-%D8%AF%D8%B1-%D8%B1%D8%A7%D8%A8%D8%B7%D9%87-%D8%A8%D8%A7-%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-eptpp4o8l2e1 Modular Monolithicبرنامه نویسی monolithic به شیوه‌ای از برنامه نویسی گفته میشود کهدر آن تمام قسمت‌های برنامه شامل دیتابیس، منطق برنامه، فرانت و ... در یک فایل نوشته میشوند و همه‌ی اجزای برنامه به هم وابسته هستند و در این شیوه تغییر جزئی منجر به تغییر و در اغلب موارد منجر به خرابی در اجزای دیگر میشود. در مقابل این شیوه، برنامه نویسی modular وجود دارد که برنامه به بخش‌های مختلف شکسته شدا و مستقل از هم ایجاد شده و مستقل از هم نیز کار میکنند. در این روش ایجاد تغییر در یک بخش معمولا تاثیری بر دیگر اجزا ندارد و توسعه‌ی برنامه نیز راحت تر است. Modular monolithic اصطلاحی است که به برنامه‌هایی گفته میشود که در ابتدا به صورت monolithic ایجاد شده اند و بعد تلاش هایی برای ماژوله کردن صورت گرفته است که ساختار برنامه اندکی شکل modular به خود بگیرد و بتوان از مزیت‌های modularity تا حدودی بهره‌مند شد.https://vrgl.ir/jzMoYhttps://medium.com/design-microservices-architecture-with-patterns/microservices-killer-modular-monolithic-architecture-ac83814f6862AWSفرض کنید فردی میخواهد خانه‌ای بخرد. او نیاز به برق، آب، گاز و ... برای زندگی در آن خانه دارد. پس از خرید خانه فرد خودش منبع تولید برق، چاه آب و ملزومات آن را فراهم نمیکند بلکه از شرکت برق که تمام این زیرساخت‌های مورد نیاز را فراهم کرده و آماده‌ی خدمت رسانی است برق میگیرد و در آخر ماه به اندازه‌ی مصرف خود هزینه میپردازد. اکنون در نظر بگیرید فردی میخواهد یک بیزینسی راه‌ اندازی کند که نیاز به فضای ذخیره سازی و پردازشی که هزینه‌ی بسیار زیادی دارد داشته باشد. شرکت آمازون ابزاری به نام AWS (Amazon Web Service) ایجاد کرده است که استخری از منابع مورد نیاز دارد و افراد میتوانند از آن خدمت گرفته و به ازای مصرفشان هزینه پرداخت کنند، بدون نیاز به خریداری سخت افزارها.https://fanology.ir/what-is-amazon-web-service/https://www.karlancer.com/blog/aws/API-first ApproachAPI-first Approach یک رویکردی در برنامه نویسی است که به طراحی و ایجاد API ها قبل از دیگر بخش‌ها تاکید دارد. الویت دادن به طراحی و تعریف API ها باعث میشود پس از مشخص شدن اهداف، ارتباطات واضح بین اجزا مشخص شوند و هر بخش به طور مستقل و با وظایف مشخص توسعه پیدا کنند بنابراین میتوان گفت این رویکرد به موازی سازیِ توسعه کمک کرده و زمان توسعه را کاهش پیدا میدهد. کاهش وابستگی بین اجزا از دیگر مزیت‌های این استراتژی است و در نتیجه‌ی کاهش وابستگی ها نگهداری آسان میشود. تعریف API ها در ابتدای کار توسعه پذیری و انعطاف پذیری برنامه را افزایش میدهد.https://www.postman.com/api-first/https://apieco.ir/blog/what-is-api-first/NoSQL DatabaseNoSQL Database یا not only SQL روشی برای ذخیره سازی داده است که در آن داده های با حجم زیاد و نامتمرکز میتوان ذخیره کرد بنابراین این نوع از دیتابیس بیشتر برای کسب و کارهایی مناسب است که با حجم انبوهی از داده‌های ساختار نیافته سروکار دارند. همین ساختارنیافتگی داده‌ها مزیت مهم NoSQL است زیرا نیاز به سازماندهی داده‌ها، ایجاد جدول، روابط و ... نداریم؛ بنابراین نیاز به مدیریت آنچنانی وجود ندارد و این خود یک مزیت مهم است. این نوع دیتابیس از مقیاس پذیری افقی پشتیبانی میکند یعنی در صورت نیاز بدون افزایش سرورها میتوانیم حجم داده‌ی بیشتری ذخیره کنیم. NoSQL Database ها سرعت زیادی برای پردازش دارند. انواع مختلفی از NoSQL ها وجود دارند مانند: Document-Oriented, Key-Value sores, Columan-family stores, Graph Database؛ اکثرا در فضاهای ابری نیز مورد استفاده قرار میگیرند.https://7learn.com/blog/what-is-nosqlhttps://aws.amazon.com/nosql/Serverless Architectureزمانی که نرم افزاری تولید میشود نیاز به سرور دارد که این سرور علاوه بر اینکه هزینه‌ی زیادی دارد نیازمند مدیریت و نگهداری است. امنیت سرور نیز یکی دیگر از چالش های نگهداری سرور هست. Serverless Architecture یک مدل رایانش ابری است که میتواند بستر سرور فراهم نماید و میگوید میتوانید با خذف چالش های نگهداری سرور تمرکز و هدف را بر روی ایده‌ی خود و نرم افزار مجتمع کنید. بنابراین، این زیرساخت تنها کد برنامه را گرفته و بسته به نیازِ یک نرم افزار، به صورت داینامیک منابع مورد نظر را به آن اختصاص میدهد. هزینه‌ای که باید پرداخت شود بر اساس میزان مصرف محاسبه میشود. به این نکته باید توجه داشت که مهاجرت از سرویس سنتی به این زیرساخت‌ها فرآیندی ساده‌ای نیست و چالش‌های خود را به همراه دارد.https://vrgl.ir/8HY4ahttp://sokanac.ir/kNLDomain Driven Designطراحی دامنه محور (DDD) یک رویکرد توسعه نرم افزار است که بر درک و مدل سازی مفاهیم اصلی کسب و کار و اتباط شفاف بین اعضا تمرکز دارد. این یک زبان مشترک ((زبان جاودانه)) بین توسعه دهندگان و کارشناسان کسب و کار را برای ایجاد یک درک مشترک تشویق می کند. DDD به ساختن نرم‌افزاری کمک می‌کند که مستقیماً فرآیندهای کسب‌وکار در دنیای واقعی را منعکس می‌کند و نگهداری و تکامل آن را آسان‌تر می‌کند. یکی از مزایای کلیدی آن بهبود همکاری بین اعضای تیم فنی و غیر فنی است که منجر به راه حل های نرم افزاری موثرتر و دقیق تر می شود.https://en.wikipedia.org/wiki/Domain-driven_designhttps://martinfowler.com/bliki/DomainDrivenDesign.htmlHexagonal Architectureمعماری Hexagonal یا شش‌گوشی، الگویی در طراحی نرم‌افزار است که هدف اصلی این معماری، تمرکز بر منطق کسب و کار و هسته‌ی اصلی برنامه است. جزئیات وابسته به ورودی و خروجی، مثل واسط‌های کاربری یا دیتابیس‌ها، از منطق اصلی تفکیک می‌شوند. در این مدل، هسته اصلی برنامه در وسط قرار دارد و با ورودی‌ها و خروجی‌ها از طریق شش دید مختلف در ارتباط است. این الگو از پلاگین‌پذیری بهره می‌برد که امکان اضافه کردن واسط‌های جدید را بدون تغییر در منطق اصلی برنامه فراهم می‌کند. با جدا سازی I/O و منطق کسب و کار، این معماری انعطاف‌پذیری بالا، تست و نگهداری آسان و کاهش وابستگی‌ها را به ارمغان می‌آورد؛ Hexagonal Architecture به ویژه برای برنامه‌هایی که با برنامه‌های دیگر تعامل دارند مناسب است.https://vrgl.ir/gC1Qrhttp://sokanac.ir/JnIhttps://tsh.io/blog/hexagonal-architecture/#:~:text=Hexagonal%20architecture%20is%20a%20pattern,databases%20from%20the%20core%20applicationEvent SourcingEvent Sourcing یک الگوی طراحی نرم‌افزار است که به جای نگهداری وضعیت فعلی یک سیستم، تمامی رخدادها و تغییرات را در طول زمان ثبت می‌کند. در این الگو، تاریخچه‌ی کامل تغییرات در سیستم قابل دسترس است، که این موضوع می‌تواند به رفع اشکالات و تجزیه و تحلیل کمک کند. Event Sourcing به سیستم این امکان را می‌دهد که با تجمیع رخدادها، وضعیت فعلی را محاسبه کند و از این طریق قابلیت بازگردانی وضعیت به هر زمانی را فراهم سازد. این الگو مناسب برای سیستم‌هایی است که نیاز به ثبت و ردیابی دقیق تغییرات دارند، مانند سیستم حسابداری. اما برای پیاده‌سازی آن، نیازمند تغییرات در مدل داده و logic سیستم است که ممکن است برای سیستم‌های ساده باعث پیچیدگی شود. Event Sourcing از پلاگین‌پذیری بهره می‌برد که به راحتی امکان اضافه کردن واسط‌های جدید بدون تغییر در بخش‌های اصلی را فراهم می‌کند و به سیستم امکان به‌روزرسانی یا تغییر مدل داده بدون از دست رفتن تاریخچه‌ی رخدادها میدهد.https://learn.microsoft.com/en-us/azure/architecture/patterns/event-sourhttps://vrgl.ir/t7NUtLow-code platformsLow-code platforms، ابزارهای توسعه نرم‌افزار هستند که امکان ایجاد برنامه و نرم افزار‌ها برای کسانی که به مهارت عالی و پیشرفته در برنامه نویسی نرسیده‌اند را فراهم میکند. این پلتفرم‌ها با فراهم آوردن یک محیط گرافیکی و امکانات متنوع، توسعه‌دهندگان را در فرآیند ایجاد و تنظیم فرآیندها و برنامه‌ها همراهی می‌کنند. مزایای این ابزارها شامل افزایش سرعت توسعه، وجود امکان شرکت کاربران غیر توسعه دهنده در فرایند ایجاد برنامه و کاهش هزینه‌ها و زمان موردنیاز برای پروژه‌های کوچک و متوسط است. با این حال، در پروژه‌های پیشرفته و نیازمند کنترل دقیق‌تر، ممکن است محدودیت‌هایی وجود داشته باشد. به طور کلی، Low-code platforms با توجه به نوع پروژه‌ها، ابزارهایی کارآمد برای توسعه سریع و آسان نرم‌افزارها هستند.https://www.ibm.com/topics/low-codehttps://blog.faradars.org/what-is-low-code-development/Business Process Management Systems (BPMS)BPMS به عنوان سیستم‌های مدیریت فرآیند کسب و کار، نقش بسیار مهمی در بهبود عملکرد و بهینه‌سازی فرآیندها و فعالیت‌های سازمانی ایفا می‌کنند. از جمله مزایای این سیستم‌ها می‌توان به افزایش شفافیت در داخل سازمان و بهبود هماهنگی، سیستم امکان مشارکت افراد غیرتکنیکی را در طول فرایند و همکاری میان اعضای تیم اشاره کرد. این سیستم‌ها میتوانند با گزارش‌گیری و تجزیه و تحلیل پیشرفته مدیران را در ارزیابی و بهبود عملکرد فرآیندها ‌کنند. به علاوه، این سیستم‌ها قابلیت ادغام با سایر سیستم‌ها و داده‌های مختلف درون سازمان را دارند و به سازمان‌ها این امکان را می‌دهند که با سرعت به تغییرات بازار و نیازهای مشتریان واکنش نشان دهند. با این حال استفاده از این سیستم‌ها ممکن است نیازمند تغییرات در ساختار و فرآیندهای سازمانی باشد که این مسئله ممکن است به چالش‌هایی برای برخی از سازمان‌ها منجر شود.https://www.pegaheaftab.com/bpms-%DA%86%DB%8C%D8%B3%D8%AA/https://abpmp-ir.org/what-are-business-process-management-systems/Message QueueMessage Queue یا صف پیام، مثل Kafka و RabbitMQ، یک سیستم مهم برای ارتباط و انتقال پیام بین برنامه‌ها یا بخش‌های مختلف یک سیستم هستند. این سیستم‌ها مانند یک پستچی عمل می‌کنند. هر برنامه می‌تواند یک پیام را به این صف بفرستد و بعداً برنامه دیگری این پیام را از صف بیرون آورد. مزیت این روش این است که وقتی یک برنامه پیامی بفرستد، می‌تواند به کار خود ادامه داده و منتظر دریافت پیام توسط بخش دیگر نباشد. همچنین، اگر بخشی از سیستم برای لحظه‌ای کار نکند و نتواند یک پیام را دریافت کند آن پیام از بین نرفته و می‌تواند بعداً آن را بخواند. ایجاد صف به هنگام ترافیک زیاد می‌تواند به عملکرد سیستم کمک کند؛ به طور کلی ارتباط بین برنامه‌ها ایجاد کرده و به کارامد بودن سیستم کمک میکند.https://vrgl.ir/rpyGuhttps://en.wikipedia.org/wiki/Message_queueContainer OrchestrationContainer Orchestration، نقش مهمی در مدیریت کانتینرها و اجرای برنامه ها در محیط های توزیع شده ایفا می کند. این به توسعه دهندگان این امکان را می دهد که به راحتی برنامه های خود را در کانتینرها اجرا و مدیریت کنند. Kubernetes، به عنوان یک نمونه‌ی برجسته، قابلیت‌هایی را برای ایجاد، مقیاس‌بندی و نظارت بر برنامه‌ها فراهم می‌کند و به بهبود فرآیندهای ساخت و اجرای برنامه‌ها کمک می‌کند. مزایای مهم شامل توزیع بهینه حجم کار، امکان ایجاد و به روز رسانی خدمات بدون وقفه، و نظارت پیشرفته است. استفاده از این Orchestration ‌ها روند ارتقاء و مقیاس بندی برنامه ها را سرعت می بخشد.https://xaas.ir/blog/orchestration/https://cloud.google.com/discover/what-is-container-orchestrationLog Management Toolsمدیریت لاگ یک فرآیند مداوم است که شامل جمع‌آوری و تجزیه و تحلیل داده‌های لاگ برای نظارت بر عملکرد، شناسایی مشکلات و افزایش امنیت می‌شود. تحلیل داده‌های جمع‌آوری شده برای به دست آوردن تصویری از عملکرد تجاری، امنیتی و عملیاتی استفاده می‌شود. به عنوان مثال، یک سرویس میزبانی وب را در نظر بگیرید. Elasticsearch(ELK) به عنوان یک مخزن مرکزی عمل می کند و به سرعت لاگ های سرور را ذخیره و بازیابی می کند. Logstash به طور سیستماتیک داده ها را جمع آوری و پردازش می کند و از انسجام اطمینان حاصل می کند. سپس Kibana این اطلاعات را به تصاویر قابل درک تبدیل می‌کند و مدیران را قادر می‌سازد تا عملکرد سرور را نظارت کنند، تهدیدات امنیتی بالقوه را شناسایی کنند و مشکلات را به سرعت عیب‌یابی کنند. این اعمال به سازمان‌ها اجازه می‌دهد تا از گزارشات به راه‌ حل‌های عملی برسند و قابلیت اطمینان و امنیت سیستم را افزایش دهند.https://www.sumologic.com/blog/log-management-tool/https://sematext.com/guides/elk-stack/Monitoring toolsابزارهای مانیتورینگ، مانند Prometheus، به عنوان نگهبان هوشیار سیستم‌ها و برنامه‌های دیجیتال عمل می‌کنند و به طور مداوم معیارهای مختلفی مانند استفاده از منابع، زمان پاسخ و نرخ خطا را جمع‌آوری و تجزیه و تحلیل می‌کنند. وظیفه‌ی آنها مطمئن شدن از اجرای درست همه چیز است. برای مثال، Prometheus از مدل pull برای جمع‌آوری معیارهای مختلف از سیستم‌ها و خدمات استفاده می‌کند. این ابزار، این امکان را فراهم می‌کند تا کاربران بتوانند داده‌های جمع‌آوری‌شده را استفاده کرده و پرس‌وجوهای پیچیده را انجام دهند، همچنین از قابلیت اعلان استفاده می‌کند تا به کاربران اطلاع دهد که آیا شرایط مشخصی در سیستم رخ داده یا خیر؛ این امر به مدیران سیستم اجازه می‌دهد به سرعت هر مشکلی را شناسایی و رسیدگی کنند و سیستم را ارتقا دهند.https://vrgl.ir/NlJCOhttps://logit.io/blog/post/prometheus-monitoring-tools/Static Code AnalysisStatic Code Analysis به تجزیه و تحلیل کد برای یافتن ایرادات و مشکلات کد مانند مشکلات امنیتی، Dead codeها، باگ‌ها و ... بدون اجرای کد است. این مرحله معمولا قبل از مرحله‌ی تست نرم افزار و ابتدای توسعه انجام می‌شود. این تحلیل را میتوان به صورت دستی نیز انجام داد اما ابزارهای قدرتمندی برای انجام خودکار این مرحله وجود دارد. SonarQube یکی از این ابزارهاست که به طور مداوم کیفیت کد را بررسی می‌کند و از همسویی آن با استانداردهای کدنویسی و نبود مشکلات رایج، اطمینان می‌دهد. این ابزارها با ارائه بازخورد اولیه در مورد کیفیت و امنیت کد به توسعه دهندگان، تیم ها را قادر می سازند تا به طور فعالانه به مسائل رسیدگی کنند و در نتیجه برنامه های نرم افزاری قوی تر، کارآمدتر و ایمن تر ایجاد کنند. با انجام این تحلیل توسعه‌ی یک نرم افزار آسان‌تر خواهد شد.https://vrgl.ir/1gAvfhttps://www.bitegarden.com/static-code-analysis-with-sonarqube فاطمه عصمتی فاطمه عصمتی Thu, 23 Nov 2023 15:44:57 +0330 https://virgool.io/@m_46173657/%D8%AE%D9%84%D8%A7%D8%B5%D9%87-%DB%8C-%D9%81%D8%B5%D9%84-%D9%87%D8%A7%DB%8C-%DB%B1%DB%B5-%D8%AA%D8%A7-%DB%B2%DB%B9-%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-pm1sbau0kra2 فصل ۱۵ بر اهمیت معماری نرم افزار تاکید مجدد دارد و میگوید معماری تصمیماتی بنیادی برای ساختار یک نرم‌افزار است که میتواند نقش مهمی در کاهش هزینه‌های توسعه و نگهداری داشته باشد. در این فصل به کپسوله‌ سازی هم اشاره‌ی ویژه‌ای شده است که کپسوله سازی را کلیدی ترین اصل یک معماری خوب میداند زیرا بخش‌های سیستم میتوانند تغییر پیدا کنند بدون اینکه به بقیه‌ی اجزای سیستم آسیبی وارد شود. این فصل همچنین به بررسی سبک های مختلف معماری، مانند معماری لایه ای، معماری شش ضلعی، و معماری میکروسرویس می پردازد و مبادلات بین آنها را مورد بحث قرار می دهد. به طور کلی، فصل 15 یک نمای کلی از اهمیت معماری در توسعه نرم افزار ارائه می دهد و توصیه هایی برای طراحی و پیاده سازی معماری نرم افزار خوب بیان میکند.فصل ۱۶ درباره‌ی اهمیت decoupling اجزا در یک سیستم صحبت میکند؛ به این معنا که هر بخش سیستم مستقل از بخش‌های دیگر عملکرد داشته باشد و تغییر در یک بخش، تاثیری بر عملکرد اجزای دیگر نداشته باشد. این فصل انواع مختلف کوپلینگ، مانند کوپلینگ زمانی، مکانی و منطقی را مورد بحث قرار می دهد و توصیه های عملی برای کاهش وابستگی بین اجزا ارائه می دهد. در فصل‌های قبلی راجب اصل interface segregation صحبت شد و این اصل میتواند به کم کردن وابستگی‌ها کمک کند. به طور کلی، این فصل یک نمای کلی از اهمیت استقلال در معماری نرم افزار ارائه می دهد و میگوید Decoupling انعطاف پذیری سیستم را افزایش میدهد و توسعه و نگهداری را آسان تر میکند.فصل ۱۷ به توصیف اهمیت و چگونگی ارتباط و تعیین مرز بین بخش‌هایی از نرم‌افزار با دنیای بیرون میپردازد. بایستی مرزهای مشخصی بین نرم‌افزار و محیط بیرون تعریف کنیم و همچنین برای مرزها interface تعریف کنیم. میتوانیم از اصل Dependency Inversion برای مدیریت وابستگی‌ها استفاده کنیم. در نهایت باید از درست بودن این مرزها و پایدار بودنشان اطمینان حاصل کرد.این فصل راهکارهایی برای مدیریت این ارتباطات و تعاملات ارائه میدهد که در نهایت سیستم قابل نگهداری تر میشود.فصل ۱۸ بر اهمیت درک و تعریف مرزهای بین اجزا در یک سیستم نرم افزاری تمرکز دارد و انواع مرزها را مورد بحث قرار میدهد. از جمله componentها، thread ها، فرآیندهای محلی و سرویس‌ها. این فصل توصیه بر به حداقل رساندن عبور از مرزها در یک سیستم دارد. هر چه اینکار بهتر انجام شود معماری خوبی خواهیم داشت و با تعریف مرزهای واضح و مشخص میتوانیم یک سیستم انعطاف پذیر، مقیاس پذیر و قابل نگهداری داشته باشیم.فصل ۱۹ در مورد مفهوم سیاست ها در سیستم های نرم افزاری و اهمیت سازماندهی موثر آنها در یک معماری بحث می کند. سیستم های نرم افزاری اساساً بیانیه های خط مشی هستند و چگونگی تبدیل ورودی ها به خروجی ها را توصیف می کنند. معماری خوب شامل جداسازی و گروه بندی مجدد سیاست ها بر اساس ویژگی های تغییر آنهاست و مولفه ها بر اساس سطحشان طبقه بندی می شوند و سیاست های ورودی/خروجی پایین ترین سطح هستند. معماری مناسب سیاست های سطح بالا را از جزئیات سطح پایین جدا می کند و تاثیر تغییرات را کاهش می دهد. در اصل، فصل بر اهمیت سیاست‌های ساختاری در معماری نرم‌افزار برای افزایش قابلیت نگهداری و انعطاف‌پذیری تاکید می‌کند و کاربرد اصول مختلف طراحی نرم‌افزار را در دستیابی به این اهداف برجسته می‌کند.فصل ۲۰ بر اهمیت جداسازی قوانین تجاری از بقیه سیستم تاکید می کند. قوانین کسب و کار سیاست ها و رویه هایی هستند که بر رفتار سیستم حاکم هستند و اغلب منحصر به یک تجارت یا صنعت خاص هستند. آنها باید جدا از رابط کاربری، پایگاه داده و سایر نگرانی های زیرساختی نگهداری شوند تا اصلاح آنها بدون تأثیرگذاری بر سایر بخش های سیستم آسان تر شود. این فصل انواع مختلف قوانین تجاری را نیز مورد بحث قرار می دهد؛ قوانین باید به طور ساده و قابل فهم نگهداری شوند. با رعایت این موارد اصلاح و نگهداری سیستم‌ها ساده‌تر خواهد بود.فصل ۲۱ بر اهمیت ایجاد یک معماری واضح و قابل درک برای یک سیستم نرم افزاری تاکید می کند. یک معماری خوب باید ساده، واضح و قابل درک باشد، همچنین باید انعطاف پذیر و سازگار با نیازهای متغیر باشد. این فصل مفهوم « screaming architecture » را معرفی می‌کند، چنین معماری‌ایی هدف خود را به وضوح بیان می‌کند، درک و هدایت آن آسان است و انعطاف‌پذیر و سازگار است. این فصل چندین نمونه از ظاهر چنین معماری را در عمل ارائه می‌کند، مانند استفاده از قراردادهای نام‌گذاری واضح و سازگار، و ایجاد یک معماری مدولار و انعطاف‌پذیر. با پیروی از این اصول، توسعه دهندگان می توانند سیستم هایی ایجاد کنند که درک، اصلاح و نگهداری آنها در طول زمان آسان باشد.فصل ۲۲ مفهوم رویکرد معماری تمیز برای توسعه نرم افزار را معرفی می کند. جداسازی concern ها و وارونگی وابستگی دو مولفه‌ی مهم در تولید چنین نرم‌افزاری هستند. معماری تمیز به جداسازی بین منطق بیزینس و جزئیات پیاده سازی تاکید دارد. این فصل مروری بر لایه‌ها و مؤلفه‌هایی که یک معماری تمیز را تشکیل می‌دهند، شامل موجودیت‌ها، یوز کیس‌ها، اینترفیس‌ها و لایه‌های زیرساخت ارائه می‌کند. همچنین به اهمیت ایجاد مرز مشخص بین لایه‌ها و استفاده از تزریق وابستگی برای مدیریت وابستگی‌ها بین اجزا میپردازد.فصل ۲۳ یک الگوی طراحی را ارائه میدهد؛ الگوی Object Humble یک اصل طراحی است که رفتارهایی که آزمایش سخت دارند را از رفتارهای آزمایش آسان جدا می کند. این کار را با ایجاد دو ماژول انجام می دهد: View، که شی فروتن است، ارائه داده ها را به شیوه ای ساده مدیریت می کند. Presenter که شی قابل آزمایش است و مسئول قالب بندی و آماده سازی داده ها برای View است. این الگو برای افزایش تست‌پذیری نرم‌افزار، به‌ویژه در مرزهای معماری استفاده می‌شود. با جدا کردن رفتارهای پیچیده یا آزمایش کردن سخت از رفتارهایی که به راحتی قابل آزمایش هستند، آزمایش را ساده می کند.فصل ۲۴ مرزهای جزئی را مورد بحث قرار می‌دهد که جایگزینی ارزان‌تر برای مرزهای کامل معماری هستند. معمولا ایجاد مرزهای کامل کاری زمانبر و هزینه‌بر است. معماران ممکن است یک مرز جزئی را زمانی اجرا کنند که هزینه یک مرز کامل بسیار زیاد باشد. این فصل همچنین استفاده از مرزهای جزئی را در عمل پوشش می دهد، از جمله مثال هایی از نحوه اجرای آنها و نحوه آزمایش آنها. به طور کلی، یک نمای کلی از مرزهای جزئی و استفاده از آنها در معماری نرم افزار ارائه می شود.فصل ۲۵ اهمیت جداسازی concern ها در معماری نرم افزار را مورد بحث قرار می دهد و مفهوم لایه ها را معرفی می کند؛ لایه‌ها راهی برای سازماندهی کد به گروه‌هایی با عملکردهای مرتبط هستند که هر لایه مسئولیت خاصی دارد. نحوه تعامل لایه ها با یکدیگر و مرزها در معماری نرم یک امر بسیار مهمی است. نمونه هایی از نحوه تعریف API و مدیریت وابستگی بین لایه ها نیز گفته شده است. همچنین اصل وارونگی وابستگی (DIP) را که پیش از این آشنا شدیم، نمونه هایی از نحوه اعمال آن در عمل را ارائه می دهد. به طور کلی، این فصل یک نمای کلی از لایه ها و مرزها در معماری نرم افزار ارائه می دهد.فصل ۲۶ اهمیت داشتن یک جزء اصلی را در هر سیستم نرم افزاری که اجزای دیگر را ایجاد، هماهنگ و نظارت می کند، بحث می کند. این جزء اصلی وظیفه‌ی مدیریت جریان کنترل و داده‌ها بین سایر اجزا را بر عهده دارد. جزء اصلی بایستی ساده نگه داشته شود. در این فصل نمونه هایی از نحوه طراحی جزء اصلی و نحوه مدیریت وابستگی های آن و نحوه‌ی استفاده از interfaceها برای جدا کردن جزء اصلی از سایر اجزا ارائه شده است. آزمایش این جزء اصلی بسیار مهم است و آزمون‌هایی در این باره در کتاب ارائه شده است.فصل ۲۷ استفاده از خدمات در معماری نرم افزار را توضیح میدهد. همه‌ی سرویس‌ها از نظر معماری مهم نیستند و معماری یک سیستم با مرزهایی تعریف می شود که خط مشی سطح بالا را از جزئیات سطح پایین جدا می کند و از قانون وابستگی پیروی می کند. طراحی خدماتی که از نظر معماری مهم هستند از اهمیت برخوردارند. به نحوه‌ی استفاده از خدمات برای جداسازی عملکردها در بین فرآیندها و پلتفرم ها هم در این فصل اشاره شده است.فصل ۲۸ نقش تست را در معماری نرم افزار مورد بحث قرار می دهد. تست‌ها بخشی از سیستم هستند و مانند هر بخش دیگری از سیستم در معماری شرکت می‌کنند. همچنین انواع مختلف آزمون‌ها، مانند آزمون‌های واحد، آزمون‌های یکپارچه‌سازی، آزمون‌های پذیرش، آزمون‌های عملکردی و غیره وجود دارند. این فصل بر اهمیت طراحی برای آزمایش پذیری تأکید می کند و مثال هایی از نحوه انجام این کار ارائه می دهد. Testing API مجموعه‌ای از توابع و کلاس‌ها است که به تست‌ها اجازه می‌دهد با سیستم تحت آزمایش تعامل داشته باشند. تست ها جزئی از سیستم هستند و یک معماری خوب باید قابل آزمایش باشد.فصل ۲۹ بر استفاده از اصول معماری در نرم‌افزارها و سیستم‌های عامل تعبیه شده توصیه میکند. در معماری سیستم‌های تعبیه شده باید به وجود محدودیت‎های منابع توجه داشت. قابل تست بودن معماری در اینجا نیز تاکید شده است که به حداقل رساندن وابستگی‌های اجزای سیستم به این امر کمک میکند. این فصل بر ماژولار بودن طراحی نیز تاکید مجدد دارد زیرا میتواند به کاهش پیچیدگی سیستم کمک کند و در نهایت تست پذیری افزایش پیدا کند. فاطمه عصمتی فاطمه عصمتی Fri, 20 Oct 2023 15:00:34 +0330