📌 BackEnd (Golang) Engineer

📝 Visa Sponsorship: ✅

🌍 Relocation Package: ✅

🏢 Company: moon active

📍 Location: POLAND

⌨️ Category: #Programming

🔗 Tags: #python #golang #redis #rabbitmq #gcp #grpc #sqs #c #server #kubernetes #aws #docker #devops #cloud #scrum #sql

➖➖➖➖➖➖➖➖

📌 Staff Backend Engineer

📝 Visa Sponsorship: ✅

🌍 Relocation Package: ✅

🏢 Company: plexus resource solutions

📍 Location: CANADA

⌨️ Category: #Programming

🔗 Tags: #golang #microservices #cloud #blockchain

➖➖➖➖➖➖➖➖
📌 Backend Engineer

📝 Visa Sponsorship: ✅

🌍 Relocation Package: ❌

🏢 Company: sword health

📍 Location: PORTUGAL

⌨️ Category: #Programming

🔗 Tags: #nosql #golang #redis #c #responsive #sql

➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

✍️فرق kafka و rabbitmq

🔵معماری
🟢Kafka:

🔻مدل انتشار-اشتراک: Kafka بر اساس مدل انتشار-اشتراک (publish-subscribe) کار می‌کند. تولیدکنندگان پیام‌ها را به مباحث (topics) می‌فرستند و مصرف‌کنندگان پیام‌ها را از این مباحث می‌خوانند.
🔻ذخیره‌سازی پایدار: Kafka پیام‌ها را به صورت پایدار در دیسک ذخیره می‌کند و به مصرف‌کنندگان اجازه می‌دهد که پیام‌ها را بر اساس آفست (offset) خاصی دوباره بخوانند.
🔻مقیاس‌پذیری: Kafka به راحتی مقیاس‌پذیر است و می‌تواند به صورت افقی با افزودن نودهای بیشتر در کلاستر (cluster) خود گسترش یابد.
🔻کارایی بالا: Kafka برای پردازش حجم زیادی از داده‌ها با تاخیر کم و توان عملیاتی بالا طراحی شده است.
🟢RabbitMQ:

🔻مدل صف-پیام: RabbitMQ بر اساس مدل صف-پیام (message queue) کار می‌کند. پیام‌ها در صف‌ها قرار می‌گیرند و مصرف‌کنندگان پیام‌ها را از صف‌ها می‌خوانند.
🔻قابلیت‌های مسیریابی پیشرفته: RabbitMQ از انواع مختلف مبادلات (exchanges) مانند مستقیم، موضوعی و هدرها برای مسیریابی پیام‌ها استفاده می‌کند.
🔻پشتیبانی از پروتکل‌های مختلف: RabbitMQ از پروتکل‌های مختلف پیام‌رسانی مانند AMQP، MQTT و STOMP پشتیبانی می‌کند.
🔻سادگی: RabbitMQ به راحتی قابل نصب و پیکربندی است و برای موارد استفاده ساده‌تر بسیار مناسب است.

🔵موارد استفاده
🟢Kafka:

🔻پردازش داده‌های جریانی: Kafka برای پردازش داده‌های جریانی و تجزیه و تحلیل داده‌های بزرگ در زمان واقعی بسیار مناسب است.
🔻سیستم‌های ثبت تراکنش (log): Kafka به عنوان یک سیستم ثبت تراکنش توزیع شده برای نگهداری و پردازش لاگ‌های بزرگ استفاده می‌شود.
🔻میکروسرویس‌ها: Kafka به عنوان یک سیستم پیام‌رسانی توزیع شده برای ارتباط بین میکروسرویس‌ها استفاده می‌شود.

🟢RabbitMQ:

🔻میکروسرویس‌ها: RabbitMQ نیز برای ارتباط بین میکروسرویس‌ها مناسب است، به ویژه در مواردی که نیاز به مسیریابی پیشرفته پیام‌ها وجود دارد.
🔻مدیریت وظایف: RabbitMQ برای مدیریت و پردازش وظایف پس‌زمینه مناسب است.
🔻سیستم‌های صف: RabbitMQ برای مواردی که نیاز به صف‌های ساده برای پیام‌رسانی و مدیریت بار کاری وجود دارد، مناسب است.

