🔭 تاریخچه و زمینه پیدایش Domain-Driven Design

اوایل دههٔ ۲۰۰۰ شرکت‌های خیلی بزرگ (بانک‌ها، بیمه، و …) با سیستم‌های نرم‌افزاری‌ای روبه‌رو بودند که:

- دامین‌های با پیچیدگی خیلی بالا داشتند (مثل قوانین کسب‌وکار پرشمار و در حال تغییر).

- گپ ارتباطی وحشتناکی بین تحلیلگرها و برنامه‌نویس‌ها وجود داشت؛ اصطلاحات یکی برای دیگری نامفهوم بود.

- هر تغییر کوچک به موجی از regression bugها و استرس انتشار تبدیل می‌شد.

توی چنین شرایطی، Eric Evans می‌گه: «بیایید به جای تمرکز صِرفن روی لایه‌های فنی، قلب مسأله—یعنی دامنه—رو محور کار بگذاریم.» نتیجه شد متدولوژی Domain-Driven Design که توی کتاب معروف «آبی» در سال ۲۰۰۳ متولد شد و ‌بعدتر با کارهای Vaughn Vernon، Jimmy Nilsson و بقیه گسترش پیدا کرد.

برخی مفاهیم پایه در DDD:

- مفهوم Ubiquitous Language
زبان مشترک بین همهٔ ذی‌نفعان. کلاس، جدول DB و اسلاید ارائه باید از یک واژه برای یک مفهوم استفاده کنند، و یک واژه باید همه جا معنی یکسان داشته باشه.

- مفهوم Bounded Context
مرزهایی شفاف برای معنی واژه‌ها. «سفارش» در حسابداری ≠ «سفارش» در انبار.

- مفهوم Aggregate
یک خوشه (گروه) از آبجکت‌ها، با یک ریشهٔ واحد که می‌شه به‌صورت واحد تلقی کردشون.

- مفهوم Context Map
نقشهٔ روابط بین Bounded Contextها؛ شامل پیوندهای همکار، مشتری–تأمین‌کننده و…

- مفهوم Strategic Design
هنر تشخیص اینکه کِی باید دامنه رو بشکنیم و تیم رو حولش سازمان‌دهی کنیم.

آیا DDD برای همه است؟ نه دقیقاً!
توی «مطلب قبل» دربارهٔ وسوسهٔ ترندها گفتم، DDD هم قربانی حباب‌ها شده. نشونه‌های انتخاب اشتباه:

- دامنه ساده است (CRUD سرراست، منطق پیچیده‌ای هم نداره) ولی تیم حتماً می‌خواد Bounded Context تعریف کنه و Event Storming برگزار کنه!

- ابزارهای تحلیلی، تست، مستندسازی و DevOps هنوز بالغ نیستند اما «می‌خواهیم معماری تمیز + DDD + مایکروسرویس» رو با هم پیاده کنیم.

- تیم کوچک است ولی هر کانتکست رو توی یک ریپو جداگانه Deploy می‌کنه و نصف زمانش صرف هماهنگی بین ریپوها می‌شه.

یادمون نره: DDD هزینه داره—هم آموزشی، هم طراحی، هم نگهداری.
اگر درد پیچیدگی دامنه رو حس نمی‌کنیم، این دارو تلخ و بی‌فایده است!!

چرا لزوماً هر معماری دامین-سنتریک، DDD نیست؟!
— بعدتر دراین‌باره خواهم نوشت که هر گردی گردو نیست!! پیاده‌سازی Clean / Hexagonal / Onion به معنی DDD نیست!

«توی DDD، معماری کد فقط یک لایه از ماجراست؛ موفقیت زمانی رقم می‌خوره که ساختار سازمانی و فرایندهای تیم هم با مرزهای دامنه منطبق شن. اگر تیم کوچکه و دامنه پیچیدگی بالایی نداره، صرف داشتن لایهٔ Domain یا استفاده از معماری Clean، شما صاحب DDD نمی‌شید.»

🔔 اگر علاقه‌مند بودید، روز ۴ خرداد (۲۵ می) ساعت ۱۹:۳۰ به وقت تهران جلسه‌ای به همت انجمن DDD ایران برگزار می‌شه که اگر عمر و فرصتی بود، در این مورد به تفصیل صحبت خواهم کرد. اطلاعات ایونت رو توی کامنت قرار خواهم داد.

💬 نظر؟ تجربه؟

🧠 سرنوشت یکی از اولین قربانی‌های هوش‌مصنوعی،
استک‌اورفلو

استک‌اورفلو به خاطر رشد استفاده از LLMها که یکی از منابع یادگیری‌شون خود استک‌اورفلو بوده، حالا حسابی تو دردسر افتاده. آمار جدید نشون می‌ده تعداد سؤال و جواب‌های اپریل ۲۰۲۵ نسبت به دوره مشابه پارسال ۶۴٪ کم شده و اگر با اوج ترافیکش در ۲۰۲۰ مقایسه کنیم، سقوط بالای ۹۰٪ داشته!

اوضاع جوری شده که مدیرهای استک اکسچنج (شرکت مادر استک اورفلو) اعلام کردن برای بهبود یا نجاتش می‌خوان یه "بازسازی برند" انجام بدن. میگن "هویت برند" فعلی باعث "سردرگمی، ناهماهنگی و ناکارآمدی روزانه، هم داخل و هم خارج از کسب‌وکار" شده.
یکی از مشکلاتی که اشاره کردن اینه که استک اورفلو خیلی برجسته‌تر از بقیه سایت‌های شبکه استک اکسچنج شده و "بیشتر تصمیمات با تمرکز روی توسعه‌دهندگان گرفته میشه که باعث میشه بقیه شبکه احساس غریبی کنن".

🧐 کاربرها چی میگن؟
خیلی از کاربرها اصلاً با این تغییر برند موافق نیستن. بعضی کاربرها فکر می‌کنن تغییر اسم و برند راه حل مشکل نیست...

برنامه جدید چیه؟
مدیرعامل شرکت، گفته می‌خوان از تمرکز روی یک حوزه اصلی (سوال و جواب) به سمت سه حوزه حرکت کنن و "ستون‌های جامعه و مشاغل" رو هم اضافه کنن.
البته قبلا هم چند تلاش تقریبا ناموفق برای اضافه کردن ورتیکال‌های درآمدی داشتن که خیلی موفق نبود.

جالبه که با وجود کاهش ترافیک، درآمد شرکت هنوز آسیب جدی ندیده. طبق نتایج مالی Prosus (شرکت سرمایه‌گذاری که مالک استک اکسچنج هست)، توی شش ماه منتهی به سپتامبر ۲۰۲۴، استک اورفلو درآمدش رو افزایش داده و ضررش رو هم کمتر کرده.

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

💬 نظر شما چیه؟ قربانی بعدی کیه؟ از این به بعد هوش مصنوعی از کجا تغذیه بشه؟؟

🎮 تاریخچه زمینه پیدایش Clean / Hexagonal / Onion

در یک نگاه، سه الگوی «clean»، «hexagonal» و «onion» همه با یک هدف مشترک متولد شده‌اند: جدا کردن «منطق دامنه» از جزئیات متغیّر فناوری (UI، دیتابیس، فریم‌ورک‌ها) و معکوس کردن جهت وابستگی‌ها. تفاوت‌شون در زاویه دید و لایه‌بندی است؛ hexagonal روی ports و adapters (درگاه‌ها و آداپترها) تأکید می‌کنه، و onion روی «وابستگیِ رو به هسته» و clean یک معماری‌ ترکیبیه که ایده‌های هر دو رو با تمرکز روی use-case گسترش می‌ده.

اما درست مثل مایکروسرویس و DDD، پیاده‌سازی زودهنگام یا بدون مسئله واقعی، می‌تونه هزینه و پیچیدگی بی‌فایده تحمیل کنه.

📇 ریشه و سیر تکامل

- هگزاگونال (Ports & Adapters)
سال ۲۰۰۵ توسط Alistair Cockburn مطرح شد؛ هدف: «قابلیت تست مستقل از UI و پایگاه داده و جلوگیری از بلاک شدن توسط فناوری»

