🔔 ۲۵ دقیقه دیگه 😉

گوگل میت

📱 ویدیو جلسه مرور مهارت‌های مورد نیاز و مسیر رسیدن به مهندس ارشد نرم‌افزار - بخش ۱

🔄 فایل اسلایدها رو هم در بخش کامنت قرار دادم

ممنون از همه دوستانی که تشریف آوردن، امیدوارم هر چه زودتر توی جلسه دوم ببینمتون 😊🌱

لینک یوتیوب

📝 روش‌هایی برای اولویت‌بندی نیازمندی‌ها

جلسه «مرور مهارت‌های مورد نیاز و مسیر رسیدن به مهندس ارشد نرم‌افزار» رو بر اساس چرخه توسعه نرم‌افزار (SDLC) طرح کردم، و بخش اولش «نیازمندی‌ها و تحلیل (Requirements & Analysis)» بود. چون از روش‌های MoSCoW و Kano Model برای اولویت‌بندی نیازمندی‌ها (Prioritization Techniques) اسم بردم، گفتم شاید بد نباشه برای دوستانی که آشنایی ندارن، کمی توضیح بدم.

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

اینجاست که تکنیک‌های اولویت‌بندی میان وسط. اینا ابزارهایی هستن که کمک می‌کنن:

*️⃣خواسته‌های کاربر، کسب‌وکار و تیم توسعه رو دسته‌بندی کنیم.
*️⃣تصمیم‌های درست‌تری بگیریم.
*️⃣روی چیزهایی تمرکز کنیم که بیشترین تأثیر رو دارن.

دو تا روش محبوب رو اینجا معرفی می‌کنم که می‌تونن کمک کنن. Kano Model و MoSCoW

🔍 مدل اول: Kano – وقتی رضایت کاربر مهمه
مدل Kano از اسم یه پروفسور ژاپنی به اسم «نوری‌آکی کانو» الهام گرفته شده. ایده اصلی اینه که همه فیچرها تأثیر یکسانی روی رضایت کاربر ندارن. بعضیاشون اگه نباشن، کاربر عصبانی میشه. بعضیا اگه باشن، خیلی خوشحال میشه. بعضیا هم بودن یا نبودنش براش فرقی نداره! (کاربر رو ذینفع (stakeholder) هم تعبیر می‌کنیم)

دسته‌بندی ویژگی‌ها توی Kano:
*️⃣گروه Basic Needs (Must-be): چیزایی که انتظار می‌ره حتماً باشن. نبودش فاجعه‌ست ولی بودنش کسی رو شگفت‌زده نمی‌کنه.

*️⃣گروه Performance Needs: هرچی بهترش کنی، رضایت بیشتر میشه (مثلاً سرعت سایت یا دقت جستجو).

*️⃣گروه Excitement Needs (Delighters): قابلیت‌هایی که کاربر انتظار نداره، ولی وقتی می‌بینه خوشحال میشه. (مثل auto-save هوشمند یا تم تیره پیش‌فرض)

*️⃣گروه Indifferent: بودن یا نبودنش خیلی فرقی نمی‌کنه.

*️⃣گروه Reverse: بعضیا ممکنه یه فیچر رو نخوان!

🔧 کاربرد: این مدل خیلی برای مصاحبه با کاربر و طراحی تجربه کاربری خوبه. کمک می‌کنه روی فیچرهایی تمرکز کنی که "دل کاربر رو می‌بره"، نه فقط اونایی که لازمه.
——————————————————-

📦 مدل دوم: MoSCoW – برای اولویت‌بندی سریع و پروژه‌محور
اشتباه نشه؛ MoSCoW یه مخففه و ربطی به شهر مسکو نداره! 😄:

*️⃣گروه Must have: اگه اینا نباشن، محصول کار نمی‌کنه.

*️⃣گروه Should have: مهمن، ولی می‌تونن تاخیر بخورن.

*️⃣گروه Could have: اگه وقت شد اضافه‌شون می‌کنیم.

*️⃣گروه Won’t have (this time): الان انجامش نمی‌دیم، شاید بعداً.

🔧 کاربرد: MoSCoW بیشتر توی مدیریت پروژه و جلسه‌های برنامه‌ریزی اسپرینت استفاده میشه. وقتی می‌خوای با تیم تصمیم بگیری که توی این بازه زمانی رو چی تمرکز کنید.

🧠 اگه خواستی بیشتر بدونی...
اولا هر کاری رو اگر «روشمند» یعنی بر اساس یک مدل بریم جلو، ولو کارهایی که بدیهی به نظر میان، عموما شانس موفقیت بالاتری داریم.

دوما، فقط این دو تا نیست؛ اگه دوست داری مدل‌های بیشتری رو بررسی کنی یا روش‌های دیگه‌ای برای تصمیم‌گیری داشته باشی، اینا هم ارزش وقت گذاشتن دارن:

روش RICE Scoring – برای اولویت‌بندی عددی و داده‌محور
روش WSJF – مخصوص تیم‌های اجایل و SAFe
روش Opportunity Scoring – مبتنی بر نیازهای پنهان کاربر
روش Feature Buckets – دسته‌بندی فیچرها براساس تأثیر و استراتژی
روش Eisenhower Matrix – ساده ولی کاربردی برای تصمیم‌گیری‌های روزمره

💬 شما از چه روشی برای اولویت دادن به نیازها و کارها استفاده می‌کنی؟

2️⃣ جلسه دوم مرور مهارت‌های مورد نیاز و مسیر رسیدن به مهندس ارشد نرم‌افزا

اگر نظر مثبتی نسبت به جلسه اول «مرور مهارت‌های مورد نیاز و مسیر رسیدن به مهندس ارشد نرم‌افزار» داشتید و فکر می‌کنید ادامه بحث می‌تونه براتون جالب باشه، لطفا از طریق فرم زیر بگید 😊

🗓 برای روز یکشنبه ۷ اردیبهشت (۲۷ اپریل) ساعت ۱۸:۳۰ به وقت تهران

https://forms.gle/ayy2Q3MESKnhrNt3A

🔔 ۳۰ دقیقه دیگه 😉

https://meet.google.com/okw-tdmb-gut

📱 معماری سلولی چیه، لزوم توجه بهش؛ و چرا slack رفت دنبالش؟

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

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

❓ مشکل slack از کجا شروع شد؟
یه روز توی اسلک، نمودارهای مانیتورینگ نشون دادن که یکی از Availability Zone (AZ) های AWS در منطقه us-east-1 داره پکت‌های زیادی رو از دست میده. این باعث خطا و کندی سرویس برای کاربرها شده بود.
مشکل اصلی اینجا بود که با وجود اینکه اسلک از چند AZ استفاده می‌کرد، وقتی یک AZ دچار مشکل می‌شد، کل سرویس تحت تأثیر قرار می‌گرفت! خب این اصلاً منطقی نیست! مگه نه اینکه هدف استفاده از چند AZ همین هست که اگه یکی به مشکل خورد، بقیه کار رو پیش ببرن؟

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

🎯 اسلک چهار هدف اصلی داشت:

- حذف ترافیک از یک AZ در کمتر از ۵ دقیقه (سرعت)
- حذف ترافیک نباید باعث خطای قابل مشاهده برای کاربر بشه
- خروج و بازگشت ترافیک یک AZ باید تدریجی باشه (مثلاً ۱٪ یا ۱۰٪)
- مکانیزم Drain نباید به AZ مشکل‌دار وابسته باشه

🧠 استراتژی‌های پیاده‌سازی در اسلک

*️⃣منزوی‌سازی (Siloing): سرویس‌ها در یک AZ فقط با سرویس‌های همون AZ ارتباط داشته باشن. ساده‌ترین روش، اما برای همه سرویس‌ها امکان‌پذیر نیست.

*️⃣مدیریت سرویس‌های با consistency قوی: سرویس‌هایی مثل Vitess (لایه شاردینگ روی MySQL) نیاز به مدیریت failover دارن.

*️⃣تقسیم‌بندی براساس CAP: سرویس‌ها براساس نیازشون به Consistency یا Availability دسته‌بندی شدن:
🔤سرویس‌های Stateless مثل webapp ها (راحت‌ترین)
🔤سرویس‌های Eventually Consistent مثل Memcache (نسبتاً راحت)
🔤سرویس‌های Strongly Consistent مثل Vitess (سخت‌ترین)


*️⃣کنترل ترافیک با Envoy و xDS: استفاده از traffic weighting برای هدایت تدریجی ترافیک

چرا این بار موفق شدن؟
اسلک قبلاً یک بار تلاش کرده بود این کار رو انجام بده و شکست خورده بود. این بار چند اصل مهم رو رعایت کردن:

- تدریجی بودن (Incrementality): به جای ساخت یک سیستم کاملاً جدید و تغییر یکباره، هر سرویس رو جداگانه و تدریجی تغییر دادن.
- نگاه از پایین به بالا (Bottom-up): با هر تیم سرویس جداگانه کار کردن و راهکار مخصوص اون سرویس رو پیدا کردن.
- به اندازه کافی خوب (Good Enough): پذیرفتن اینکه لازم نیست همه سرویس‌ها یکجا و کامل تغییر کنن.
- رویکرد Roofshot به جای Moonshot: به جای یک حرکت مستقیم و بلندپروازانه، مجموعه‌ای از قدم‌های کوچکتر که در هر مرحله ارزش ایجاد می‌کنه.
- تست‌های منظم: هر هفته یک AZ رو drain می‌کردن و پیشرفت رو اندازه می‌گرفتن.

⛳️ نتایج:

- الان می‌تونن یک AZ رو در ۶۰ ثانیه از سرویس خارج کنن
- هزینه‌های انتقال داده بین AZ کاهش پیدا کرده
- یک مکانیزم blue-green deployment جدید به دست آوردن
- راهکار عمومی برای مقابله با مشکلات محدود به یک AZ دارن