🔵کارایی و مقیاس‌پذیری
🟢Kafka:

🔻توان عملیاتی بالا: Kafka برای پردازش حجم زیادی از داده‌ها با توان عملیاتی بالا و تاخیر کم طراحی شده است.
🔻مقیاس‌پذیری افقی: Kafka به راحتی با افزودن نودهای بیشتر به کلاستر خود مقیاس‌پذیر است.
🟢RabbitMQ:

🔻کارایی متوسط: RabbitMQ نیز کارایی بالایی دارد، اما در مقایسه با Kafka ممکن است برای حجم بسیار زیاد داده‌ها کارایی کمتری داشته باشد.
🔻مقیاس‌پذیری: RabbitMQ به صورت افقی مقیاس‌پذیر است، اما ممکن است برای مقیاس‌بندی به اندازه Kafka بهینه نباشد.

🥂جمع‌بندی
🟢Kafka:

🔻مناسب برای پردازش داده‌های جریانی، سیستم‌های ثبت تراکنش و ارتباط بین میکروسرویس‌ها با حجم بالای داده‌ها.
🔻توان عملیاتی بالا و مقیاس‌پذیری افقی عالی.
🟢RabbitMQ:

🔻مناسب برای مدیریت وظایف، مسیریابی پیشرفته پیام‌ها و سیستم‌های صف با نیاز به پشتیبانی از پروتکل‌های مختلف.
🔻سادگی در نصب و پیکربندی و قابلیت‌های مسیریابی پیشرفته.

➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

7 استراتژی مهم برای اسکیل کردن دیتابیس تون👌
➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

✍️در زبان برنامه‌نویسی Go و به ویژه در کتابخانه net/http`، دو مقدار `nil و http.NoBody تفاوت‌های مهمی دارند که باید به آن‌ها توجه کنید. این تفاوت‌ها به ویژه در زمینه استفاده از درخواست‌ها (requests) و پاسخ‌ها (responses) اهمیت پیدا می‌کنند.

🟢nil

در Go، nil می‌تواند به عنوان مقدار پیش‌فرض برای انواع اشاره‌گرها، رابط‌ها (interfaces)، نقشه‌ها (maps)، اسلایس‌ها (slices)، کانال‌ها (channels) و توابع استفاده شود. وقتی که یک متغیر از نوع اشاره‌گر یا رابط مقدار nil دارد، به این معنی است که به هیچ چیز اشاره نمی‌کند یا مقداردهی نشده است.

🔵 ویژگی‌ها:
1. عدم اشاره به هیچ چیز: nil به این معنی است که هیچ مقدار یا آدرسی وجود ندارد.
2. پیش‌فرض برای اشاره‌گرها و رابط‌ها: بسیاری از انواع داده‌ها می‌توانند مقدار nil داشته باشند، از جمله *http.Request.Body.

🟢http.NoBody

اhttp.NoBody یک مقدار خاص در بسته net/http است که به طور خاص به عنوان یک جایگزین برای بدنه‌ی (body) خالی در درخواست‌ها و پاسخ‌ها استفاده می‌شود. این مقدار به طور خاص برای بهینه‌سازی و جلوگیری از استفاده از منابع غیرضروری طراحی شده است.

🔵 ویژگی‌ها:
1. بدنه خالی بهینه شده: http.NoBody به جای استفاده از یک اشاره‌گر nil برای بدنه خالی، به عنوان یک جایگزین بهینه شده استفاده می‌شود.
2. پیاده‌سازی `io.ReadCloser`: http.NoBody یک نوع خاص است که io.ReadCloser را پیاده‌سازی می‌کند و همیشه خواندن صفر بایت را برمی‌گرداند و بستن بدون خطا.

🔵 مزایا:
1. کاهش استفاده از منابع: به دلیل پیاده‌سازی خاص، استفاده از http.NoBody می‌تواند منجر به کاهش استفاده از منابع و بهینه‌سازی عملکرد شود.
2. سازگاری با رابط‌ها: چون http.NoBody رابط io.ReadCloser را پیاده‌سازی می‌کند، می‌توان آن را در جاهایی که انتظار io.ReadCloser می‌رود، به کار برد.