عملا core system از طریق «پورت»‌ها با جهان بیرونی‌اش صحبت می‌کنه؛ هر پورت می‌تونه آداپترهای مختلف مثل REST، CLI، تست و... داشته باشه.

🧅 معماری onion
توسط Jeffrey Palermo در سال ۲۰۰۸ معرفی شد؛ قانون طلایی: «تمام وابستگی‌ها باید به سمت مرکز (دامین مدل) باشن»

چهار رکن اصلی به گفتهٔ خودش:
۱: سیستم باید حول یک object model مستقل شکل بگیره
۲: لایه‌های داخلی interfaceها رو تعریف می‌کنن و لایه‌های بیرونی interfaceها رو پیاده‌سازی.
۳: جهت اتصال به سمت مرکزه.
۴: امکان کامپایلِ Core بدون زیرساخت باید محقق بشه.

معماری clean
توسط پیرمرد پرحاشیه‌ی این روزها 😅 رابرت سی. مارتین (uncle bob) مفهوم «Clean Architecture» سال ۲۰۰۸ توی وبلاگش شرح داد؛ معماری‌ای لایه‌ای با entityها، use caseها و interface adapter که «مستقل از فریم‌ورک و قابل تست» باقی بمونن.

معماری clean رو می‌شه ترکیبی تکامل‌یافته از hexagonal و onion دونست که حلقه‌های بیشتری (Entities, Use-Cases, Interface Adapters…) تعریف می‌کنه.

⚖️ چه‌وقت‌ مناسبند؟
- وقتی پیچیدگی دامنه واقعاً بالاست؛ قوانین در حال تغییر و تعاملات متعدد دارید.
- طول عمر سیستم طولانیه و انتظار تغییر فناوری‌های UI یا دیتابیس یا کلن لایه‌های فنی را داریم.
- نیاز به یونیت‌تست قبل از آماده بودن زیرساخت احساس می‌شه.

🧩 نسبتشون با DDD و مایکروسرویس
این الگوها «دامین‌سنتر» هستند، اما استفاده ازشون الزاماً به معنی DDD نیست؛ همون‌طور که DDD بدون این معماری‌ها هم ممکنه.

در معماری مایکروسرویس، به‌کارگیری یکی از این الگوها برای هر سرویس به استقلال توسعه/دیپلوی کمک می‌کنه، ولی اگر مقیاس تیم یا ماژول کوچک باشه، شاید حتی الگوی ساده لایه‌ای کفایت کنه! — مثل همون اشتباه «پیاده‌سازی زودهنگام مایکروسرویس».

💬 تجربه شما؟

💡آیا ویندوز NT واقعا سیستم‌عامل پیشرفته‌ای بود؟ نمونه مقایسه مهندسی، به جای هیجانات شخصی...

امروز داشتم بوکمارک‌‌تکونی می‌کردم، یهو پست وبلاگ Julio Merino که ماه‌ها پیش ذخیره کرده بودم تا در موردش بنویسم و فراموش کرده بودم رو دیدم.

آقای Julio Merino پیشتر در گوگل و مایکروسافت و الان هم در snowflake مشغول به کاره و روی سیستم‌های یونیکس‌بیس خیلی مسلطه (معماری و لایه‌های پایین‌تر سیستم عامل) و جز دولوپرهای FreeBSD و NetBSD بوده. توی این پست توضیح می‌ده که آیا تعریف و تمجیدهایی که از پیشرفته بودن سیستم‌عامل Windows NT در سال ۱۹۹۳ می‌شده در مقابل یونیکس‌سانان مثل BSD درست بوده یا نه؟!

شاید ما هرگز سیستم عامل توسعه ندیم یا تا لایه‌های خیلی پایین کرنل عمیق نشیم؛ ولی خوبه بدونیم مقایسه صحیح دو تا سیستم ولو اینکه به ۳۰ سال پیش برگردن، آداب و روشی داره که توی این مقاله به خوبی یاد می‌ده...

مقاله مفصلیه، و از حوصله پست تلگرامی خارج. ولی مثلا از hybrid microkernel یا Async I/O میگه که NT جلوتر از زمان خودش و پیشرفته از Unix بوده و بعد نظرش رو توضیح می‌ده که چطور linux و یونیکس‌سانان این سال‌ها گپ‌ها رو پر کردن و چالش‌های اصلی توسعه ویندوز چیاست از نظرش.

هدفم از اشتراک این مطلب اینه چقدر در بین مقایسه‌هایی که در مورد زبان‌ها، تکنولوژی‌ها، معماری‌ها و... می‌بینیم، روش و معیارهای فنی می‌بینیم، و چقدر بر اساس رسانه و هیجان و تصورات ذهنی‌مون قضاوت می‌کنیم...

🎙 وبینار فراتر از کُد: درباره تناسب و سازگاری معماری سیستم‌ها با ساختار سازمانی

🗓 روز یکشنبه ۴ خرداد (۲۵ می) ساعت ۱۹:۳۰ به وقت تهران؛ به دعوت انجمن DDD ایران، یه صحبت یک‌ساعته و بعدش هم گپ‌وگفت نیم‌ساعته خواهیم داشت...

اگر رئوس مطالب براتون جالب بود، حضورتون باعث خوشحالیه 😊🌱

- ریشه‌ها و نیروهای محرک معماری‌های مدرن
- شناسایی مسئله، پیش از انتخاب راه‌ حل
- همگرایی بستر فنی و ساختار سازمانی
- الگوهای تطبیق معماری و سازمان
- تجربه‌های میدانی
- توصیه‌های عملی برای فردا صبح

لینک گوگل فرم برای اعلام حضور
لینک افزودن به تقویم گوگل
لینک پیوستن در گوگل‌میت

کانال تلگرامی انجمن DDD ایران
@DDD_IRAN

🤓 مقدمه‌‌ای بر تازه‌های «هر چیزی»...
نظرسنجی اخیر کانال شامل ۵ گزینه اصلی بود که هر کدوم حول یک تکنولوژی، ابزار، یا روش جدید بود. فارغ از اینکه برآیند تمایل جمع، به سمت کدوم گزینه بوده؛ خوبه تا یه مرور کنیم ببینیم «چیز جدید» چیه؟ و از چه زوایایی می‌شه بهش نگاه کرد!

۱: نگاه فردی: مسئله یا کنجکاوی ما چیه؟
نسخه جدید فلان زبون، فریم‌ورک یا دیتابیس یا ... از راه رسید. خب که چی؟ چه دردی از من قراره دوا کنه؟ قراره این نسخه جدید مسئله‌ای ازم حل کنه؟ قراره فردا توی زمان استراحت باهاش پُز به‌روز بودن به همکارهام بدم؟ قراره باهاش ویدیو/اینفوگرافی یا پُست تلگرامی یا توییتری بگذاریم و خودم رو در لبه‌ی تکنولوژی‌های نو نشون بدم؟ قراره با به خاطر سپردن چند کلمه، عنوان، یا حتی چند خط کد، حس عذاب وجدان کم‌دانشی و کم‌تلاشی‌ام رو تسکین بدم؟ قراره یه جوری توی فضای مجازی یا بین دوستان صحبت کنم که خشم و حس ناکافی بودنی که از شرکت و محصولی که روش کار می‌کنم و با ابزارهای قدیمی و کیفیت پایین عرضه می‌شن رو پنهان کنم یا جلو بقیه کم نیارم؟؟

ده‌ها دست از این سوالات وجود داره که هر کدومشون طیفی از ما رو پوشش می‌ده. اتفاقا شاید در نگاه اول از قرارگیری ذیل خیلی از این سوالات ناخشنود بشیم یا از پذیرشش فراری باشیم، ولی فارغ از احساس بیرونی، برخی با خیلی از این موارد خوشحالن! اتفاقا از اینکه توی لینکدین یا توییتر یه جوری بنویسن که مخاطب فکر کنه این بابا تمام عمرش منتظر اومدن فلان قابلیت جدید در فلان زبون یا بهمان دیتابیس بوده!! و از لایک‌ها و کامنت‌ها حس رضایت فردی می‌گیره، دوپامین دریافت می‌کنه... و البته امان از روزی که یه سوتی کوچیک باعث قطع جریان این دوپامین بشه، سوال و لایک و بازنشرها کم بشن و معضلات بعدی...

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

