سلام دوستان برای اینکه وبینار بهتری کنار هم داشته باشیم این کانال ایجاد شده. تا جایی که امکانش هست تمام این وبینار ها رایگان خواهد بود

بیش از 100 نفر تو پرسشنامه شرکت کردند که جا داره از همه دوستان بابت لطف و اعتمادی که نسبت به بنده دارند تشکر کنم. موضوعی که بیشتر افراد روش اتفاق نظر داشتند DDD و Microservice architecture بود که بنظرم خوبه که با Microservice architecture شروع کنیم و مطمئنم که بحث و موضوعات جالبی رو میتونیم در موردش داشته باشیم. پلتفرمی که برای وبینار انتخاب کردم Discord هست که لینکش رو اینجا براتون میذارم. اگه نظر یا پیشنهادی دارید حتما با من از طریق آیدی تلگرام @BoB_Tm در میون بذارید. ممنونم

چالش ها و سوالاتی رو که در مورد Microservice Architecture دارید تو قسمت کامنت ها بنویسید

#fun
یکی از مشکلاتی که اپلیکیشن های monolithic دارند اینه که حل یک مشکل باعث بوجود اومدن مشکلات بیشتر میشه. یک تار عنکبوت رو در نظر بگیرید که اگه یک سمتش تکون بخوره سمت کاملا مخالفش هم تحت تاثیر اون تکون قرار میگیره
در فلسفه نرم افزار لغتی وجود داره به اسم Cohesion (معنی فارسیش میشه انسجام که بنظرم حق مطلب رو خوب ادا نمیکنه). یک سرویسی که یک کار مشخص رو به خوبی انجام میده بعنوان High Cohesion تعریف میشه. توسعه و نگهداری و فهم چنین سرویسی کار بسیار ساده ای هست و از طرفی دیباگ چنین کدی کار بسیار ساده و لذت بخشی میشه.
در مقابل low cohesion وجود داره. مثلا در یک اپلیکشین monolithic یک class library رو در نظر بگیرید که هزارتا کار مختلف رو انجام میده و اصلا مشخص نیست که چه کاری رو چجوری داره انجام میده( اوضاع جایی بدتر میشه که ما این وسط hidden dependency هم داشته باشیم. و شمای برنامه نویس ناخودآگاه یک کلاس یا متدی‌ رو دستکاری کنی که چنتا کلاس دیگه وابسته بهش بودن و شما روحت هم از این قضیه خبر نداشته)

ادامه:
یکی از دلایل محبوبیت Microservice Architecture هم همین ایجاد High Cohesion هست. جایی که یک سرویس فقط و فقط وظیفه خودش رو انجام میده و سایر وابستگی هاش رو از سرویس های‌ دیگه تامین میکنه و اگه مشکل یا باگی براش پیش بیاد کل سیستم رو دچار مشکل نمیکنه
البته این برداشت نشه که از فردا همه باید بریم سروقت معماری میکروسرویس، ولی خوبه که موقع برنامه نویسی این سوال ها رو از خودتون بپرسید:
فهم کدی که نوشتید چقدر سخته؟
اگر این کد فردا پس فردا تغییر کنه مشکلی برای کل سیستم بوجود میاره؟
تغییرات این قسمت از کد روی کدوم قسمت های سیستم تاثیر میذاره؟
آیا وظیفه کد برای برنامه نویسی جز خودم مشخصه؟
کد نوشته شده دقیقا یک وظیفه مشخص رو انجام میده؟ یا تبدیل شده به آچار فرانسه؟
اضافه کردن فیچر جدید به این کد چقدر سخته؟

Overthinking damages everything
خیلی از دوستان هستند که به بنده لطف دارند و سوالی که براشون پیش میاد رو میپرسن.
مسئله ای که برام جالبه اینه که همه ما گاهی اوقات اینقدر وسواس به خرج میدیم که کلا اصل مسئله ای که قراره حل کنیم رو فراموش می کنیم. احتمالا سه تا اصطلاح زیر رو شنیده باشید
-YAGNI principle
-KISS
-No Tricky Code
اصطلاح اول میگه که بعضی از قابلیت هایی که سیستم درحال توسعه ممکنه در آینده بهش نیاز پیدا کنه رو الان نباید پیاده سازی کرد. و طبیعتا یک سری نیازها هست که شما نمیتونید به عنوان یک برنامه نویس پیشبینی کنید. وقتی زمان پیاده سازیش رسید، اون موقع بهش فکر کنید.
اصطلاح دوم و سوم در اصل یک چیز رو میگن. اونم اینه که خودتون رو درگیر پیچیدگی هایی که هیچ نیازی بهشون نیست نکنید. همیشه در ساده ترین حالت ممکن یک سیستم رو پیاده سازی کنید. بعد از پیاده سازی به ریفکتور و بهبودش فکر کنید. اگر بخوایم یه مثال باحال واسش بیاریم میتونیم به RED GREEN REFACTOR توی TDD اشاره کنیم. که شما اول نیاز های سیستم رو توی تست مینویسید و طبعا Test شما Fail یا قرمز میشه.

ادامه:
در مرحله بعد شما کدی رو مینویسید که فقط نیاز این تست رو برطرف کنه و تست شما سبز یا Pass بشه و در مرحله آخر به ریفکتور کدی که زدید فکر میکنید.
همیشه اینو در نظر داشته باشید که وسواس بیش از حد به محصول نهایی شرکت یا پروژه صدمه میزنه. و کلام آخر اینکه برنامه نویسی یک ابزاره برای تولید محصول یا ایجاد یک بیزینس موفق.

کلی اسلاید و مثال باحال واسه وبینار فردا آماده کرده بودم اما بخاطر کرونا کلا صدام در نمیاد. از همه دوستان عذرخواهی میکنم ایشالله هفته بعد وبینار رو برگزار میکنیم. قبلش هم اسلاید ها تو این گروه قرار میگیره و دمو ها داخل گیتهاب
گیتهاب:
https://github.com/babaktaremi

ساعت ۵ یادتون نره دوستان...

ویدیو وبینار امروز
خیلی ممنون از دوستانی که وقت گذاشتن و شرکت کردند. اگر مشکلی ( چه فنی چه...) وجود داره پیشاپیش عذرخواهی میکنم و حتما بمن بگید که اصلاحش کنم