🔵 مقایسه در زمینه HTTP
هنگام کار با درخواست‌ها (requests) و پاسخ‌ها (responses) در net/http`، تفاوت بین استفاده از `nil و http.NoBody مهم است.

🔵 مثال: ایجاد یک درخواست HTTP با بدنه خالی
استفاده از nil:

req, err := http.NewRequest("GET", "http://example.com", nil)
if err != nil {
    // handle error
}

در اینجا، بدنه درخواست به صورت nil تعیین می‌شود که به معنای عدم وجود بدنه است.
🔵استفاده از http.NoBody:

req, err := http.NewRequest("GET", "http://example.com", http.NoBody)
if err != nil {
    // handle error
}

در اینجا، بدنه درخواست به طور صریح به عنوان http.NoBody تنظیم می‌شود که نشان‌دهنده یک بدنه خالی بهینه شده است.

🍾 جمع‌بندی

- `nil`:
- نشان‌دهنده عدم وجود بدنه یا مقدار.
- مقدار پیش‌فرض برای انواع اشاره‌گرها و رابط‌ها.
- می‌تواند برای بدنه‌های خالی استفاده شود، اما از لحاظ عملکردی بهینه نیست.

- `http.NoBody`:
- نشان‌دهنده یک بدنه خالی بهینه شده برای درخواست‌ها و پاسخ‌ها.
- پیاده‌سازی io.ReadCloser.
- بهینه‌تر برای مواردی که بدنه خالی نیاز است، به ویژه در زمینه HTTP.

به طور کلی، استفاده از http.NoBody به جای nil در مواردی که بدنه خالی در HTTP نیاز است، می‌تواند به بهبود عملکرد و کاهش استفاده از منابع کمک کند.
➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

Massimo DevMassimo Dev

#برنامه_نویس سنیور کیه واقعا؟

فقط یک جمله:
کسی که برای پیچیده‌ترین صورت مسأله‌ها، ساده‌ترین راه حل‌ها رو ارائه میده.

اگر حس می کنید کدنویسی پیچیده یعنی سنیوریتی، باخت دادید تا الان.

مشتی باشید!
➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

برای رسیدن به متریک مناسب سرویس تون یه سری راه حل اینجا گذاشته
➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

📌 Go Developers (m/f/d) create masterpieces & pioneering work in the backend while their career takes off at the front!

📝 Type: Visa Sponsorship

🌍 Relocation Package: ✅

🏢 Company: mytalentscout gmbh

📍 Location: GERMANY

⌨️ Category: #Programming

🔗 Tags: #golang #mysql #ai


📌 Backend Engineer (Tabby Finance)

📝 Type: Visa Sponsorship

🌍 Relocation Package: ✅

🏢 Company: tabby

📍 Location: SERBIA

⌨️ Category: #Programming

🔗 Tags: #golang #postgresql #redis #kubernetes #cloud #gitlab

➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

لیستی از مکانیزم های قفل برای جلوگیری از دسترسی همزمان دادها و ناسازگاری داده ها
👇👇👇👇
➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

🔻لیستی از مکانیزم های قفل برای جلوگیری از دسترسی همزمان دادها و ناسازگاری داده ها🔻

🎯1. Shared Lock (S Lock)
It allows multiple transactions to read a resource simultaneously but not modify it. Other transactions can also acquire a shared lock on the same resource.

🎯2. Exclusive Lock (X Lock)
It allows a transaction to both read and modify a resource. No other transaction can acquire any type of lock on the same resource while an exclusive lock is held.

🎯3. Update Lock (U Lock)
It is used to prevent a deadlock scenario when a transaction intends to update a resource.

🎯4. Schema Lock
It is used to protect the structure of database objects.

🎯5. Bulk Update Lock (BU Lock)
It is used during bulk insert operations to improve performance by reducing the number of locks required.

🎯6. Key-Range Lock
It is used in indexed data to prevent phantom reads (inserting new rows into a range that a transaction has already read).