۲: اگر مسئله‌ای باید حل شه، آیا پاسخش اینه؟
نسخه جدید فلان دیتابیس، بهمان درصد سریع‌تره، ولی آیا کندی‌ای که ما باهاش درگیریم، دلیلش نداشتن این نسخه جدید و راه‌حلش استفاده از این نسخه جدیده؟ یا جایی توی طراحی و توسعه و زیرساختمون مشکل داریم؟ هیجان چیزهای جدید زیاده! سر و صداش هم زیاده! ولی عمرش کوتاه! «زمان حل مسئله» رو صرف پرداختن به هیجانات نکنیم...
فلان نسخه از دیتابیس بهمان، AI رو به نیکویی! پیاده کرده، ولی آیا محصول ما در کوتاه یا میان‌مدت ازش استفاده می‌کنه؟ همون‌طور که میز و اتاق کار شلوغ باعث عدم تمرکز و حواس‌پرتی می‌شه، پرداختن به چیزهایی که نیازمون نیست، مثل قراردادن وسایل بی‌ربط روی میز و دور و برمونه...

۳: عمق واقعی!
بعضی از ما با یه خط‌کش ۱۰ سانتیمتری می‌ریم وسط اقیانوس، خط‌کش رو تا ته می‌کنیم توی آب، و به هیجان فریاد می‌زنیم: «حاجی عجب عمقی داره، کل خط‌کشم رو گرفت...»
این مثال خیلی بی‌ربط به عمق یادگیری خیلی از ما از یه نسخه جدید نیست. خیلی از ما فقط نسخه جدید رو نصب می‌کنیم و به سبک ۱۰ نسخه قبل ازش استفاده می‌کنیم و از عدد ورژنش کیف می‌کنیم. یا ته تهش یه شیوه جدید نوشتن متد رو استفاده می‌کنیم. مثلا چراییِ استفاده از فروشنده دوره‌گرد به طور asymmetric در JIT دات‌نت ۱۰ برامون جذابه؟ کمک می‌کنه درک بهتری از فرایند کامپایل کدمون داشته باشیم؟ در خدمت رشد فردی‌ یا محصولی یا تیمی‌مون هست؟ یا فقط دلمون خوش خواهد بود که توی سی‌شارپ ۱۴ می‌شه ?. نوشت؟ نمی‌گم بریم ۴۰۰ صفحه مستندات AVX10.2 رو بخونیم، ولی حداقل در حد ۲ پاراگراف بدونیم که چیه و کجا کاربرد داره...

🌱 این پست مفصله، اگر دوست داشتید تا بیشتر با هم بلند بلند فکر کنیم که اطلاع از چیز جدید، چه فرصت‌ها و چه تله‌هایی داره، چه خطاهای ادراکی می‌تونه داشته باشه: ⚙️

بخش‌های بعدی (در صورت تمایل جمع)
۴: تمرین تداوم
۵: آثار مثبت و منفی تیمی/سازمانی
۶: توازن بین پیشرفت ساختار و ابزار
۷: استراتژی پیشنهادی برای مهاجرت/استخدام ابزار جدید در محصول
۸: وزن‌دهی بین توسعه، بهبود، ارتقاء
۹: ارتقاء محصول یا تغییر گزینه‌ها؟
۱۰: روش‌های مدل‌سازی و تصمیم برای تغییر/ارتقاء محصول
۱۱: انترپرایز (technology radar, green book, و...)

💬 نظر؟ تجربه؟ اگر این بحث حدنصاب ادامه رو نیاره، علی‌الحساب با احترام به آراء دات‌نت ۱۰ در اولویت مطالب بعدیه 😊

🔔۳۰ دقیق دیگه...
https://meet.google.com/gyr-xpmr-abk

📔 دات‌نت ۱۰ (C# 14): Extension members

یکی از بهبودهای دات‌نت C# 14، رو می‌شه Extension membersr دونست که فقط محدود به متد نیستند؛ حالا می‌شه پراپرتی، ایندکسر، و حتی event رو هم به‌صورت اکستنشن برای یک کلاس یا اینترفیس اضافه کرد. این قابلیت‌ها یک جهش بزرگ برای توسعه‌پذیری و Clean Code در نرم‌افزارهای بزرگ به حساب میاد.

فرض کنین چند تا تیم روی قابلیت‌های مختلف پلتفرم کار می‌کنن. حالا به راحتی می‌شه Map کردن آبجکت به DTO و اعتبارسنجی و... با کدهای تمیزتر و بهتری پیاده‌کرد

 csharp
public class Order
{
    public int Id { get; set; }
    public decimal Amount { get; set; }
    public string Status { get; set; } = "pending";
    public string? Customer { get; set; }
}

public class OrderDto
{
    public int Id { get; set; }
    public decimal Amount { get; set; }
    public string Status { get; set; }
    public bool IsPaid { get; set; }
}

و حالا اینجوری با بلاک اکستنشن:

public static class OrderApiExtensions
{
    extension(Order order)
    {
        // متد اکستنشن: تبدیل Domain Model به DTO
        public OrderDto ToDto()
            => new OrderDto
            {
                Id = order.Id,
                Amount = order.Amount,
                Status = order.Status,
                IsPaid = order.IsPaid() //  اکستنشن متد دیگه
            };

        // متد اکستنشن: بررسی پرداخت‌شده بودن سفارش
        public bool IsPaid() => order.Status == "paid";

        // پراپرتی اکستنشن: نمایش عنوان مشتری
        public string? CustomerDisplay => 
            string.IsNullOrWhiteSpace(order.Customer) ? "(نامشخص)" : order.Customer;
    }
}

و همین تمیزسازی پیاده‌سازی‌های قبلی رو با قابلیت جدید دیگه‌ای که اجازه می‌ده تا instance constructors و events رو هم به صورت partial members تعریف کرد...

📔 ساده‌تر شدن اجرای نرم‌افزارهای کوچیک در دات‌نت ۱۰

نسخه پیش‌نمایش ۴ دات‌نت ۱۰ امکانی رو فراهم کرده تا بودن فایل پراجکت و سولوشن هم به راحتی بشه کد سی‌شارپ نوشت. قبلا با استفاده از فایل‌های اسکریپت csx. هم می‌شد این کار رو کرد، ولی امکان جدید، جامع‌تر و ساده‌تره.
کابردش: آموزش، اسکریپت‌های مورد استفاده برای DevOps و...
ابتدای فایل به ذکر :# و بعدش skd یا package چیزهایی رو که قبلا توی فایل csproj مشخص می‌کردیم، اینجا می‌تونیم توی یک فایل قرار بدیم.

مثلا: کد زیر فقط با یه فایل cs کار می‌کنه و چک می‌کنه اگر rabbitmq و postgresql اوکی بودن، ورژن نرم‌افزار رو توی دیتابیس به‌روز می‌کنه و یه وب‌پیچ هم محیا می‌کنه برای مشاهده وضعیت.

#! /usr/bin/dotnet run

#:sdk Microsoft.NET.Sdk.Web
#:package markdig@0.41.*
#:package Npgsql@9.0.*
#:package RabbitMQ.Client@7.1.*


using Markdig;
using Npgsql;
using RabbitMQ.Client;
using System.Reflection;

var rabbitMqHost = Environment.GetEnvironmentVariable("RABBITMQ_CONNECTION_STRING") 
    ?? "amqp://guest:guest@localhost:5672/";
var pgConnStr = Environment.GetEnvironmentVariable("POSTGRES_CONNECTION_STRING") 
    ?? "Host=localhost;Username=postgres;Password=yourpassword;Database=yourdb";

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", async () =>
{
    bool rabbitOk = false;
    try
    {
        var factory = new ConnectionFactory() { Uri = new Uri(rabbitMqHost) };
        using var connection = factory.CreateConnection();
        using var channel = connection.CreateModel();
        rabbitOk = connection.IsOpen && channel.IsOpen;
    }
    catch { rabbitOk = false; }

    bool pgOk = false;
    string errorMsg = "";
    try
    {
        using var conn = new NpgsqlConnection(pgConnStr);
        await conn.OpenAsync();
        pgOk = conn.State == System.Data.ConnectionState.Open;

        var version = Assembly.GetEntryAssembly()?.GetName().Version?.ToString() ?? "unknown";
        var now = DateTime.Now;

        using var cmd = new NpgsqlCommand(
            "INSERT INTO application (checked_at, version, rabbitmq_ok, postgres_ok) VALUES (@date, @ver, @rmq, @pg)", conn);
        cmd.Parameters.AddWithValue("date", now);
        cmd.Parameters.AddWithValue("ver", version);
        cmd.Parameters.AddWithValue("rmq", rabbitOk);
        cmd.Parameters.AddWithValue("pg", pgOk);
        await cmd.ExecuteNonQueryAsync();
    }
    catch (Exception ex)
    {
        errorMsg = ex.Message;
    }


    var content = $"""
    # System Health Check

    - **RabbitMQ:** {(rabbitOk ? "OK" : "FAILED")}
    - **PostgreSQL:** {(pgOk ? "OK" : "FAILED")}
    {(string.IsNullOrWhiteSpace(errorMsg) ? "" : $"\n- **Error:** {errorMsg}")}
    """;

    return Results.Content($"""
        <html>
            <body style="font-family: sans-serif;">
                {Markdown.ToHtml(content)}
            </body>
        </html>
        """, "text/html");
});

