ممنونم از انرژی مثبتت دوست من، به زودی ویدئوهای بیشتری در زمینه مایکروسرویس ها و سیستم دیزاین در کانال منتشر میکنم که این موارد رو پوشش بدن. موفق و سلامت باشید و ممنونم از پیشنهاد خوبتون ✌💚
خیلی خوب بود مخصوصا مورد آخر در مورد اینکه طراحی مایکروسرویس نیاز به تخصص و دانش فنی زیاد داره و همچنین اینکه همیشه بهترین معماری نمی‌تونه باشه. از نظر من برای نرم‌افزارهایی در اندازه کوچک و متوسط ، DDD کافیست.
ممنونم از حسن توجه و نظر لطفت مهران عزیز، بله دقیقا مایکروسرویس همیشه بهترین معماری نیست و باید در شرایط به خصوص و درستی از این معماری استفاده کرد. موفق و سلامت باشی دوست من ✌💚
بسیار عالی و حرفه ای بود. نظر آخر رو خیلی پسندیدم، فشن پرستی خیلی رایج شده متاسفانه. یه سئوال: فرض کنید در ساختار بک‌اند یه تغییری ایجاد شده که یه فیچر جدید رو از فرانت میخواد. وقتی این تغییر اعمال میشه، دو راه وجود داره: یه مسیر اینه که ساختار قبلی هنوز هندل بشه و فیچر جدید صرفا پس بشه و یا اررور برگردونه بشه تا فرانت مجبور باشه تمام GUI های مرتبط رو اپدیت کنه. من نظرم اینه که فرانت باید اپشن اپدیت ساختار ور داشته باشه تا این ایگنور شدن بعدا تبدیل به یک معضل نشه ولی معمولا فشار میاد که باید پس کنید تا مشکلی پیش نیاد.
سلام، خیلی ممنونم از انرژی مثبت و حسن توجهت یوسف عزیز، در رابطه با سوالی که پرسیدید، آپدیت ها میتونن اختیار یا فورس باشن. معمولا در نرم افزارهای تجاری هر ۲ حالتش در نظر گرفته میشه و ممکنه تعداد زیادی از آپدیت ها اختیاری باشند و نرم افزار نسخه های قدیمی رو پشتیبانی بکنه اما ممکنه آپدیت هایی هم باشند که نیازمند پچ شدن سریع هستند و شاید حاوی باگ های امنیتی باشند که در این موارد از آپدیت های فورس یا اجباری استفاده میکنیم و کاربر برای ادامه ی کار با اپلیکیشن مجبور به آپدیت بشه. معمولا هر ۲ حالتش رو در نظر میگیریم تا بتونیم در شرایط خاص باتوجه به شرایط یک سلوشن رو انتخاب کنیم. اگر سوالی داشتید حتما بپرسید. موفق و سلامت باشید دوست من ✌💚
ممنونم از حسن توجه و نظر لطفت علیرضا عزیز، به زودی ویدئوهایی برای معرفی منابع آموزشی و کتاب های کاربردی ضبط میکنم و راجع به این موضوع صحبت میکنم. ممنونم از پیشنهادت دوست من 🙏💚
مایکروسرویس ها نباید از پیاده سازی درونی همدیگه خبر داشته باشند و رفتارهای درونی همدیگر رو بدونند بلکه باید تنها از اینترفیس یا رابط همدیگر خبر داشته باشند. مثلا سرویس مسافرین نیازی به دونستن پیاده سازی سرویس رانندگان نباید داشته باشه اما باید بدونه زمانی که با اینترفیس سرویس رانندگان ارتباط برقرار میکنه اگر چه ورودی هایی رو بده چه خروجی هایی رو دریافت میکنه.
عالی بوداش بابی جان برای این که دانش این موضوع به دست بیاریم چه تئوری و چه عملی پیشنهادی داری در ضمن این رو هم بگم که من python back-end هستم می خواهم این موضوع اصولی یادبگیر ام سپاس .
سلام، این کتاب رو پیشنهاد میکنم برای بحث میکروسرویس خیلی کمک کننده و کامل هست: Sam Newman - Building Microservices - Designing Fine-Grained Systems-O'Reilly Media (2021)
عالی بود استاد فقط من یه سوال داشتم این مطالب مثل معماری نرم افزار به درد چه کسایی می خوره ؟ بک اند دولوپرها؟ موبایل دولوپر ها ؟ یا مثلا شرکت هایی که مهندس نرم افزار استخدام می کنن اون مهندس نرم افزار دقیقا چه مهارت هایی باید بلد باشه ؟ باید بک اند و موبایل رو باهم بلد باشه ؟ یا نه؟ من اینا واقعا گیجم کرده ممنون میشم راهنمایی کنید
ممنونم از حسن توجهت سیاوش عزیز، نه لازم نیست بک اند و موبایل رو باهم بلد باشید و شرکت ها انتظار ندارند که همچین کاری رو انجام بدید. شرکت های بزرگ آدم متخصص توی یک حوزه میخوان نه کسی که چند تا حوزه رو نصفه و نیمه بلد هست. مهارت هایی مثل معماری نرم افزار به درد هر مهندس نرم افزاری میخوره که میخواد توی کارش پیشرفت کنه چون هر نرم افزاری بر پایه یک سری معماری ها ساخته میشه و نرم افزارهای بدون معماری دیر یا زود محکوم به شکست هستند. این معماری در هر اپلیکیشن و سرویسی هست و فرقی نمیکنه فرانت اند و موبایل معماری داره و بک اند معماری داره و کلا همه اپلیکیشن های خوب معماری دارند. سوالی داشتید حتما بپرسید. موفق و سلامت باشید دوست من ✌💚
ممنونم از انرژی مثبت و حسن توجهت پارسا عزیز، یوزکیس دیاگرام معمولا برای تعاملات کاربر با یک سیستم هست و موارد استفاده کاربر از سیستم رو نشون میده، مثلا روند ثبت نام کاربر میتونه در یوزکیس دیاگرام نمایش داده بشه. اما سرویس دیاگرام معمولا برای معماری سرویس ها و نحوه ی تعامل سرویس ها استفاده میشه تا یک هدف خاص رو برآورده کنن. معمولا این دیاگرام ها در کنار همدیگر به همراه دیاگرام های دیگر استفاده میشن. سوالی داشتید حتما بپرسید. موفق و سلامت باشید دوست من ✌💚
سلام وقت بخیر، سعی میکنم راجع به این موضوع ویدئوهای بیشتری ضبط کنم. کوهیژن به معنای یکپارچگی هست و کوهیژن بالا به معنای یکپارچی بالای یک سرویس یا حتی یک شی هست. یعنی سرویس یا شی مورد نظر باید تمام پیاده سازی های فنی مورد نظر رو درون خودش داشته باشه و وابسته به سرویس های دیگه نباشه. امیدوارم خوب توضیح داده بشم. اگر سوالی داشتید حتما بپرسید. موفق و سلامت باشید دوست من
خیلیم عالی آقا یه سوال : توی ویدیو مونولیت دیزاین پترن layerd monolithic دقیقا همین مفاهیم صدق میکنه . همه اپ ها جدا از هم هستن . هرکدوم پکیج های خودشونو دارن و با یه چارچوب خاصی باهم ارتباط دارن حالا مایکروسرویس هم دقیقا همینطوریه . فرق بین layerd monolithic و microservice چیه؟ توی مایکروسرویس مگه mvc نمیتونیم استفاده کنیم؟ و در اخر اینکه این مفاهیم برای سمت فرانت اند هم میشه استفاده کرد یا فقط مربوط به بکند و سروره؟ بازم ممنون
سلام وقت بخیر، فرق مونولیث لایه بندی شده و میکروسرویس در این هست که دیپلویمنت جداگانه دارن و معمولا در بیزینس دامین های جداگانه ای هستن و به صورت کامل دغدغه های جداگانه ای دارن که بهش میگیم separation of concerns درکل تفاوت زیادی در نحوه ی دیپلویمنت و نگهداری مونولیث لایه بندی شده و میکروسرویس هست در فرانت اند هم میتونه استفاده باشه مثلا میتونیم برای هر میکروسرویس فرانت اند جداگانه هم داشته باشیم که توسط gateway یکپارچه میشن خیلی بستگی به معماری نرم افزار و ساختار شرکت داره که از این قابلیت استفاده بکنن یا نه.
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عالی گفتی...به همین داشتم فکر میکردم ..وقتی استقرارمون ممکنه خیلی وابسته باشه که زمان طراحی تا حد ممکن کاپلینگ کم نشده باشه...مرسی از جواب کاملت
درود استفاده کردیم. اما متاسفانه خیلی یکنواخت بود و طولانی. من دقیقه 20 خوابم برد. داشتم توی ماشین میدیدم. اگه ماشین جلویی فلش نمیزد کامل خوابیده بودم.
بسیار غالی بود . مطلب بسیار جالبی بود.دقیقا همینطور که خودتون اشاره کردید مایکروسرویس ها تقریبا با ظهور یونکس و سیستم عاملهای لینوکسی متولد شدن . بیشتر این تکنولوژی ها که که الان در موردشون بحث میشه و مطرح میشن قبلا بودن .
خیلی ممنونم از توضیحات تکمیلی و انرژی مثبتت فرید عزیز، بله دقیقا همینطور هست سرویس های اصطلاحا ریزدانه زمان زیادی هست که در دنیای نرم افزار وجود داشند اما خب با اسم های جدید ترند میشن و گاها باعث میشن آدم ها در شناخت سلوشن های درست دچار خطا بشن. موفق و سلامت باشید دوست من ✌💚
مهندس عالی و بینظیر بود ♥
ویدئوهات عالین عالی
خیلی ممنونم مهدی جان سلامت باشید 🙏🌹
ویدیو جالبی بود تشکر
خیلی ممنونم از لطفتون سلامت و موفق باشید عزیز ✌️❤️
خیلی عالی بابی جان. خسته نباشی. استفاده کردیم.
ممنونم موفق باشی علیرضا جان ✌️
عالی بودش خیلی خوندم راجب این موضوع اما موجه نمیشدم الی توضیح دادید ممنون
خیلی ممنونم از لطفت وحید جان سلامت باشی 🙏🌹
عالی بود مهندس. متشکرم
ممنونم از لطفت احسان عزیز، سلامت و موفق باشی دوست من ✌💚
This is one of the best videos i have ever seen about microservices.
Thank you so much, Reza. I'm delighted that you enjoyed it!🙏❤️
عالی بود. ممنون
ممنونم از حسن توجهت دوست من ✌💙 سلامت و موفق باشی
بسیار عالی توضیح دادین
از حسن توجهتون سپاسگزارم محمدرضا عزیز، سلامت و موفق باشید 🙏🌷
ممنون عالی بود
خیلی ممنونم مجتبی عزیز سلامت و موفق باشید دوست من 🙏🌺
ویدیوی خوب و کارآمدی بود لطفاًاگر فرصتش بود بازم راجب micro services ویدیو بسازی
سلام چشم حتما ممنونم از فیدبکتون میلاد جان 🙏🌹
دمت گرم - عالی بود.
ممنونم از حسن توجه و نظر لطفت داوود عزیز. سلامت و موفق باشی عزیز 💚
سلام عالی بود استاد😍
ممنونم از حسن توجهت حامد عزیز، سلامت و موفق باشی دوست من ✌💚
thanks 🌼
ممنونم از حسن توجهتون، سلامت و موفق باشید 🌺✌️
such a perfect presentation of microservices. 👌👌👌 thank you so much.
Excellent.
عالی هستیییی بابی جان
سپاس از انرژی مثبتت محمد علی عزیز، سلامت و موفق باشید 🌷🙏
خیلی خوب بود تازه پیدات کردم
ممنونم از لطفت مهدی جان سلامت باشید 🙏💙
ممنون محمد جان عالی . خسته نباشید 🙂
ممنونم از حسن توجه و انرژی مثبتت حسین عزیز، سلامت و موفق باشی دوست من 💚✌
ممنون خیلی عالی بود😇
خیلی ممنونم مهدی جان، سلامت باشید 🙏🌹
خییلی عالی
ممنونم از انرژی مثبتت حسین عزیز، سلامت و موفق باشی دوست من ✌💚
بسیار عالی
🙏🌹
عالی بود دم شما گرم
ممنونم از نظر لطف و حسن توجهت صابر عزیز، سلامت و موفق باشی دوست من ✌💙
میشه لطفا چنتا منبع که به صورت عملی پیاده سازیش رو آموزش میدن معرفی کنید ممنون
سلام وقت بخیر، این کتاب رو پیشنهاد میکنم وحید جان: Building Microservices: Designing Fine-Grained Systems
واقعا بینظیر بود . خسته نباشی داداش
Excellent 👏
مثل همیشه عالی هستی😍😍😍😍
مرررسی کلی همسر عزیزم 😍😊💕💖😘
بسیار عالی 👌
خیلی ممنونم از انرژی مثبت و حسن توجهت امیرحسین عزیز، سلامت و موفق باشی دوست من ✌💚
Excellent
Many thanks 🙏🌹
عاااالی بود. واقعا عااالی بود
بابی عزیز خیلی کامل و عالی توضیح دادی. اصل مطلب رو ادا کردین با این ویدئو.
خیلی ممنونم از انرژی مثبت و حسن توجهت هادی عزیز، سلامت و موفق باشید ✌🌷
بسیار مفید بود 👍
سپاسگزارم پدرام عزیز، سلامت و موفق باشید دوست من ✌🌷
ممنون از آموزش خوب شما
جناب مهندس اگر مقدوره در مورد ابزارهایی که باهاش میشه معماری میکروسرویس رو هم پیاده کرد بیشتر توضیح بدید
ممنونم
ممنونم از انرژی مثبتت دوست من، به زودی ویدئوهای بیشتری در زمینه مایکروسرویس ها و سیستم دیزاین در کانال منتشر میکنم که این موارد رو پوشش بدن. موفق و سلامت باشید و ممنونم از پیشنهاد خوبتون ✌💚
خیلی خوب بود مخصوصا مورد آخر در مورد اینکه طراحی مایکروسرویس نیاز به تخصص و دانش فنی زیاد داره و همچنین اینکه همیشه بهترین معماری نمی‌تونه باشه.
از نظر من برای نرم‌افزارهایی در اندازه کوچک و متوسط ، DDD کافیست.
ممنونم از حسن توجه و نظر لطفت مهران عزیز، بله دقیقا مایکروسرویس همیشه بهترین معماری نیست و باید در شرایط به خصوص و درستی از این معماری استفاده کرد. موفق و سلامت باشی دوست من ✌💚
عالی بود
سلام و درود، سپاسگزارم از حسن توجه و انرژی مثبتتون بابک عزیز، سلامت و موفق باشید ✌🌷
عالی❤️
🙏🌹
بسیار عالی و مفید بود مرسی از بابی عزیز
منتظر ویدیو های بعدی هستیم
ممنونم از حسن توجه و نظر لطفت فرهاد عزیز، حتما ویدئوهای جدید و بیشتری در این زمینه ضبط میکنم. موفق و سلامت باشی دوست من ✌💚
خیلی عالی بود
ممنونم از حسن توجهت مهدی عزیز، موفق و سلامت باشی برادر ✌💚
عالی بود استاد جان خسته نباشید به امید ویدئو های بیشتر
ممنونم از انرژی مثبت و حسن توجهت مجید عزیز، سلامت و موفق باشی دوست من ✌💚
بابی جان خسته نباشی👌
ممنونم از حسن توجهت احسان عزیز، سلامت و موفق باشی دوست من ✌💚
خیلی خوب بود واقعن مفهوم و روون شرح دادی👍
خیلی ممنونم سلامت باشید 🙏🌹
بسیار عالی و حرفه ای بود. نظر آخر رو خیلی پسندیدم، فشن پرستی خیلی رایج شده متاسفانه. یه سئوال: فرض کنید در ساختار بک‌اند یه تغییری ایجاد شده که یه فیچر جدید رو از فرانت میخواد. وقتی این تغییر اعمال میشه، دو راه وجود داره: یه مسیر اینه که ساختار قبلی هنوز هندل بشه و فیچر جدید صرفا پس بشه و یا اررور برگردونه بشه تا فرانت مجبور باشه تمام GUI های مرتبط رو اپدیت کنه. من نظرم اینه که فرانت باید اپشن اپدیت ساختار ور داشته باشه تا این ایگنور شدن بعدا تبدیل به یک معضل نشه ولی معمولا فشار میاد که باید پس کنید تا مشکلی پیش نیاد.
سلام، خیلی ممنونم از انرژی مثبت و حسن توجهت یوسف عزیز، در رابطه با سوالی که پرسیدید، آپدیت ها میتونن اختیار یا فورس باشن. معمولا در نرم افزارهای تجاری هر ۲ حالتش در نظر گرفته میشه و ممکنه تعداد زیادی از آپدیت ها اختیاری باشند و نرم افزار نسخه های قدیمی رو پشتیبانی بکنه اما ممکنه آپدیت هایی هم باشند که نیازمند پچ شدن سریع هستند و شاید حاوی باگ های امنیتی باشند که در این موارد از آپدیت های فورس یا اجباری استفاده میکنیم و کاربر برای ادامه ی کار با اپلیکیشن مجبور به آپدیت بشه. معمولا هر ۲ حالتش رو در نظر میگیریم تا بتونیم در شرایط خاص باتوجه به شرایط یک سلوشن رو انتخاب کنیم. اگر سوالی داشتید حتما بپرسید. موفق و سلامت باشید دوست من ✌💚
مرسی مهندس عزیز مثل همیشه عالی بود ممنون از وقتی که میزارین 🌹
ممنونم از انرژی مثبت و حسن توجهتون مجید عزیز، سلامت و موفق باشید دوست من 💚✌
بینهایت عالی بود
منتظر ویدیوهای بعدی هستیم.
🙏🌹
عالی، لطفا راجب معماری های نرم افزار بیشتر محتوا تولید کنید چون خیلی منابعش محدود هست 👌
ممنونم از نظر لطفت امین عزیز، حتما در رابطه با معماری ها ویدئوهای بیشتری تولید میکنم و پلی لیست جداگانه میسازم. موفق و سلامت باشی دوست من ✌💚
عالی بود
کتاب خوب برای مایکروسرویس ها معرفی میکنید .
ممنونم از حسن توجه و نظر لطفت علیرضا عزیز، به زودی ویدئوهایی برای معرفی منابع آموزشی و کتاب های کاربردی ضبط میکنم و راجع به این موضوع صحبت میکنم. ممنونم از پیشنهادت دوست من 🙏💚
عالی بود. خیلی مفید. لطفا ادامه بدین. 👍👌👌
سلامت باشید عزیز 🙏🌺
باریکلا کیفیت فنی محتوایی که ارائه میدی عالیه
ممنونم از نظر لطف و حسن توجهت مرتضی عزیز ✌💙 خوشحالم که کیفیت محتوا مورد رضایتتون واقع شده، سلامت و موفق باشید دوست من
Bestiary aali
you know, we need more and more technical videos, please, than you for good presentation, also for about your light board, I love it
Glad to hear that from you 😍
طبق چیزی که فهمیدم باید کارکرد و رفتار کل کلاس های مایکرو سرویس های دیگه رو بدونی که تداخل نخوریم ؟
درسته؟
مایکروسرویس ها نباید از پیاده سازی درونی همدیگه خبر داشته باشند و رفتارهای درونی همدیگر رو بدونند بلکه باید تنها از اینترفیس یا رابط همدیگر خبر داشته باشند. مثلا سرویس مسافرین نیازی به دونستن پیاده سازی سرویس رانندگان نباید داشته باشه اما باید بدونه زمانی که با اینترفیس سرویس رانندگان ارتباط برقرار میکنه اگر چه ورودی هایی رو بده چه خروجی هایی رو دریافت میکنه.
سپاس گزارم عااالی بود
لطفا در این مورد مطالب بیشتری بزارید لطفا مثال در پروژه واقعی هم بزارید
خیلی ممنونم از انرژی مثبتت رضا جان. حتما توی برنامه ام هست. موفق و سلامت باشید ✌🌷
nice ❤❤❤❤
💙💙
درمورد تفاوت کار تو شرکت های ایران و ترکیه هم ویدیو درست کنین
خیلی مفید بود ممنون ازتون
حتما سعی میکنم در این رابطه ویدئوهایی رو ضبط کنم. ممنونم از پیشنهاد خوبت دوست من، سلامت و موفق باشید ✌💚
Another one 💪💙
Thank you for your positive energy my friend 😍💚
عالی بوداش بابی جان برای این که دانش این موضوع به دست بیاریم چه تئوری و چه عملی پیشنهادی داری در ضمن این رو هم بگم که من python back-end هستم می خواهم این موضوع اصولی یادبگیر ام سپاس .
سلام، این کتاب رو پیشنهاد میکنم برای بحث میکروسرویس خیلی کمک کننده و کامل هست:
Sam Newman - Building Microservices - Designing Fine-Grained Systems-O'Reilly Media (2021)
@@BobyCloud ممنون ام از راهنمایت بابی جان
👌👌
💚✌
عالی بود استاد فقط من یه سوال داشتم این مطالب مثل معماری نرم افزار به درد چه کسایی می خوره ؟ بک اند دولوپرها؟ موبایل دولوپر ها ؟
یا مثلا شرکت هایی که مهندس نرم افزار استخدام می کنن اون مهندس نرم افزار دقیقا چه مهارت هایی باید بلد باشه ؟ باید بک اند و موبایل رو باهم بلد باشه ؟ یا نه؟
من اینا واقعا گیجم کرده ممنون میشم راهنمایی کنید
ممنونم از حسن توجهت سیاوش عزیز، نه لازم نیست بک اند و موبایل رو باهم بلد باشید و شرکت ها انتظار ندارند که همچین کاری رو انجام بدید. شرکت های بزرگ آدم متخصص توی یک حوزه میخوان نه کسی که چند تا حوزه رو نصفه و نیمه بلد هست. مهارت هایی مثل معماری نرم افزار به درد هر مهندس نرم افزاری میخوره که میخواد توی کارش پیشرفت کنه چون هر نرم افزاری بر پایه یک سری معماری ها ساخته میشه و نرم افزارهای بدون معماری دیر یا زود محکوم به شکست هستند. این معماری در هر اپلیکیشن و سرویسی هست و فرقی نمیکنه فرانت اند و موبایل معماری داره و بک اند معماری داره و کلا همه اپلیکیشن های خوب معماری دارند. سوالی داشتید حتما بپرسید. موفق و سلامت باشید دوست من ✌💚
ویدیو عاااالی بود مثل همیشه! یه سوال هم دارم. تفاوت سرویس ها در یوزکیس دیاگرام با سرویس ها در معماری مایکروسرویس چیه؟
ممنونم از انرژی مثبت و حسن توجهت پارسا عزیز، یوزکیس دیاگرام معمولا برای تعاملات کاربر با یک سیستم هست و موارد استفاده کاربر از سیستم رو نشون میده، مثلا روند ثبت نام کاربر میتونه در یوزکیس دیاگرام نمایش داده بشه. اما سرویس دیاگرام معمولا برای معماری سرویس ها و نحوه ی تعامل سرویس ها استفاده میشه تا یک هدف خاص رو برآورده کنن. معمولا این دیاگرام ها در کنار همدیگر به همراه دیاگرام های دیگر استفاده میشن. سوالی داشتید حتما بپرسید. موفق و سلامت باشید دوست من ✌💚
Hello, sorry for my question because this may be a beginner.Are microservices running on separate servers? Doesn't that slow it down?
سلام، هم میتونن روی یک سرور باشن هم سرورهای جداگانه معمولا رایج هست که در سرورهای جداگانه باشن.
❤
✌💚
likeeeee
🌺🌺
لا کاپل و فهمیدم ولی کوهیژن واقعا نامفهوم بود برام
سلام وقت بخیر، سعی میکنم راجع به این موضوع ویدئوهای بیشتری ضبط کنم. کوهیژن به معنای یکپارچگی هست و کوهیژن بالا به معنای یکپارچی بالای یک سرویس یا حتی یک شی هست. یعنی سرویس یا شی مورد نظر باید تمام پیاده سازی های فنی مورد نظر رو درون خودش داشته باشه و وابسته به سرویس های دیگه نباشه. امیدوارم خوب توضیح داده بشم. اگر سوالی داشتید حتما بپرسید. موفق و سلامت باشید دوست من
چند وقتی هستش که فعالیت‌تون کم شده.
خوشحال میشیم برگردید💯
سلام، ممنونم از حسن توجهت حسین جان، به امید خدا برگشتم! 🙏💙
خیلیم عالی
آقا یه سوال : توی ویدیو مونولیت دیزاین پترن layerd monolithic دقیقا همین مفاهیم صدق میکنه . همه اپ ها جدا از هم هستن . هرکدوم پکیج های خودشونو دارن و با یه چارچوب خاصی باهم ارتباط دارن
حالا مایکروسرویس هم دقیقا همینطوریه . فرق بین layerd monolithic و microservice چیه؟ توی مایکروسرویس مگه mvc نمیتونیم استفاده کنیم؟
و در اخر اینکه این مفاهیم برای سمت فرانت اند هم میشه استفاده کرد یا فقط مربوط به بکند و سروره؟
بازم ممنون
سلام وقت بخیر، فرق مونولیث لایه بندی شده و میکروسرویس در این هست که دیپلویمنت جداگانه دارن و معمولا در بیزینس دامین های جداگانه ای هستن و به صورت کامل دغدغه های جداگانه ای دارن که بهش میگیم separation of concerns
درکل تفاوت زیادی در نحوه ی دیپلویمنت و نگهداری مونولیث لایه بندی شده و میکروسرویس هست
در فرانت اند هم میتونه استفاده باشه مثلا میتونیم برای هر میکروسرویس فرانت اند جداگانه هم داشته باشیم که توسط gateway یکپارچه میشن
خیلی بستگی به معماری نرم افزار و ساختار شرکت داره که از این قابلیت استفاده بکنن یا نه.
عالی! قثط نمیدونم چرا حس میکنم همش میخای بخندی وسطش:|
آره خندش میگیره 😂
ممنونم از حسن توجهت محمد جواد عزیز، خنده بر هر دردی دواست 😂 موفق و سلامت باشید دوست من 🙏💚
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عالی گفتی...به همین داشتم فکر میکردم ..وقتی استقرارمون ممکنه خیلی وابسته باشه که زمان طراحی تا حد ممکن کاپلینگ کم نشده باشه...مرسی از جواب کاملت
@@seyedmiladhashemi2094 قربانت عزیزدلی میلاد جان 😍❤️
درود استفاده کردیم. اما متاسفانه خیلی یکنواخت بود و طولانی. من دقیقه 20 خوابم برد. داشتم توی ماشین میدیدم. اگه ماشین جلویی فلش نمیزد کامل خوابیده بودم.
ممنونم از حسن توجهت میلاد جان،
سعی میکنم از این به بعد تایم ویدئوهارو کوتاه تر کنم که از حوصله خارج نشه و خدای نکرده مشکلی پیش نیاد عزیز 😂🙏💚
بسیار غالی بود . مطلب بسیار جالبی بود.دقیقا همینطور که خودتون اشاره کردید مایکروسرویس ها تقریبا با ظهور یونکس و سیستم عاملهای لینوکسی متولد شدن . بیشتر این تکنولوژی ها که که الان در موردشون بحث میشه و مطرح میشن قبلا بودن .
خیلی ممنونم از توضیحات تکمیلی و انرژی مثبتت فرید عزیز، بله دقیقا همینطور هست سرویس های اصطلاحا ریزدانه زمان زیادی هست که در دنیای نرم افزار وجود داشند اما خب با اسم های جدید ترند میشن و گاها باعث میشن آدم ها در شناخت سلوشن های درست دچار خطا بشن. موفق و سلامت باشید دوست من ✌💚
فقط مقایسه جاوا و پایتون 😂
فیل در مقابل فنجان 😂✌
بسیار عالی
خیلی خیلی خیلی خوب بود . دم شما گرم و آفرین
دمت گرم - عالی بود