🎯7. Row-Level Lock
It locks a specific row in a table, allowing other rows to be accessed concurrently.

🎯8. Page-Level Lock
It locks a specific page (a fixed-size block of data) in the database.

🎯9. Table-Level Lock
It locks an entire table. This is simple to implement but can reduce concurrency significantly.

➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

Massimo Dev

میدونستید #ایندکس ترکیبی یا Composite Index تو #دیتابیس چی هست؟ یه سوالیه که معمولا تو #مصاحبه های #استخدام #برنامه_نویسی می‌پرسن!

ایندکس ترکیبی، ایندکسی هست که چندتا ستون رو باهم تو خودش داره. یعنی به جای اینکه فقط یه ستون رو ایندکس کنیم، میایم و چندتا ستون رو با همدیگه ایندکس می‌کنیم تا وقتی که توی کوئری‌ها (دستورات جستجو) از چندتا ستون استفاده می‌کنیم، دیتابیس سریع‌تر بتونه نتایج رو پیدا کنه.

👈 مثال از ایندکس ترکیبی

فرض کن یه جدول به اسم employees داریم که این ستون‌ها رو داره:

- employee_id
- first_name
- last_name
- department
- hire_date

اگه بخوایم جستجوهایی که بر اساس department و hire_date هستن سریع‌تر بشن، میایم و یه ایندکس ترکیبی روی این دوتا ستون درست می‌کنیم:

CREATE INDEX idx_department_hire_date ON employees(department, hire_date);

👈 ترتیب ستون‌ها توی ایندکس ترکیبی:

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

🍒 مثال‌هایی از کوئری‌ها

1. کوئری‌ای که از هر دو ستون استفاده می‌کنه**:

 SELECT * FROM employees WHERE department = 'Sales' AND hire_date = '2023-01-15';
 

این کوئری می‌تونه از ایندکس ترکیبی idx_department_hire_date کامل استفاده کنه.

2. کوئری‌ای که فقط از ستون اول استفاده می‌کنه:

 SELECT * FROM employees WHERE department = 'Sales';
 

این کوئری هم می‌تونه از ایندکس استفاده کنه چون با ستون department شروع شده.

3. کوئری‌ای که فقط از ستون دوم استفاده می‌کنه:

 SELECT * FROM employees WHERE hire_date = '2023-01-15';
 

این کوئری نمی‌تونه به طور مؤثری از ایندکس ترکیبی idx_department_hire_date استفاده کنه، چون با ستون department شروع نمی‌شه. به این معنا نیست که تحت هیچ شرایطی از ایندکس استفاده نمی‌کنه، بلکه به این معناست که از بخش زیادی از ایندکس استفاده نمی‌شه و عملاً سود چندانی از ایندکس نمی‌بره.

4. کوئری‌ای که از هر دو ستون ولی به ترتیب برعکس استفاده می‌کنه:

 SELECT * FROM employees WHERE hire_date = '2023-01-15' AND department = 'Sales';
 

این کوئری هم می‌تونه از ایندکس استفاده کنه چون از هر دو ستون استفاده کرده، ولی بهتره ستون‌ها رو به همون ترتیبی که تو ایندکس تعریف شدن استفاده کنیم.

👈👈👈 خلاصه

🔺 ترتیب مهمه: ترتیب ستون‌ها توی ایندکس ترکیبی خیلی مهمه. ایندکس وقتی بهترین کارایی رو داره که جستجوها از ستون‌های اول ایندکس شروع بشن.
🔺 استفاده از پیشوند: جستجوهایی که از ستون اول، دو ستون اول و همینطور ادامه دارن، از ایندکس بهره می‌برن.
🔺 استفاده جزئی: استفاده از ستون دوم یا بعدی بدون ستون اول نمی‌تونه از ایندکس ترکیبی استفاده کنه.

فهمیدن اینکه کوئری‌هات چجوری با ایندکس‌ها کار می‌کنن خیلی مهمه تا بتونی عملکرد دیتابیس رو بهتر کنی.

➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

Massimo Dev
📗 اصول مهم کد ریویو یا بررسی کد: YAGNI، KISS و DRY
من خودم موقع کد ریویوها این سه اصل رو خیلی با دقت رعایت می‌کنم.