app.Run();

🎮💡 مقایسه مفهوم ACID و BASE

مقدمه: دو مدل اصلی برای مدیریت تراکنش‌ها وجود داره: ACID و BASE. هر کدوم از این مدل‌ها رویکرد متفاوتی نسبت به «تضمین صحت» و «در دسترس‌پذیری» داده‌ها دارن و انتخاب مناسب بستگی به نیازهای خاص سیستم داره.

💎 مدل ACID: تضمین صحت و یکپارچگی داده‌ها
مدل ACID که مخفف چهار ویژگی Atomicity (اتمی بودن)، Consistency (سازگاری)، Isolation (انزوا) و Durability (دوام) است، از بدیهی‌ترین و ابتدایی‌ترین مفاهیم RDBMSهاست و توی تقریبا همه‌شون دیده می‌شه.

*️⃣مفهوم Atomicity (اتمیک بودن): تراکنش‌ها به صورت یک واحد کامل اجرا می‌شن؛ یا کل عملیات موفق میشه یا هیچ‌کدمم اعمال نمی‌شه. چرا می‌گیم اتمیک؟ چون به زبون عامیانه و ساده، اگر اتم آهن رو فرض کنیم، هر جزء کوچک‌تر از اتم آهن، دیگه آهن نیست! یه چیز دیگه است. وقتی میگیم این ۱۰ عمل باهم میشه تراکنش خرید، حتی ۹ تاش رو هم داشته باشیم، «خرید» نداریم!

*️⃣مفهوم Consistency (سازگاری): تراکنش‌ها داده‌ها رو از یک وضعیت معتبر به وضعیت معتبر دیگه منتقل می‌کنن، بدون نقض قوانین تعریف‌شده.

