بسیار عالی و حرفه ای بود. نظر آخر رو خیلی پسندیدم، فشن پرستی خیلی رایج شده متاسفانه. یه سئوال: فرض کنید در ساختار بک‌اند یه تغییری ایجاد شده که یه فیچر جدید رو از فرانت میخواد. وقتی این تغییر اعمال میشه، دو راه وجود داره: یه مسیر اینه که ساختار قبلی هنوز هندل بشه و فیچر جدید صرفا پس بشه و یا اررور برگردونه بشه تا فرانت مجبور باشه تمام GUI های مرتبط رو اپدیت کنه. من نظرم اینه که فرانت باید اپشن اپدیت ساختار ور داشته باشه تا این ایگنور شدن بعدا تبدیل به یک معضل نشه ولی معمولا فشار میاد که باید پس کنید تا مشکلی پیش نیاد.
سلام، خیلی ممنونم از انرژی مثبت و حسن توجهت یوسف عزیز، در رابطه با سوالی که پرسیدید، آپدیت ها میتونن اختیار یا فورس باشن. معمولا در نرم افزارهای تجاری هر ۲ حالتش در نظر گرفته میشه و ممکنه تعداد زیادی از آپدیت ها اختیاری باشند و نرم افزار نسخه های قدیمی رو پشتیبانی بکنه اما ممکنه آپدیت هایی هم باشند که نیازمند پچ شدن سریع هستند و شاید حاوی باگ های امنیتی باشند که در این موارد از آپدیت های فورس یا اجباری استفاده میکنیم و کاربر برای ادامه ی کار با اپلیکیشن مجبور به آپدیت بشه. معمولا هر ۲ حالتش رو در نظر میگیریم تا بتونیم در شرایط خاص باتوجه به شرایط یک سلوشن رو انتخاب کنیم. اگر سوالی داشتید حتما بپرسید. موفق و سلامت باشید دوست من ✌💚
خیلی خوب بود مخصوصا مورد آخر در مورد اینکه طراحی مایکروسرویس نیاز به تخصص و دانش فنی زیاد داره و همچنین اینکه همیشه بهترین معماری نمی‌تونه باشه. از نظر من برای نرم‌افزارهایی در اندازه کوچک و متوسط ، DDD کافیست.
ممنونم از حسن توجه و نظر لطفت مهران عزیز، بله دقیقا مایکروسرویس همیشه بهترین معماری نیست و باید در شرایط به خصوص و درستی از این معماری استفاده کرد. موفق و سلامت باشی دوست من ✌💚
عالی بود استاد فقط من یه سوال داشتم این مطالب مثل معماری نرم افزار به درد چه کسایی می خوره ؟ بک اند دولوپرها؟ موبایل دولوپر ها ؟ یا مثلا شرکت هایی که مهندس نرم افزار استخدام می کنن اون مهندس نرم افزار دقیقا چه مهارت هایی باید بلد باشه ؟ باید بک اند و موبایل رو باهم بلد باشه ؟ یا نه؟ من اینا واقعا گیجم کرده ممنون میشم راهنمایی کنید
ممنونم از حسن توجهت سیاوش عزیز، نه لازم نیست بک اند و موبایل رو باهم بلد باشید و شرکت ها انتظار ندارند که همچین کاری رو انجام بدید. شرکت های بزرگ آدم متخصص توی یک حوزه میخوان نه کسی که چند تا حوزه رو نصفه و نیمه بلد هست. مهارت هایی مثل معماری نرم افزار به درد هر مهندس نرم افزاری میخوره که میخواد توی کارش پیشرفت کنه چون هر نرم افزاری بر پایه یک سری معماری ها ساخته میشه و نرم افزارهای بدون معماری دیر یا زود محکوم به شکست هستند. این معماری در هر اپلیکیشن و سرویسی هست و فرقی نمیکنه فرانت اند و موبایل معماری داره و بک اند معماری داره و کلا همه اپلیکیشن های خوب معماری دارند. سوالی داشتید حتما بپرسید. موفق و سلامت باشید دوست من ✌💚
ممنونم از انرژی مثبتت دوست من، به زودی ویدئوهای بیشتری در زمینه مایکروسرویس ها و سیستم دیزاین در کانال منتشر میکنم که این موارد رو پوشش بدن. موفق و سلامت باشید و ممنونم از پیشنهاد خوبتون ✌💚
ممنونم از حسن توجه و نظر لطفت علیرضا عزیز، به زودی ویدئوهایی برای معرفی منابع آموزشی و کتاب های کاربردی ضبط میکنم و راجع به این موضوع صحبت میکنم. ممنونم از پیشنهادت دوست من 🙏💚
سلام وقت بخیر، سعی میکنم راجع به این موضوع ویدئوهای بیشتری ضبط کنم. کوهیژن به معنای یکپارچگی هست و کوهیژن بالا به معنای یکپارچی بالای یک سرویس یا حتی یک شی هست. یعنی سرویس یا شی مورد نظر باید تمام پیاده سازی های فنی مورد نظر رو درون خودش داشته باشه و وابسته به سرویس های دیگه نباشه. امیدوارم خوب توضیح داده بشم. اگر سوالی داشتید حتما بپرسید. موفق و سلامت باشید دوست من
مایکروسرویس ها نباید از پیاده سازی درونی همدیگه خبر داشته باشند و رفتارهای درونی همدیگر رو بدونند بلکه باید تنها از اینترفیس یا رابط همدیگر خبر داشته باشند. مثلا سرویس مسافرین نیازی به دونستن پیاده سازی سرویس رانندگان نباید داشته باشه اما باید بدونه زمانی که با اینترفیس سرویس رانندگان ارتباط برقرار میکنه اگر چه ورودی هایی رو بده چه خروجی هایی رو دریافت میکنه.
درود استفاده کردیم. اما متاسفانه خیلی یکنواخت بود و طولانی. من دقیقه 20 خوابم برد. داشتم توی ماشین میدیدم. اگه ماشین جلویی فلش نمیزد کامل خوابیده بودم.
خیلیم عالی آقا یه سوال : توی ویدیو مونولیت دیزاین پترن layerd monolithic دقیقا همین مفاهیم صدق میکنه . همه اپ ها جدا از هم هستن . هرکدوم پکیج های خودشونو دارن و با یه چارچوب خاصی باهم ارتباط دارن حالا مایکروسرویس هم دقیقا همینطوریه . فرق بین layerd monolithic و microservice چیه؟ توی مایکروسرویس مگه mvc نمیتونیم استفاده کنیم؟ و در اخر اینکه این مفاهیم برای سمت فرانت اند هم میشه استفاده کرد یا فقط مربوط به بکند و سروره؟ بازم ممنون
سلام وقت بخیر، فرق مونولیث لایه بندی شده و میکروسرویس در این هست که دیپلویمنت جداگانه دارن و معمولا در بیزینس دامین های جداگانه ای هستن و به صورت کامل دغدغه های جداگانه ای دارن که بهش میگیم separation of concerns درکل تفاوت زیادی در نحوه ی دیپلویمنت و نگهداری مونولیث لایه بندی شده و میکروسرویس هست در فرانت اند هم میتونه استفاده باشه مثلا میتونیم برای هر میکروسرویس فرانت اند جداگانه هم داشته باشیم که توسط gateway یکپارچه میشن خیلی بستگی به معماری نرم افزار و ساختار شرکت داره که از این قابلیت استفاده بکنن یا نه.
عالی بوداش بابی جان برای این که دانش این موضوع به دست بیاریم چه تئوری و چه عملی پیشنهادی داری در ضمن این رو هم بگم که من python back-end هستم می خواهم این موضوع اصولی یادبگیر ام سپاس .
سلام، این کتاب رو پیشنهاد میکنم برای بحث میکروسرویس خیلی کمک کننده و کامل هست: Sam Newman - Building Microservices - Designing Fine-Grained Systems-O'Reilly Media (2021)
ممنونم از انرژی مثبت و حسن توجهت پارسا عزیز، یوزکیس دیاگرام معمولا برای تعاملات کاربر با یک سیستم هست و موارد استفاده کاربر از سیستم رو نشون میده، مثلا روند ثبت نام کاربر میتونه در یوزکیس دیاگرام نمایش داده بشه. اما سرویس دیاگرام معمولا برای معماری سرویس ها و نحوه ی تعامل سرویس ها استفاده میشه تا یک هدف خاص رو برآورده کنن. معمولا این دیاگرام ها در کنار همدیگر به همراه دیاگرام های دیگر استفاده میشن. سوالی داشتید حتما بپرسید. موفق و سلامت باشید دوست من ✌💚
بسیار غالی بود . مطلب بسیار جالبی بود.دقیقا همینطور که خودتون اشاره کردید مایکروسرویس ها تقریبا با ظهور یونکس و سیستم عاملهای لینوکسی متولد شدن . بیشتر این تکنولوژی ها که که الان در موردشون بحث میشه و مطرح میشن قبلا بودن .
خیلی ممنونم از توضیحات تکمیلی و انرژی مثبتت فرید عزیز، بله دقیقا همینطور هست سرویس های اصطلاحا ریزدانه زمان زیادی هست که در دنیای نرم افزار وجود داشند اما خب با اسم های جدید ترند میشن و گاها باعث میشن آدم ها در شناخت سلوشن های درست دچار خطا بشن. موفق و سلامت باشید دوست من ✌💚
I don't understand difference between independent deployment and low coupling! Independent deployment is about that a service shouldn't has dependency to other services and low coupling is about dependency between services too! are they same?
سلام میلاد جان امیدوارم حالت خوب و عالی باشه، تفاوت بین ۲ درواقع تفاوت در زمان (تایم) هست. کاپلینگ پایین معمولا در زمان طراحی و توسعه نرم افزار در نظر گرفته میشه. مثلا فانکشن ها یا کلاس هایی که مینویسیم (بیشتر در زمان توسعه و طراحی نرم افزار) نیاز هست بهمدیگر وابستگی کمی داشته باشن تا در صورت تغییر یک فانکشن مجبور نباشیم بقیه فانکشن ها یا کلاس هارو تغییر بدیم. دیپلویمنت مجزا در زمان آپدیت نرم افزار مطرح میشه. یعنی از نظر زمانی، کاپلینگ پایین در زمان توسعه و طراحی نرم افزار هست و دیپلوی مجزا در زمان آپدیت نرم افزار که اگر چرخه حیاط یک نرم افزار رو نگاه کنیم در زمان های مختلفی این ۲ مطرح میشن و صدالبته بهمدیگر ربط دارند. برای مثال کاپلینگ بالا میتونه باعث افزایش وابستگی در زمان دیپلویمنت بشه و کاپلینگ پایین میتونه باعث دیپلوی مجزا بشه. امیدوارم تونسته باشم خوب توضیح بدم اگر جاییش به نظرت ابهام یا سوالی وجود داره حتما بگو در خدمت هستم. موفق و سلامت باشی عزیز ✌️❤️
@@BobyCloudعالی گفتی...به همین داشتم فکر میکردم ..وقتی استقرارمون ممکنه خیلی وابسته باشه که زمان طراحی تا حد ممکن کاپلینگ کم نشده باشه...مرسی از جواب کاملت