🔶 1. YAGNI (You aren't gonna need it):
- این اصل داره میگه از اضافه کردن ویژگی‌ها یا کدی که الان لازم نیست خودداری کن. این کار باعث میشه کدت تمیز و ساده بمونه.
🔹 - مثال: اگه تو داری یه فرم ساده برای ورود اطلاعات می‌نویسی، لازم نیست از الان برای فیلتر کردن داده‌ها یا اضافه کردن قابلیت‌های پیچیده فکر کنی. اونها رو بعداً وقتی واقعاً نیاز بود اضافه کن.

🔶 2. KISS (Keep it simple & stupid):
- میگه سعی کن کدت ساده باشه. راه‌حل‌های پیچیده معمولاً میشه ساده‌ترشون کرد و این باعث میشه کد راحت‌تر خوانده و نگهداری بشه.
🔹 - مثال: به جای نوشتن یه تابع پیچیده برای محاسبه تخفیف، یه تابع ساده بنویس که فقط تخفیف رو بر اساس درصد حساب کنه. اگه بعداً نیاز به محاسبات پیچیده‌تر بود، اون موقع بهش اضافه کن.

🔶 3. DRY (Don't repeat yourself):
- میگه جایی که میشه، از کدهای موجود استفاده کن و از تکرار کد خودداری کن. این کار باعث میشه نگهداری کد راحت‌تر باشه و احتمال خطاها کمتر بشه.
🔹- مثال: اگه داری چند بار یه عملیات مشابه مثل محاسبه مالیات رو انجام میدی، اون رو تو یه تابع مجزا بنویس و هر بار از اون تابع استفاده کن.

با رعایت این اصول در کد ریویوها، می‌تونی کدی بنویسی که هم خواناتر، هم قابل نگهداری‌تر و هم بهینه‌تر باشه. همه چیز در مورد نوشتن کد کمتر ولی بهتره.

➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

Massimo Dev
🚀 تست‌نویسی در پروژه‌های بزرگ: بهترین روش‌ها و یه مثال واقعی 🚀

تو دنیای پرسرعت توسعه نرم‌افزار، تضمین کیفیت کد و اطمینان از عملکرد درست خیلی مهمه. روش تست‌نویسی قبل از کدنویسی (TDD) ثابت کرده که می‌تونه یه تغییر بزرگ ایجاد کنه، مخصوصاً تو پروژه‌های بزرگ. اینجا چندتا از بهترین روش‌ها برای اجرای TDD تو پروژه‌های بزرگ رو با یه مثال واقعی براتون می‌گم.

✅ 1. طراحی و معماری ماژولار
ما تو شرکت مون ابتدا سعی کردیم یه اپلیکیشن مونولیتیک رو به مایکروسرویس‌ها تقسیم کردیم. این کار نوشتن تست‌های مستقل برای هر سرویس رو آسون‌تر کرد و نگهداری و مقیاس‌پذیری رو بهتر کرد.

✅ 2. پایپلاین تست اتوماتیک
ما TDD رو با استفاده از Jenkins و GitHub Actions تو CI/CDمون ادغام کردیم. هر کامیت یه سری تست رو اجرا می‌کنه و بلافاصله بازخورد می‌ده و سلامت کد رو حفظ می‌کنه.

✅ 3. تست کاوریج (پوشش تست) و کیفیت
به جای دنبال کردن پوشش ۱۰۰٪، روی مسیرهای بحرانی تمرکز کردیم. مثلاً، تست احراز هویت کاربر به ما کمک کرد که مشکلات امنیتی رو زودتر پیدا و رفع کنیم

✅ 4. انواع و سطوح تست
- تست‌های واحد یا Unit Tests: اعتبارسنجی اجزای فردی.
- تست‌های یکپارچه‌سازی یا Integration Tests: اطمینان از عملکرد درست اجزا با هم.
- تست‌های End-to-End: تست کل ورک فلوهای اپلیکیشن.
تو پروژه، Unit Testing برای پردازش پرداخت‌ها با تست‌های End-to-End که تراکنش‌های واقعی کاربران رو شبیه‌سازی می‌کرد، اجرا شد تا عملکرد قوی‌ای داشته باشیم.

✅ 5. نگهداری تست‌ها
مرور و بازسازی منظم تست‌ها به ما کمک کرد تا مجموعه تست‌هامون رو مرتبط و کارآمد نگه داریم و بدهی فنی رو کاهش بدیم.

✅ 6. کد ریویو
بررسی دقیق کدها، شامل تست‌ها، فرهنگ ارتقاء کیفیت و مسئولیت مشترک بین اعضای تیم رو تقویت کرد.

✅ 7. ماکینگ و Stubbing
ما از ماک‌ها (Mocks) برای شبیه‌سازی درگاه‌های پرداخت خارجی استفاده کردیم تا تست‌هامون بدون وابستگی به سرویس‌های خارجی سریع و قابل اعتماد باشه.

✅ 8. تست‌های مقیاس‌پذیری و عملکرد یا Scalability & Performance Testing
قبل از نسخه‌های اصلی، بارگذاری سرویس‌هامون رو تست کردیم تا گلوگاه‌ها رو شناسایی کنیم و تو دوره‌های ترافیک بالا، عملکرد روان داشته باشیم.

✅ 9. مستندسازی و آموزش
مستندات جامع و جلسات آموزشی منظم در مورد بهترین روش‌های TDD تیم‌مون رو هماهنگ و مچ تر نگه داشت.

✅ 10. بازخورد و بهبود
جلسات رترو دو هفته‌ای یه فضایی رو برای بحث در مورد چالش‌ها و بهبودهای TDD فراهم کرد و رویکردمون رو به طور مداوم بهبود داد.

با ادغام این روش‌ها، فرآیند توسعه‌مون رو متحول کردیم و نتیجه‌ش نرم‌افزار با کیفیت‌تر و نسخه‌های قابل پیش‌بینی‌تر شد. TDD فقط یه روش نیست، یه ذهنیته که وقتی کامل پذیرفته بشه، می‌تونه بهبودهای قابل توجهی هم تو فرآیند توسعه و هم محصول نهایی ایجاد کنه.


#توسعه_نرم‌افزار #TDD #تضمین_کیفیت #DevOps #مایکروسرویس‌ها #اجایل
➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

خلاصه کتاب قورباغه ات را قورت بده در یک دقیقه:

♦️قانون اول:
فکر نکن بخورش.
اگه دو تا قورباغه روی میز هست و تو قراره اونارو بخوری نگاه کردن بهشون و تعلل کردن هیچ چیزی رو حل نمیکنه همین الان قورباغرو قورت بده

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

♦️قانون دوم :
اول زشته رو بخور
اگه دو تا قورباغه روی یک میز هست اول اونی که زشت تره رو بخور، اول اون کاری که سخت تره رو انجام بده

وقتی اول صبح کارای سختو انجام بدی اعتماد به نفس پیدا میکنی برای ادامه روزت.

➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

فرصت همکاری
دورکاری
Digital marketer

➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

Massimo Dev
آشنایی با اصول SOLID#

به عنوان برنامه‌نویس، همیشه دنبال نوشتن کد تمیز، قابل نگهداری و قابل گسترش هستیم. اصول SOLID یک سری راهنما برای رسیدن به این هدف‌ها ارائه می‌ده.

📍1. اصلSingle Responsible Principle (SRP)
- مفهوم: هر کلاس باید فقط یک دلیل برای تغییر داشته باشه و یک مسولیت رو بپذیره!
- مثال: فکر کن یه دستگاه قهوه‌ساز داری که هم قهوه درست می‌کنه و هم رادیو داره. اگه رادیو خراب بشه، ممکنه نتونی قهوه درست کنی تا رادیو تعمیر بشه. بهتره دستگاه‌های جدا برای قهوه و موسیقی داشته باشی.

📍2. اصل باز/بسته (OCP) یا Open-Close Principle
- مفهوم: موجودیت‌های نرم‌افزاری باید برای گسترش باز و برای تغییر بسته باشن.
- مثال: فرض کن یک فروشگاه آنلاین داری که روش‌های مختلف پرداخت رو پشتیبانی می‌کنه. به جای اینکه هر بار که یک روش پرداخت جدید اضافه می‌کنی، کد اصلی فروشگاه رو تغییر بدی، می‌تونی یک ساختار ماژولار طراحی کنی که هر روش پرداخت به صورت یک ماژول جداگانه باشه. اینجوری، وقتی می‌خوای یک روش پرداخت جدید مثل پرداخت با بیت‌کوین اضافه کنی، فقط کافیه یک ماژول جدید برای اون روش پرداخت بسازی و به سیستم اضافه کنی، بدون اینکه کد اصلی فروشگاه تغییر کنه.

📍3. اصل جایگزینی لیسکوف (LSP) یا Liskov Substitution Principle
جایگزینی لیسکوف یا اصل جایگزین‌پذیری Liskov مفهومی در برنامه‌نویسی شیءگرا است که تضمین می‌کند هر شیء یا نمونه‌ای از یک کلاس می‌تواند به جای هر نمونه دیگری از آن کلاس قرار گیرد بدون اینکه عملکرد برنامه‌ی کامل را تحت تاثیر قرار دهد. به این معنی که اگر یک کلاس زیرکلاس (subclass) باشد، باید بتواند به جای کلاس اصلی (superclass) قرار گیرد و همه‌ی عملکردها به درستی کار کنند.

فرض کنید که شما یک کلاس اتومبیل (Car) دارید که دارای عملکردهایی مانند شروع کردن (start)، توقف کردن (stop) و حرکت کردن (move) است. حالا شما یک زیرکلاس به نام اتومبیل الکتریکی (ElectricCar) ایجاد می‌کنید که همه‌ی این عملکردها را به ارث می‌برد.

بر اساس اصل جایگزین‌پذیری لیسکوف، اگر برنامه شما برای کلاس اتومبیل نوشته شده باشد، باید بتوانید به جای هر اتومبیل، یک اتومبیل الکتریکی قرار دهید و برنامه همچنان به درستی کار کند، به این معنی که توابع start، stop و move به درستی اجرا شوند بدون نیاز به تغییر در کد برنامه.

📍4. اصل جداسازی اینترفیس‌ها (ISP) Interface Segregation Principle
- مفهوم: هیچ مشتری نباید مجبور باشه به متدهایی که استفاده نمی‌کنه وابسته باشه.
- مثال: فکر کن یه ابزار چندکاره داری با قابلیت‌های جدا برای کارهای مختلف (پیچ‌گوشتی، چاقو، درب‌بازکن). هر ابزار وظیفه خاصی داره بدون اینکه مجبور باشی امکانات اضافی رو حمل و استفاده کنی.

📍5. اصل وارونگی وابستگی (DIP) یا Dependency Inversion
- مفهوم: ماژول‌های سطح بالا نباید به ماژول‌های سطح پایین وابسته باشن. هر دو باید به انتزاع وابسته باشن.

یک مثال ساده از اعمال اصل DIP می‌تواند در استفاده از وابستگی‌ها و تزریق وابستگی باشد. به عنوان مثال، فرض کنید شما یک برنامه‌ای دارید که برای ارسال ایمیل به کاربران خود نیاز به استفاده از یک سرویس ایمیل دارد. به جای اینکه مستقیماً به یک سرویس خاص مثل Gmail یا Outlook وابسته شوید، شما یک رابط یا اینترفیس برای سرویس ارسال ایمیل خود تعریف می‌کنید.

#برنامه_نویسی #دیزاین_پترن #کدنویسی

➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost

✍️ Massimo Dev

توی مهندسی نرم‌افزار، "طراحی مبتنی بر دامنه" (DDD) یه روش طراحی هست که توسط Eric Evans معرفی شده. هدف این روش اینه که یه درک مشترک از حوزه‌ی کاری بین برنامه‌نویسا و استراتژیست ها ایجاد بشه

مفاهیم کلیدی

دامنه (Domain): همون قسمتی که کاربر از برنامه استفاده می‌کنه. مثلاً اگه برنامه ما یه فروشگاه آنلاین کتابه، دامنه‌اش همینه.

مدل دامنه (Domain Model): یه مدل انتزاعی که مفاهیم، قوانین و منطق دامنه کاری رو نشون می‌ده. این مدل باید طوری باشه که هم کارشناسان فنی و هم استراتژیست ها بتونن بفهمنش.

زبان مشترک (Ubiquitous Language): یه زبان مشترک که تیم ازش استفاده می‌کنه تا همه حرف‌ها و مفاهیم توی پروژه رو با اون بیان کنن. این زبان شکاف بین اصطلاحات فنی و تخصصی رو پر می‌کنه.

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

موجودیت‌ها (Entities): Object هایی که هویت مشخص و ثابتی دارن و می‌تونن حالت‌های مختلفی داشته باشن.

اشیاء ارزشمند (Value Objects): آبجکت هایی که جنبه‌های خاصی از دامنه رو توصیف می‌کنن ولی هویت مشخصی ندارن.

مجموعه‌ها (Aggregates): یه کلاستر از آبجکت های دامنه هستن که می‌تونن به‌عنوان یه واحد در نظر گرفته بشن. نگران نباشید مثال میزنم بعدش که متوجه بشید.

مخازن (Repositories): مکانیزم‌هایی برای نگهداری، بازیابی و جستجوی اشیاء که شبیه یه کلکسیون از اشیاء عمل می‌کنن.

سرویس‌ها (Services): عملیات یا فرایندهایی که به Life Cycle یه Entity یا Value Object ربطی ندارن.

مثال عملی: فروشگاه آنلاین کتاب

بیاین این مفاهیم رو با یه مثال از یه فروشگاه آنلاین کتاب توضیح بدیم.

Domain:
دامنه همون "فروشگاه آنلاین کتاب" هست که روی منطق کسب‌وکار خرید، فروش و مدیریت کتاب تمرکز داره.

Domain Model:
مدل دامنه شامل موجودیت‌هایی مثل کتاب، مشتری، سفارش و مفاهیمی مثل مدیریت موجودی و پردازش پرداخت می‌شه.

Ubiquitous Language:
- کتاب: همون محصولیه که داریم می‌فروشیم.
- مشتری: کسی که کتاب می‌خره.
- سفارش: خرید مشتری که شامل یه یا چندتا کتابه.
- موجودی: تعداد کتاب‌های موجود.
- پرداخت: تراکنش برای یه سفارش.

Bounded Context:
1. کانتکست فروش: شامل موجودیت‌ها و گرفتن سفارش و پردازش پرداخت.
2. کانتکست موجودی: شامل موجودیت‌ها و مدیریت موجودی کتاب‌ها.
3. کانتکست مشتری: شامل موجودیت‌ها و اطلاعات و پروفایل مشتری‌ها.

Entities and Value Objects

- Entities:
- کتاب (ISBN، Title، Author، Price)
- مشتری (ID, Name، Email)
- سفارش (ID، Book Items، total amount، order date )

- Value Objects:
- آدرس (خیابان، شهر، استان، کدپستی)
- پول (مبلغ، ارز)

Aggregates

- مجموعه سفارش: موجودیت Order یک Aggregate root است. شامل لیست کتاب‌ها به‌عنوان Value object و مبلغ کل به‌عنوان یه value object.
- مجموعه مشتری: موجودیت Customer یک Aggregate root است. شامل آدرس به‌عنوان یه Value object.

Repositories
- مخزن کتاب: مدیریت موجودیت‌های کتاب، پیدا کردن، ذخیره و حذف کتاب‌ها.
- مخزن سفارش: مدیریت موجودیت‌های سفارش، ثبت، پیگیری و بازیابی سفارش‌ها.

Services
- سرویس سفارش: شامل منطق ثبت سفارش، از جمله چک کردن موجودی، پردازش پرداخت و تایید سفارش.
- سرویس موجودی: شامل منطق به‌روز‌رسانی سطح موجودی، چک کردن موجودی و تجدید موجودی کتاب‌ها

➖➖➖➖➖➖➖➖
👑 @gopher_academy | 💸 Donate | 💋 Boost