*️⃣مفهوم Isolation (انزوا): اجرای همزمان تراکنش‌ها به گونه‌ای است که انگار هر کدوم به تنهایی اجرا شده‌ باشن، بدون تأثیر بر همدیگه (البته بستگی به سطح ایزوله کردن داره که مفاهیمی مثل unrepeatable read و phantom read پیش میاد.

*️⃣مفهوم Durability (دوام): پس از تأیید تراکنش، تغییرات به طور دائمی در پایگاه داده ذخیره می‌شون (تضمین می‌شه)، حتی در صورت بروز خطا یا قطع برق.

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

⚡️ مدل BASE: تمرکزش روی دسترس‌پذیری و مقیاس‌پذیریه.
مدل BASE که مخفف Basically Available، Soft state و Eventually consistent است، توی پایگاه‌های داده NoSQL مثل Cassandra و DynamoDB استفاده می‌شه.

*️⃣مفهوم Basically Available (اساساً در دسترس): سیستم همیشه در دسترسه، حتی در صورت بروز خطا یا قطعی شبکه.

*️⃣مفهوم Soft state (وضعیت نرم): وضعیت سیستم ممکنه در طول زمان بدون ورودی‌های جدید تغییر کنه.

*️⃣مفهوم Eventually consistent (در نهایت سازگار): در نهایت، تمام nodeهای سیستم به یک وضعیت سازگار می‌رسن، حتی اگر در کوتاه‌مدت ناسازگاری‌هایی وجود داشته باشه.

این مدل برای سیستم‌هایی که به دسترس‌پذیری بالا و مقیاس‌پذیری نیاز دارن، مثل شبکه‌های اجتماعی مناسبه.

🧠 نتیجه‌گیری

انتخاب بین ACID و BASE به نیازهای خاص هر سیستم بستگی داره؛ در برخی شرایط، ترکیبی از این دو مدل گزینه مطلوب رو شکل می‌ده، به ویژه توی معماری‌های میکروسرویس که نیاز به انعطاف‌پذیری بیشتری وجود داره و نیاز هر سرویس الزاما با بقیه‌ سرویس‌ها یکی نیست. یعنی مثلا شاید شما دیتای master مالی توی مایکروسرویس مالی رو ACID نیاز داشته باشین، ولی بخشی از داده مالی که توی مایکروسرویس دیگه‌ای جهت ریپورتینگ نگهداری می‌شه رو BASE.


💬 ببخشید اگر مطلب خیلی بیسیک بود، گاهی در تعامل با دوستان تصور می‌کنم برخی مفاهیم پایه تکرارش برای بخشی از مخاطبین شاید بد نباشه...

💡 سه خبر از کنفرانس بیلد ۲۰۲۵

1️⃣ تمرکز مایکروسافت روی Blazor
یه نکته مهم توی کنفرانس اخیر بیلد این بود که مایکروسافت اعلام کرد که Blazor رو به‌عنوان بستر اصلی و آینده‌دار برای توسعه رابط کاربری وب توی دات‌نت انتخاب کرده. این تصمیم، تاثیر زیادی روی اکوسیستم NET. خواهد داشت و نشون‌دهنده‌ی تغییراتی توی استراتژی‌های توسعه‌ی وب مایکروسافته. چرا تغییر؟ چون React و React Native همه‌جای مایکروسافت حضور دارن؛ از Teams تا منو استارت ویندوز تا آفیس... کماکان Razor Pages و MVC و... هم توسعه خواهند داشت ولی Blazor فعلا سوگولی است و هم روی پرفرمنسش هم اکوسیستمش داره با تمرکز کار می‌شه.


2️⃣ قابلیت جدید Kestrel یعنی Memory Trim در دات‌نت ۱۰
وب‌سرور اصلی و پیش‌فرض دات‌نت Kestrel (هم توی ویندوز و هم لینوکس) یکی از مشکلات وب‌سرورها توی سرویس‌های بزرگ رو یعنی مدیریت و بهینه‌سازی مصرف رم در بازه‌های زمانی طولانی رو سعی کرده برطرف کنه. تا الان Kestrel امکان مموری‌تریم نداره؛ یعنی وقتی در طول زمان رم مضرفی‌اش زیاد می‌شه، دیگه حافظه آزاد شده رو پس نمی‌ده. اگر حافظه‌ی تخصیص‌یافته به‌موقع آزاد نشه، برنامه دچار "memory bloat" یا حتی OutOfMemory می‌شه.

حالا Memory Trim چیه؟
نسخه‌های جدید Kestrel (هم‌زمان با Net 10)، ویژگی جدید Memory Trim رو خواهد داشت که به شکل دوره‌ای (یا هنگام کاهش بار سرور) حافظه‌ی بلااستفاده‌اش رو به سیستم‌عامل بگردونه. این باعث بهینگی بیشتر پرفرمنس و کاهش هزینه ابری می‌شه.

3️⃣ اضافه‌شدن JSON Patching به System.Text.Json + افزایش پرفرمنسش که سهولت تصمیم برای مهاجرت از Newtonsoft.Json به System.Text.Json رو فراهم می‌کنه.

توضیح تکمیلی:
وقتی NET 9. منتشر شد، Nick Chapsas، از Roth که عنوان شغلیش Principal Product Manager, ASP.NET است، درباره Blazor و استفاده داخلی مایکروسافت ازش پرسید. دو دلیل اصلی برای استفاده کم از Blazor در مایکروسافت، به ویژه برای برنامه‌های عمومی مثل آفیس، ارائه می‌ده که مهمه! یکی از این دلایل تاریخیه، یعنی زمانی که آفیس برای اولین بار React رو پذیرفت، Blazor در دسترس نبود. با این حال، دلیل دیگه روشن‌تره؛ می‌گه Blazor برای حل مشکل توسعه‌دهنده‌های NET. که به دانش عمیق جاوا اسکریپت نیز نیاز دارن، طراحی شده، که "هزینه و بار ناشی از استفاده از چند تکنولوژی (تایپ‌اسکریپت، ری‌اکت، دات‌نت و...) رو کم کنه". پلتفرم NET. برای استفاده روی سرور بهینه شده و Blazor تیم‌ها رو توانمند می‌کنه تا از همون توی مرورگر استفاده کنن. Blazor ارزش افزوده ایجاد می‌کنه، "وقتی نیاز داریم بدون یک تیم جداگانه جاوا اسکریپت front-end، کارهای بیشتری انجام بدیم."

نکته مهم اینه که Roth صریح ​​اعتراف می‌کنه که شرکت‌هایی به اندازه مایکروسافت، در حال حاضر تیم‌های front-end متخصص توی جاوا اسکریپت یا TypeScript دارن که Blazor رو کمتر جذاب می‌کنه.


پی‌نوشت: بیلد امسال و دات‌نت ۱۰ روی بهینگی‌های minimal API هم زیاد پرداخته شد، که به نظر میاد برای پروژه‌های بیشتری می‌تونه جذاب باشه. خصوصا که کامپایل AOT رو پشتیبانی می‌کنه کنه که توی controller-based ها نداریمش.


💬 نکته یا تجربه یا نظری دارید؟

⛳️ نکاتی در مورد تصمیم‌گیری تکنولوژی

اینکه برای پروژه جدید از چه تکنولوژی استفاده کنیم، یا مثلا فلان ابزار ارزش افزوده‌ای برای تیم، محصول و خودمون به‌همراه داره یا نه؛ و سوال‌های زیادی از این دست، عموما با دشواری و شک توأم با هم به پاسخ می‌رسن. برای همین چند روش و نکته رو خوبه تا با هم مرور کنیم. من خیلی خلاصه بهشون اشاره می‌کنم تا اگر کنجکاوی ایجاد کرد بیشتر در موردشون بخونید یا حتی همینجا مفصل‌تر صحبت کنیم...

1️⃣ چارچوب‌های تصمیم‌گیری معماری یا Architectural Decision-Making Frameworks

۱-۱ چارچوب ATAM (Architecture Tradeoff Analysis Method)
این چارچوب توسط SEI (Software Engineering Institute) در دانشگاه کارنگی ملون توسعه داده‌شده و در مراحل اولیه چرخه حیات توسعه نرم‌افزار وارد می‌شه. فازهای مشخص برای تحلیل نیازمندی‌ها، شناسایی گزینه‌ها و مقایسه trade-offها رو بررسی می‌کنه. و اینکه هر تکنولوژی چطور بر شاخص‌های کیفیت سیستمی، مثل پایداری، مقیاس‌پذیری، امنیت و غیره اثر می‌گذاره.

مراحل ATAM:
- شناسایی اهداف کسب‌وکار و نیازمندی‌های کیفیتی (Quality Attributes)
- لیست‌کردن گزینه‌های تکنولوژیک
- تحلیل سناریوهای کاربردی
- شناسایی trade-offها و ریسک‌ها
- انتخاب گزینه‌ای که بیشترین تطابق را با اهداف و کمترین ریسک را دارد.
توضیح مقدماتی در مورد ATAM
توضیح بیشتر؟ ری‌اکشن: ⚙️

۱-۲ چارچوب ADR (Architecture Decision Records)
یک روش برای مستندسازی تصمیمات تکنولوژیک به شمار میاد و هر تصمیم شامل: زمینه، گزینه‌ها، دلایل انتخاب، تاثیرات مثبت/منفی، و رد گزینه‌های دیگه رو می‌نویسم و افراد تیم می‌خونن یا برای آیندگان به یادگار می‌گذاریم. به تجربه عرض می‌کنم که نوشتن دقیق (و نه سَمبَل‌نویسی، خیلی خیلی به درک و تصمیم بهتر کمک می‌کنه، به شفاف شدن مسئله و نیاز کمک می‌کنه. درست برعکس حرف زدن که جمله سوم نرسیده، نکات جمله اول فراموش می‌شه!) برای تیم کوچک تا خیلی بزرگ می‌تونه کاربرد داشته باشه. مثال‌هایی از اسناد ADR

————————-

⚙️ در مورد ۲ و ۳ در صورت استقبال از بخش اول، در پست‌های بعدی خواهم نوشت.

2️⃣ مدل‌های مقایسه‌ای (Decision Matrix/Weighted Scoring Model)

3️⃣ چارچوب‌های شرکت‌های بزرگ (مثلاً ThoughtWorks Technology Radar، Gartner Magic Quadrant)
—————————

4️⃣پرسش‌های کلیدی که خوبه پاسخ بدیم و حداکثر تلاشمون رو برای پاسخ دقیق دادن بهشون به کار ببندیم:

🔤آیا تکنولوژی با نیازمندی‌های پروژه و بودجه همخونی داره؟

🔤آیا لیستی از معیارهای مهم (کارایی، هزینه، امنیت، پشتیبانی، یادگیری، بازار کار) داریم؟

🔤تیم چقدر تجربه یا علاقه بهش داره؟ (بر اساس معیار استاندارد و نه حس شخصی)

🔤کامیونیتی و ساپورتش چطور است؟ (کامیونیتی در دسترس و مشابه، از نظر سایز و عمق دانش)

🔤توسعه، نگهداری و مقیاس‌پذیری در بلندمدت چطور خواهد بود؟

🔤امنیت، ریسک vendor lock-in یا پشتیبانی تجاری داره یا نه؟

🔤در صورت اشتباه، راه بازگشت داریم؟

🔤چقدر تحت تاثیر trend و هیجان و علاقه شخصی خواهد بود، چقدر تابع بررسی و تحلیل؟

💬 تجربه و روش مورد استفاده شما چیه؟

🔌 توسعه محصول و اهمیت استفاده از Feature Toggle
(یا Feature Flag یا Release Toggle)

تا حالا شده یه امکان جدید توی نرم‌افزار رو بخواهید فقط برای عده مشخصی از مخاطبین فعال کنید؟ یکی دو تاش رو شاید بشه با if ولو کثیف پیاده کرد، ولی اگر زیاد شد چی؟ اگر خواستید مثلا از یه جا مدیریت کنید که مثلا ۱۰ درصد از کاربرهای خارج از ایران به جای متد الف، از متد ب استفاده کنند. این قابلیت رو که نرم‌افزارها قابلیت‌هایی رو توی خودشون دارن که فقط برای برخی افراد یا در صورت تمایل اون‌ها فعال می‌شه، این روزها خیلی جاها می‌شه دید، از پلتفرم‌های وب، تا سوییچ‌های گوگل کروم تا تلگرام... (یک نسخه ولی قابلیت‌ها یا رفتارهای متفاوت بسته به شرایط دلخواه ما)

ارائه‌ی تدریجی ویژگی‌های جدید (features) یکی از پایه‌های Continuous Delivery و توسعه چابک محصوله. به‌جای انتشار تغییرات بزرگ و پرریسک، تیم‌ها ترجیح می‌دهن قابلیت‌های جدید رو مرحله‌به‌مرحله منتشر کنن، و یا در محیط واقعی آزمایش کنن، ولی نه برای همه! نهایتا بر اساس بازخورد کاربران بهبود بدن تا آماده عرضه عمومی بشه یا شایدم از چرخه خارج شه. اینجا جاییه که مفهوم Feature Flags یا Feature Toggles وارد می‌شه.

❓مفهوم Feature Toggle چیه؟

ما Feature Toggle یا Feature Flag رو مکانیزمی می‌دونیم که روشن یا خاموش کردن قابلیت‌های خاص در نرم‌افزار، بدون نیاز به انتشار نسخه‌ی جدید رو فراهم می‌کنه (شبیه سوییچ‌های گوگل کروم که می‌شه قابلیت‌های آینده رو تست کرد). این یعنی یک قطعه کد در نرم‌افزار وجود داره ولی فعال‌سازی یا غیرفعال‌سازی اون به یک تنظیم یا یه سوییچ ساده بستگی داره.

❓چرا خوبه که از Feature Toggle استفاده کنیم؟

✅ تحویل تدریجی (Progressive Delivery): امکان rollout تدریجی به درصدی از کاربران.

✅ آزمایش A/B: مقایسه‌ی اثربخشی نسخه‌های مختلف از یک قابلیت.

✅ رفع سریع خطا: در صورت وجود خطا، می‌تونیم قابلیت رو بدون rollback نسخه غیرفعال کنیم (حتی از راه دور، یا بدون دخالت).

✅ فعال‌سازی مبتنی بر کاربر یا نقش: قابلیت خاص فقط برای کاربران خاصی فعال باشه (مثلاً کارمندان، beta testerها یا مشتریان ویژه).

✅ آزمایش در محیط production: بدون درگیر کردن همه کاربرها.

✅ کاربردهای دیگه مثل نسخه Canary یا قیمت‌گذاری پلکانی محصول و... هم از جمله کاربردهاشه...

✨ پلتفرم‌های تخصصی برای مدیریت Feature Toggle

خیلی از سازمان‌ها به‌جای نوشتن سیستم داخلی، از ابزارهای آماده استفاده می‌کنن که قابلیت‌های پیشرفته مثل UI مدیریتی، rollout تدریجی، آنالیتیکس، logging و SDKهای آماده ارائه می‌دهند:

➖پلتفرم LaunchDarkly: ابزار محبوب تجاری
➖پلتفرم Unleash: پروژه‌ی متن‌باز با رابط کاربری قابل قبول.
➖پلتفرم Flagsmith: پلتفرم متن‌باز و SaaS.
➖ پلتفرم Microsoft Feature Management: در پلتفرم Azure App Configuration.
➖ پلتفرم Split.io: با قابلیت‌های تحلیلی قوی.

برای گو لایبری خیلی خوبی هست و دات‌نت از نسخه ۹ این امکان رو به‌صورت بومی داره که اگر کنجکاو بودید بخونید یا بگید تا بیشتر در موردشون گپ بزنیم.

💬 نظر؟ تجربه؟ سوال؟

پی‌نوشت:
دلیل اینکه برخی پُست‌ها ادامه پیدا نمی‌کنه، استنباط من بر اساس بازخوردها است (برآیندی از view، کامنت، ری‌اکشن، اشتراک‌گذاری). این ساده‌ترین بازخورد از میزان مفید یا مورد کنجکاوی قرار گرفتن مطلب برای مخاطبه. لذا امیدوارم حمل بر کم‌توجهی یا فراموشی نشه.

📌 تفاوت Strong Consistency و Eventual Consistency در یک نگاه

فرض کنین یه سیستم توزیع‌شده داریم با چندین node در مکان‌های مختلف (چیزی که مثلا این روزها با شرایط کم‌برقی لازمه). حالا وقتی یه داده تغییر می‌کنه، سوال اینه: کی و کجا اون تغییر رو ببینیم؟

🧱 Strong Consistency (سازگاری قوی)
هر تغییری که انجام بشه، همه باید فوراً ببینن. یعنی وقتی یه کاربر داده‌ای رو آپدیت کرد، تمام کاربران دقیقاً همون مقدار جدید رو ببینن — هیچ تأخیری در دیدن داده‌ی به‌روز وجود نداره.

✅ مناسب برای:

- سیستم‌های مالی یا رزرو که "دوگانگی" براشون قابل قبول نیست
- تراکنش‌های حیاتی مثل خرید سهام، پرداخت آنلاین

مثال ساده:
اگه از ATM پول برداریم، باید فوراً موجودی‌مون در همه جا بروز بشه. وگرنه ممکنه دوباره از یه دستگاه دیگه پول بکشیم!

🌊 Eventual Consistency (سازگاری نهایی)
داده ممکنه در لحظه همه جا یکی نباشه، ولی در نهایت (مثلاً چند ثانیه بعد) همسان می‌شه. این مدل performance بالاتری داره و مقیاس‌پذیرتره.

✅ مناسب برای:

- شبکه‌های اجتماعی
- سیستم‌های کش (Cache)
- فروشگاه‌های بزرگ آنلاین
- توزیع محتوا (CDN)

مثال ساده:
تو اینستاگرام یه پست رو لایک می‌کنی، ولی ممکنه چند ثانیه طول بکشه تا تعداد لایک برای بقیه آپدیت بشه — ولی در نهایت همه یه عدد می‌بینن.

💡 باید واقع‌بین بود، برخی موارد، تیم فنی این موضوع رو از یه آدم غیر فنی می‌پرسه که «قربان» دستور می‌فرمایید کدام گونه‌ی consistency را به خدمت گیریم؟! قربان هم پاسخ می‌ده: ببین مهندس «سامانه» ما خیلی مهمه، قراره میلیان‌ها بلکه میلیاردها کاربر در لحظه داشته باشه. فلذا داده‌ها باید در همه جا یکسان باشه، بلادرنگ، در لحظه! این می‌شه که آخرش نه توزیع‌یافتگی محقق می‌شه، وقتی هم محقق می‌شه با کندی و بدبختی و فلاکت برقرار می‌شه، اگر هم درست برقرار بشه، هزینه‌ی تمام‌شده معقولی نداره!
مثال تجربی و واقعی: سال‌ها پیش (۱۳۸۷) همین چالش دشوار قانع کردن یک سازمان بزرگ برای غیرالزامی بودن strong consistency داشتم، از یک طرف مشکلات عدیده مقیاس‌پذیری و دسترس‌پذیری داشتن، از یه طرف اصرار مکرر بر اینکه ما کارمون حیاتیه و باید راهکار تضمین کنه که داده‌ها همه‌جا در لحظه یکسانه. با هزار اما و اگر، نهایتا راضی به تست شدند که ترکیبی از این دو رو پیاده کنم تا بخشی از سیستم، داده‌ها رو به لحظه داشته باشه، و بخش دیگه‌ای از سیستم بین ۴ تا ۱۰ ثانیه بعد توی ۳۷ نقطه در کشور داده‌ی به‌روز دریافت کنه. بعد از تست و دوره پایلوت، اون ساختار و معماری سال‌ها کار کرد (می‌کنه) و ثابت شد که «به‌روز» یک مفهوم مطلق و جهان‌شمول نیست. در حالیکه اگر قرار بود همه‌جا strong consistency بدم، تفریبا محال ممکن بود که کار انجام شه، یا اگر انجام میشد هزینه پیاده‌سازی و نگهداریش شاید بارها بیشتر بود، در حالیکه ۴ تا ۱۰ ثانیه برای اون نیاز، کاملا قابل قبول بود.

🧬 در مورد Arazzo Specification و کاربردهاش!

کمتر اپلیکیشنی رو می‌شه پیدا کردن که مستقیم یا غیرمستقیم با APIها خصوصا REST مرتبط نباشن. حالا Arazzo Specification یه استاندارد جدید و البته «باز»، از OpenAPI Initiative است که به‌عنوان مکمل OpenAPI Specification برای توصیف جریان کار (workflow) APIها طراحی شده. توسعه‌دهنده/معمار می‌تونه دنباله‌ای از فراخونی‌های API و وابستگی‌هاش رو به‌صورت ساختاریافته و قابل فهم برای انسان (فنی و کسب‌وکاری) و ماشین تعریف کنه.

📜 سابقه و هدف
قبلن، OpenAPI با تمرکز روی توصیف endpointها توسعه داده شده بود. با swagger یا ابزارهای دیگه به راحتی endpointها رو می‌شه بررسی کرد، ولی خیلی از فرایندها، چندین endpoint رو درگیر می‌کنن اما در عمل، حالا چرخه‌ی فراخونی این endpointها به نحوی باید مستند و قابل رویت باشه. چه تیم فنی و چه تیم کسب‌وکاری باید بتونن فرایند فراخونی APIها رو بررسی کنن، که کدوم API اول باید کال بشه و بعد دومی و سومی و الی آخر. برای پاسخ به این نیاز، Arazzo Specification سال ۲۰۲۴ معرفی شد تا بشه جریان‌های کاری، خصوصا پیچیده‌ها رو توصیف و تشریح کرد.

🎯 اهمیت و کاربرد
- مستندسازی API call workflow: توصیف دقیق دنباله‌ی فراخونی APIها برای سناریو خاص.
- تولید خودکار مستندات و SDK: ایجاد مستندات اینتراکتیو و تولید کدهای کلاینت بر اساس جریان‌های کاری تعریف‌شده.
- تسهیل تست‌های end-to-end: تعریف سناریوهای تست پیچیده با استفاده از جریان‌های کاری.
- ادغام با هوش مصنوعی: ارائه ساختار قابل فهم برای مدل‌های زبانی بزرگ (LLMs) برای تعامل با APIها.
- بهبود تجربه توسعه‌دهنده (DX): کاهش نیاز به مستندسازی دستی و افزایش وضوح استفاده از APIها.

🧩 ساختار Arazzo
یک سند Arazzo معمولاً شامل بخش‌های زیره:

بخش arazzo: نسخه مشخصه Arazzo (مثلاً 1.0.1).
بخش info: اطلاعات متادیتا درباره سند.
بخش sourceDenoscriptions: فهرستی از منابع (مثل فایل‌های OpenAPI) که جریان‌های کاری بهشون ارجاع می‌دن.
بخش workflows: تعریف یک یا چند جریان کاری، شامل مراحل، ورودی‌ها، خروجی‌ها و معیارهای موفقیت یا شکست.
بخش components: تعریف مؤلفه‌های قابل استفاده مجدد برای جلوگیری از تکرار.

مثال توی کامنت
لینک مستند رسمی Arazzo Specification
مخزن GitHub Arazzo
مقاله در Swagger Blog

جدی گرفتن رویکرد API First نه تنها کمک بزرگی به توسعه اصولی‌تره، بلکه به تیم/سازمان‌سازی بهتر کمک می‌کنه، همون‌طور که تست نوشتن بخشی از مسیر بلوغ تیم و سازمانه؛ مستندسازی درست و ساختارمند هم بخشی از مسیر بلوغ توسعه‌دهنده، تیم و سازمانه. فایل ورد یا کانفولئنس یا ... ابزار مدیریت مستندات API نیستن!

💬 نظر شما چیه؟!

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

من ۳ بار رو به خاطر دارم که چنین مشورتی رو گرفته باشم (۱۶، ۱۹ و ۲۱ سالگی) و چیزی که می‌نویسم آمیزه‌ای از تجربه و یادگیری خودمه، لذا ذیل درس و پند و پیشنهاد بیانش نمی‌کنم؛ بلکه یک روایته، فارغ از اینکه چقدر مفیده یا گستره‌ی دامنه‌اش چقدر می‌تونه باشه!

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

بخش ۱: فرصت طلایی ۲۰ تا ۳۰ سالگی

درسته که ماهی رو هر وقت از آب بگیری تازه‌ است! ولی یه زمان‌هایی اون ماهی خوش‌طعم‌تر یا مستعدتر برای پخت است! دهه ۲۰ سالگی خیلی مهمه، سال‌های طلاییه! (البته سال‌های پلاتینیوم هم داریم که برمی‌گرده با کودکی و نوجوانی که شاید بعدتر در موردش نوشتم) ولی فعلا از دلایل اهمیت این دهه می‌شه به چند تایی اشاره کرد:

*️⃣انعطاف‌پذیری ذهنی بالاست؛ تغییر عادات هنوز کم‌هزینه است.
*️⃣مسئولیت‌های زندگی (خانواده، وام، تعهدات شغلی ثابت) معمولاً کمتره و می‌شه ریسک کرد.
*️⃣بازار کار حاضره به «جونیورهای مشتاق» فرصت یادگیری بده.

🧠 مهارت‌های فکری پایه

✅ تفکر الگوریتمی: بهترین سال‌های این مهارت در کودکی است، ولی دهه ۲۰ سالگی سال‌های خوبیه که اگه این مهارت کسب نشه، در سال‌های بعدی محال که نه؛ ولی دشوار می‌شه این مهارت رو در خودمون ایجاد و تقویت کنیم. شکستن مسئله به مراحل کوچک‌تر. توانایی، عادت به نوشتن و بیان راه حل روی کاغذ؛ و نهایتا تفکر انتقادی نسبت به مسایل و راه‌حل‌ها با هدف پیدا کردن بهبودهای احتمالی و البته مقرون‌به‌صرفه.

✅ یادگیری مادام‌العمر: فناوری‌ها زود منقضی می‌شه؛ مهارت اصلی، «یاد گرفتنه» نه «دانسته‌ داشتن».
اینکه یاد بگیریم چجوری یاد بگیریم، چجوری مطالب رو به‌صورت منفرد و منفک یاد نگیریم و مقدمه و موخره و کاربردشون رو یاد بگیریم؛ منبع اصیل رو از غیراصیل تشخیص بدیم و کلی نکته در مورد یادگیری مستمر رو در خودمون نهادینه و تبدیل به رویه کنیم چیزی که توی این دهه آخرین شانس‌هاش رو داریم و بعدش سخت و سخت‌تر می‌شه.

✅ بازتاب و مستندسازی: بعد از هر پروژه، چند خطی در موردش بنویسید؛ شاید بگین توی ذهنم فکر می‌کنم، ولی باور کنید اثر نوشتن بارها عمیق‌تر از فقط فکر کردنه... بنویسید چی یاد گرفتم؟ چی رو می‌تونم بعدن بهتر کنم؟

✅ پیدا کردن متر و معیار: تمرین کنیم هر پیروزی، هر شکست، هر تعریف و تمجید، هر دستاورد رو فقط در مختصات محیط اطرافمون نسنجیم. شاید یک کار یا بهبود توی محیط فعلی‌مون یک دستاورد بزرگ و درخور تمجید و تشویق باشه؛ ولی همون کار توی محیط بزرگ‌تر و پیشرفته‌تر یک امر بدیهی و پیش‌وپا افتاده باشه. منظورم این نیست که خودمون رو دست‌کم بگیریم و دستاوردهامون رو با دستاورد دانشمندان مرکز تحقیقات سِرن یا فلان لابراتوار ام‌آی‌تی مقایسه کنیم؛ بلکه بدونیم نسبت دستاوردمون با محیط بیشینه‌ی پیشرفتگی ذهنمون + ۱ واحد، چقدر فاصله داره. این کمک می‌کنه ذهنمون بزرگ‌تر از محیط اطرافمون باشه؛ بدونیم دنیای بعد از پرچین‌های مزرعه چه شکلیه! همین‌طور اشتباهات و شکست‌هامون رو درست بسنجیم، الکی کوچیک یا بزرگشون نکنیم بلکه نسبتش رو یاد بگیریم...

⚙️ مهارت‌های فنی

➖ حداقل یک زبون سطح بالا رو اول تا سطح ساخت پروژهٔ واقعی و بعدتر به صورت عمیق و تا لایه‌های پایینش مسلط شید.
➖ ابزارهای عمومی و پایه مثل Git یا کامندنویسی لینوکس و ابزارهای توسعه مشارکتی یا ALM رو اصولی و عمیق یاد بگیرید، تا به کارهای مقدماتی و ابزارهای گرافیکی محدود نباشید.
➖ ساختمان داده‌ها، الگوریتم‌ها، پایگاه داده و مفاهیم پایهٔ سیستم‌عامل رو خوب بشناسید—نه برای امتحان، برای حل مسئله! برای تحلیل شرایط و مشکل، برای درک چیزی که داره اجرا می‌شه یا حتی اجرا نمی‌شه! حتی اگر دانشگاه در تدریس این مفاهیم کم‌توجهی کرده یا حتی از رشته زمین‌شناسی تغییر فیلد دادید و پیشینه‌اش رو نداشتین، اینا واقعا کاربردی هستن... اگر به احمق بودن کسانی که کتاب و جزوه بی‌کیفیت رو صرفا ترجمه کردن شک کردید، هرگز به احمق نبودن کسانی که این دروس رو «تألیف» کردن شک نکنین!

تمایل دارید این بحث ادامه پیدا کنه؟ (ادامه ۲۰ تا ۳۰ سالگی، و بعدتر دهه‌های قبل و بعدش)، ری‌اکشن ⚙️ ۱۰ درصد تعداد ویو)