📝 نکته‌های کلیدی برای پروژه‌های زیرساختی بزرگ

*️⃣تدریجی ولی مداوم کار کنید: پروژه‌های بزرگ زیرساختی باید گام به گام پیش برن
*️⃣در نظر بگیرید هر سرویس دلیلی برای وضعیت فعلیش داره: تصور نکنید که افراد دیگه اشتباه کردن
*️⃣ارزش رو در هر مرحله قفل کنید: پروژه باید در هر مرحله ارزش ایجاد کنه، نه فقط در پایان
*️⃣کارآیی رو برای کاهش ریسک فدا کنید: گاهی راه مستقیم، بهترین راه نیست

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

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

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

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

- مایکروسرویس
- متدولوژی Domain-Driven Design
- معماری‌ها Clean / Hexagonal / Onion

اگر فکر می‌کنید موضوع جذابیه: ⚙️
اگر هم پیشنهادی براش دارید حتمن بنویسید 😊

📇 تاریخچه و زمینه پیدایش مایکروسرویس

شاید بد نباشه تا دفعه بعد که خواستید در مورد معماری و ساختار یه پروژه تصمیم بگیرید، یه بار پیشینه‌ی پیدایش مایکروسرویس رو مرور کنین تا از تناسب «نیاز» و «راهکار»ی که مدنظر دارید مطمئن باشید.

نمیشه دقیق و قاطع گفت «اولین» بار کی مفهوم مایکروسرویس رو پیاده کرده. مفهوم مایکروسرویس‌ از تکامل معماری‌های قبل‌تر از خودش، خصوصا به عنوان یک پاسخ به محدودیت‌های سیستم‌های یکپارچه، و پیچیدگی معماری سرویس‌گرا (SOA) شکل گرفت. حالا دو چیز رو باید توضیح داد، یک شیوه‌های امروزی‌تر پیاده‌سازی مایکروسرویس، و یکی مفهوم و معماری‌اش. برای پیاده‌سازی مدرن، نتفلیکس رو می‌شه به عنوان یکی از اولین و تأثیرگذارترین پذیرندگان رویکرد میکروسرویس‌ توی مقیاس بزرگ شناخت. نتفلیکس مهاجرت خودش از معماری یکپارچه به مایکروسرویس‌ها رو حدود سال ۲۰۰۹ شروع کرد، خیلی قبل از اینکه اصطلاح "مایکروسرویس‌" به طور رسمی سال ۲۰۱۱ مطرح بشه. تا سال ۲۰۱۱، نتفلیکس طراحی مجدد بخش قابل توجهی از سیستم‌هاش به مایکروسرویس‌ها رو تکمیل کرده بود و از AWS استفاده می‌کرد، و خیلی از الگوهایی که امروز به عنوان استاندارد یا best practice شناخته می‌شن رو پیاده کرده بود.

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

پذیرندگان بعدی این معماری، از eBay و Spotify و... همه یک سری دغدغه مشترک داشتن، یعنی مقیاس‌پذیری، پیچیدگی و وسعت سیستم، و استقرار، اونم با تیم‌های بزرگ.

بیایم نگاه بندازیم به روایات!
جناب Fred George یکی از پیشگامان معماری مایکروسرویس می‌گه هر مایکروسرویس باید به قدری ساده و کوچک باشه که توی ذهن یک توسعه‌دهنده جا بشه:

"small enough and simple enough that a single developer can understand the whole thing"

بعدتر همین رو مارتین فولر هم به نحوی تکرار می‌کنه.

حالا سوال اینه که اگر تیم توسعه و تعداد سرویس‌ها بزرگ نیستند، آیا مقیاس‌پذیری مورد نیازمون به حدی رسیده که scale-up پاسخگو نباشه و بریم سراغ شکست و توزیع سرویس‌ها؟ آیا زیرساخت لازم رو از پردازش ابری تا DevOps تا مونیتورینگ/observabilty و... داریم؟ آیا ظرفیت مستندسازی API، فرایند، کاتالوگ داده‌ها و فرایندها و... رو داریم؟

تجربیات مستند زیادی وجود داره که استارتاپ‌ها و تیم‌های کوچیک زیادی «زودتر از موعد» به سراغ مایکروسرویس رفتن و از عهده‌ی سربارش بر نیومدن... یادمون نره، معماری باید در خدمت مسائل ما باشن، نه اینکه ما در خدمت معماری دربیایم.

توی مباحث DDD به تفصیل خواهم گفت که معماری سازمانی ما هم حتی باید با شیوه تحلیل نیازمندی‌ها و شیوه ترجمه‌ی اون‌ها به راهکارهای نرم‌افزاری سازگار باشه.

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

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

💬 نظر یا تجربه شما چیه؟

🔭 تاریخچه و زمینه پیدایش 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 تعریف کرد...