📚نام کتاب :
Microservices Design Patterns in .NET 2nd Edition: Making sense of microservices design and architecture using .NET 10 and C# 14
📌انتشارات:
Packt
🖋نویسنده:
Trevoir Williams
📆سال انتشار :
2025
🌐خرید اینترنتی :

https://mahdibookshop.com/product/1068/Microservices%20Design%20Patterns%20in%20.NET%202nd%20Edition:%20Making%20sense%20of%20microservices%20design%20and%20architecture%20using%20.NET%2010%20and%20C#%2014

👨🏻‍💻خرید از طریق پشتیبانی:
@MahdiBooksupp

➖➖➖➖➖➖➖➖
🆔@mahdibookshop
📞جهت مشاوره خرید :
02166487517
09122727954
یا خرید حضوری از کتابفروشی مهدی (عج)

#انتشارات_مهدی
#Mehdi_Publisher

این یکی از کتابهای خوبیه که مدتیه دارم در موردش تووی لینکدین پست میذارم

سال پیش وقتی رفتم مصاحبه شرکت داتین از من سوال پرسیدن که فرق بین dynamic vs object چیه؟
من نمیدونستم تا وقتی که رفتم برای اون کتاب Pro DLR in .NET 4 رو خوندم
دانشم رو دوست داشتم با شما به اشتراک بذارم
براش یه صفحه بلاگ توضیح دادم:
https://mhmdnzr.drl.ink/post/dynamic-vs-object-in-csharp

سرویس پرداخت Dr.Link رو ریفکتور کردم. تمرکزم فقط روی معماری بود — تمیز کردن ساختار، جداسازی لایه‌ها. نه latency, نه reliability.
بعداً فهمیدم اشتباه بوده. تو یه سرویس پرداخت با لود بالا، معماری تمیز به‌تنهایی هیچ تضمینی نمی‌ده. باید از همون اول بدونی سیستم زیر فشار چطور رفتار می‌کنه و اگه چیزی خراب شد، چی می‌شه.
الان دارم کتاب Latency از Pekka Enberg رو می‌خونم تا این خلأ رو جبران کنم — درباره‌ی consistency models (strong, eventual, causal, session) و trade-offهاشون.
#SoftwareEngineering #DistributedSystems #Payments #DrLink
پست جدیدم رو اینجا می‌تونید بخونید 👇
توضیح consistency models در سیستم‌های توزیع‌شده · وبلاگ دارک‌پرو

من یه مقاله به تازگی نوشتم در خصوص چرایی وجود یک سری primitives keyword ها در سی شارپ و چجوری اینا میتونن به توسعه و کاهش latency سیستم به ما کمک کنند با مثال واقعی:
https://mhmdnzr.drl.ink/post/concurrent-file-uploader

پارسال رفته بودم مصاحبه Asan Pardakht برای نیروی دات نت
یک سوالی اونجا ازم کرد که خیلی برام جالب بود، پرسید فرق بین for vs foreach تووی سی شارپ چیه؟
خب این یه سوال به ظاهر خیلی سادست اما وقتی ترکیب میشه با دیتابیس و فچ دیتا میبینی انگار چوب جادوی هری پاترو انگار پیدا کردی
تووی این بلاگ سعی کردم در مورد این موضوع بییشتر صحبت کنم که چیشد اینجوری شد!
پ.ن: البته اینم بگم که من قبول نشدم تووی مصاحبه اما هربار که من fail میشم خلاهای بیشتری رو در خودم کشف میکنم و به ظرف دانش یک قسمت دیگه اضافه میکنم تا بهتر از دیروز بشم
#csharp #dotnet #software #architecture #pattern #learning

https://mhmdnzr.drl.ink/post/for-vs-foreach

دارم روی یه سری پست کار می‌کنم که موضوعش دور و بر همون چیزیه که این روزها خیلی درگیرشم: latency، consistency، و اون لحظه‌هایی که سیستم یه چیزی رو "فکر می‌کنه" داره درست انجام می‌ده ولی در واقع نداره. این پست از دل یه بحث واقعی دراومد — یه سناریوی ساده که همه‌مون یه جایی باهاش برخورد کردیم ولی خیلی‌ها (منم قبلاً) دقیق بهش فکر نکردیم که چرا واقعاً خطرناکه.

بذارید مستقیم بریم سراغ صحنه‌ی جرم.
https://mhmdnzr.drl.ink/post/distributed-lock

فراتر از Npgsql: راهنمای کامل PgBouncer، Pgpool-II، Odyssey و پروکسی‌های ابری Postgres برای اپلیکیشن‌های C#
https://mhmdnzr.drl.ink/post/npgsql-pgbouncer-pgpool-ii-odyssey-postgres-c

یه جایی توی پروژه‌مون به خودمون گفتیم:

«بابا Notification که دیگه این همه داستان نداره! یه API می‌زنیم، پیامو می‌فرستیم، تموم.»

و واقعاً هم همین کارو می‌شه کرد.

ساده‌ست، سریع پیاده می‌شه، Infrastructure خاصی نمی‌خواد و تا وقتی همه‌چی خوب پیش میره، خیلی هم قشنگه :)