🙂 روایت ۲۰ تا ۳۰ سالگی، بخش دوم...
(مطالعه بخش اول)

🏛 ساختن نمونه‌کار

🔣 این‌سال‌ها که فراغت بیشتری از دهه بعدی زندگی‌تون دارید، سعی کنید چیزهایی رو ولو کوچک بسازید؛ ترجیحا به صورت end‑to‑end بسازید (فرانت، بک، CI، دپلوی). درسته که نمیشه پروژه بزرگ رو به صورت انفرادی end‑to‑end ساخت ولی پروژه کوچیک رو می‌شه. بهتون درک بسیار عمیق‌تری می‌ده از بخش‌هایی که سال‌های دیگه یا توی پروژه‌های بزرگ‌تر نمی‌تونین همه‌جاش درگیر باشید و نقشتون محدودتر و تخصصی‌تر یا کلی‌تر و فراگیرتر می‌شه.

🔣 ریپوهای شخصی‌ خودتون رو مثل محصول واقعی نگه‌داری کنید: README، Issues، Releases, Chane log، پیام کامیت درست بنویسد... تمرینی خواهد بود برای دهه‌ای که همین ریزه‌کاری‌ها از شما کاراکتر استانداردتری می‌سازه برای کارهای بزرگ.

🔣 اگر کاری رو نمی‌تونید نشون بدید، انگار انجامش ندادید! با توهم اینکه تولید این یا اون ساده‌ است، توی ذهنتون از خودتون قهرمان فرضی نسازید... جامعه، اکوسیستم و محیط خارج از رویای شما، اعتباری برای توانمندی غیرمشهود قائل نیست.

📇 مشارکت در اجتماع

🔣 در اوپن‌سورس مشارکت «ارزش آفرین» کنید: Issue triage، مستندسازی، رفع باگ ساده، و هرگز سراغ مشارکت‌هایی که مسئله‌ای حل نمی‌کنه نرید. به بیان ساده خودتون رو گول نزنید و بقیه رو علاف پول‌ریکوئست بی‌ارزش نکنید...

🔣 در رویدادهای محلی یا آنلاین شرکت کنید؛ شبکه‌سازی کنید، اگر حتی در حد چند دقیقه مطلب می‌تونید تهیه کنید، مشارکت کنید.

🔣 متواضعانه برای دانش‌آموزهای دبیرستانی یا جونیورترهایی که سوال طرح می‌کنن وقت بگذارید، حتی برای سوال یک نوجوان دبیرستانی قبلش سرچ کنید و مطمئن بشین مطلب صحیح رو به شیوه صحیح در پاسخ به پرسشش مطرح می‌کنین، همین‌طور برای همکار یا همکلاسی‌تون.

🔋مدیریت زمان و انرژی

➖ روش‌های مختلفی برای تمرکز روی کار و استفاده بهینه از زمان وجود داره، مثل قانون ۴۵–۱۵: ۴۵ دقیقه تمرکز، ۱۵ دقیقه استراحت فعال (مثل قدم‌زدن، نه گوشی چک کردن). خیلی از ما به خودمون میایم و می‌بینیم کل روز داریم می‌دویم ولی آخرش هم از همه کارها عقبیم. کار عمیق، تمرکز و زمان‌بندی چیزهاییه که این روزها خصوصا با وجود شبکه‌های اجتماعی و اخبار و... سخت تبدیل به رفتار و عادت می‌شن. جدی بگیریمشون!
➖ خواب کمتر از ۷ ساعت، بدهی فنی ذهنی ایجاد می‌کنه (آسیب‌های جسمی که من به واسطه کم خوابید در سنین کم‌تر، در سنین بالاتر تجربه کردم اهمیتش رو بهم ثابت کرد).
➖ نرمش، پیاده‌روی یا هوازی باعث می‌شه در دهه ۴۰ درگیر عدم تمرکز و وقفه در کار و پیشرفتتون به خاطر کمردرد و زمین‌گیر شدن نشید. همچنین کمک می‌:نه درگیر burnout شدن و خستگی فکری نشید.