ولی مشکل از جایی شروع می‌شه که همه‌چی خوب پیش نمی‌ره!

مثلاً:

پیام توی DB ذخیره شده، ولی سرویس قبل از Publish کردن به RabbitMQ می‌میره.

تبریک می‌گم!

پیام داری ولی Event نداری :)

یا OTP و Campaign رو ریختی توی یه Queue و یهو چند هزار تا پیام Campaign اومده.

حالا کاربر منتظر OTPـه و Queue داره با خودش حال می‌کنه!

اینجاست که داستان کم‌کم تبدیل می‌شه به یه فاجعه کوچیکِ قابل مدیریت و باید بری سراغ چیزهایی مثل:

Outbox

Retry

Idempotency

Queue Isolation

Hangfire

Critical Workers

و کلی چیز دیگه.

البته اینجا هم فکر نکنی همه‌چی حل شد!

هر راه‌حل جدید خودش یه عالمه پیچیدگی، Monitoring، Failure Mode و در نهایت یه مقدار بگ....یی!! جدید با خودش میاره :))

توی NotificationHub دقیقاً سعی کردم همین مسیر رو بررسی کنم:

هر تصمیم معماری چه مشکلی رو حل می‌کنه؟

چه مزیتی داره؟

چه هزینه‌ای ایجاد می‌کنه؟

و مهم‌تر از همه، کِی اصلاً نباید ازش استفاده کنیم؟

اگه با Backend و Distributed Systems سروکله می‌زنی، احتمالاً این داستان برات آشناست.

اینجا فقط یه بخش کوچیکشو گفتم.

اگه کنجکاو شدی ببینی آخرش این فاجعه رو چطوری جمع کردیم، بنظرم ارزش وقت گذاشتن و خوندن رو داره:

🔗 https://mhmdnzr.drl.ink/post/5086561b

#SoftwareArchitecture #Backend #DotNet #DistributedSystems #SystemDesign

این جمله درسته که همیشه دیتای حجیم باعث مرگ سیستم میشه؟ یا یک hot path در لایه infra SQL باعث میشه به ددلاک بخوریم؟
چجوری میشه حلش کرد؟ صرفا چندتا راه همیشگی AsNoTracking, AsSplitQuery, projection, N+1 problem و... یا استفاده از compiled query مارو از این منجلاب بیرون میکشه؟
یا شاید در زبان سی شارپ و ویژگی هاش باید دیپ تر بشیم؟
خب بنظرم گزاره دوم درسته، ما فهم ناقصی از سیستم کارکرد سی شارپ داشتیم
تووی این مقاله سعی کردم راه حلمو با for vs foreach ترکیب کنم و بهتون ارائه بدم.
میتونین از طریق لینک زیر مطالعه کنید:

https://mhmdnzr.drl.ink/post/d0040081

ما اکثرا از FirstOrDefault استفاده کردیم تا بخوایم بر اساس کلید یا یک ستون بریم داخل دیتا بیس پیدا کنیم، اما بقیش چی؟ کلا پنج تابع اصلی داریم برای پیدا کردن. اونا چیکار میکنن؟ تبدیل به چه کوئری میشه در نهایت؟
همه و همه در این مقاله جا شدن:
تفاوت در پیدا کردن است!

https://mhmdnzr.drl.ink/post/4ff4fb50

چرا وقتی میخوایم بدونیم یه آیتم توی دیتابیس یا یک persistent store هست یا نه، باید از Any استفاده کنیم نه Count() > 0؟

این سؤال رو توی مصاحبه‌ها زیاد میپرسن، چون جوابش فقط سر syntax نیست، سر چیزیه که پشت صحنه اجرا میشه.

روی یک IQueryable (مثلاً EF Core):

users.Any(u => u.Id == id)
users.Count(u => u.Id == id) > 0

اولی به EXISTS یا SELECT TOP(1) ترجمه میشه؛ دیتابیس همین که یه ردیف مچ پیدا کنه متوقف میشه.
دومی به COUNT(*) ترجمه میشه؛ دیتابیس مجبوره (بسته به index) همهٔ ردیف‌های مچ رو بشمره، حتی اگه فقط بخوای بدونی حداقل یکی هست.

روی دیتاست بزرگ این فرق فقط تئوری نیست؛ رو query plan، I/O، و latency واقعاً اثر میذاره.

توی حافظهٔ خود برنامه (نه دیتابیس) هم یه داستان مشابه با جزئیات متفاوت هست: enumerator، closure allocation، و اینکه چرا struct بودن Enumerator باعث میشه فرق اصلی سر heap نباشه، سر تعداد iteration باشه.

کل تحلیلش رو با کد، جدول پیچیدگی زمانی، و رسم Stack/Heap توی این پست نوشتم:
[لینک مقاله]

فایل README این پروژه خودش گویای همه‌چیز است. با الهام از الگوریتم topological sort و ساختار DAG که در جلد اول کتاب The Art of Computer Programming (فصل ۲، بخش 2.2.3، Linked Allocation) مطالعه کردم، این router را توسعه دادم. کاربردهای آن می‌تواند بسیار متنوع باشد. توجه شما را به بخش benchmark آن جلب می‌کنم.
https://github.com/0x-mhmdnzri/TheRouter