😵‍💫 اشتباهات رایج
✖️ عجله و طمع! برای سنیور شدن (خطاب شدن)، برای درآمد فلان، برای دیده شدن، و... عجله و طمع نکنید، تیر خلاص خواهد بود به تمام سال‌های پیشِ روی شما... از دریایی که در نزدیکی ساحل عمقش ۱۰ سانتیمتر است ولی کمی جلوتر عمقش به چند ده متر می‌رسه؛ تبدیل می‌شید به استخری که سرتاسرش عمق ۱۰ سانتیمتری داره!
✖️ مقایسهٔ خطی با دیگران در لینکدین؛ توییتر و.. مسیر آدم‌ها متفاوته.
✖️تعویق بیش‌ازحد یادگیری علوم پایه‌ای؛ دیر یا زود به درک پیچیدگی نیاز پیدا می‌کنید؛ یه جا می‌رسه که به خاطر علوم پایه‌ای رو خوب بلد نبودن (ریاضی، الگوریتم و...) متوقف می‌شید؛ توی CRUD گیر می‌کنید.
✖️شکارچی مد روز نشید، خصوصا بدون درک اصول. اول اصول، بعد ابزار.

✏️ جمع‌بندی
دههٔ ۲۰ سکوی پرش مهمیه، نه خط پایان. این دهه، سن کاشت است، و نه برداشت! تا می‌تونید بکارید، تا می‌تونید به جای فکر کردن به تصویر زیبای روی خاک، به فکر شخم خوب و بذر خوب کاشتن و خلاصه زیر خاک باشید، چیزی که دیده نمی‌شه فعلا، ولی فصل برداشت زیبایی خودش رو نشون می‌ده، به فکر گل‌هایی که عمرشون و زیبایی‌شون چند صبا بیشتر نیست نباشید... تله‌ها و فریب‌ها این سنین زیاد هستن، مراقبشون باشین 😉

در صورت تمایل جمع و فیدبک مثبت (⚙️) از این بحث، در پست بعدی دربارهٔ استراتژی‌های ۳۰ تا ۴۰ سالگی و تحولات مسیر شغلی و رفتاری صحبت خواهیم کرد. 💬 اگر نکته یا سؤال خاصی دارید بنویسید تا در نسخه‌های بعدی اضافه کنم.