Forwarded from CodeLodge
در این قسمت از سری پادکست های Code Lodge، به بررسی مضرات استفاده نادرست از Domain-Driven Design (DDD) می‌پردازیم. متأسفانه، در بسیاری از مواقع، استراتژی‌های بلندمدت فدای تاکتیک‌های کوتاه‌مدت می‌شوند و DDD به جای یک رویکرد موثر، صرفاً به یک ابزار بازاریابی برای فروش بسته‌های آموزشی تبدیل شده است. اغلب تنها بخش تکنیکال DDD برای ما برنامه‌نویسان جذاب است که همین مسئله ما را در مسیر خطرناکی خواهد انداخت .
در این قسمت با نقد و تحلیل این مشکلات، تلاش می‌کنیم تا شما را از خطرات و چالش‌های احتمالی آگاه کنیم و راهکارهایی برای اجتناب از این اشتباهات ارائه دهیم.
میزبانان شما در این قسمت:
بهنیا آزاد
بابک طارمی
این ایپزود را می توانید از طریق لینک های زیر هم بشنوید :
- 🔗Spotify
- 🔗Amazon
- 🔗Castbox
-🔗Apple podcast
-🔗 Shenoto
#Codelodge
#Software
#DDD
#softwareDeveloper
#SoftwareEngineer
@codeLodge
در این قسمت با نقد و تحلیل این مشکلات، تلاش می‌کنیم تا شما را از خطرات و چالش‌های احتمالی آگاه کنیم و راهکارهایی برای اجتناب از این اشتباهات ارائه دهیم.
میزبانان شما در این قسمت:
بهنیا آزاد
بابک طارمی
این ایپزود را می توانید از طریق لینک های زیر هم بشنوید :
- 🔗Spotify
- 🔗Amazon
- 🔗Castbox
-🔗Apple podcast
-🔗 Shenoto
#Codelodge
#Software
#DDD
#softwareDeveloper
#SoftwareEngineer
@codeLodge
👍3👏1
Forwarded from کانال مکتب‌خانه DDD
چرا تخمین‌زدن سخت است، و به‌جای آن چه باید کرد❓
در توسعه محصول، اغلب تحت فشاریم که "حدس بزنیم" یک کار چقدر زمان می‌برد. سؤال رایجی مثل این:
«این تسک چند روز طول می‌کشه؟»
اما بیشتر وقت‌ها، این تخمین‌ها بیشتر از اینکه بر پایه درک واقعی باشن، روی امید و حدس بنا شدن. و وقتی کار طبق برنامه پیش نمی‌ره، که خیلی وقت‌ها هم همین‌طوره، تیم‌ها دچار استرس، عجله یا سرزنش می‌شن.
مشکل اینجاست: ما با کار کردن روی محصول مثل یه کار ساده و قابل‌پیش‌بینی برخورد می‌کنیم. درحالی‌که بیشتر کارهای محصول پیچیده هستن و این پیچیدگی تابعی است از فاکتورهای مختلف و بهم مرتبط. و پیچیدگی با برنامه زمانی دقیق پیش نمی‌ره.
کاری که واقعاً کمک می‌کنه، اینه که به‌جای زور زدن برای تخمین زودهنگام، اول سعی کنیم اصل مسئله رو بهتر بفهمیم.
به‌جای اینکه بپرسیم «چقدر طول می‌کشه؟»، می‌پرسیم:
«چقدر این کار رو می‌فهمیم؟»
و اینو از پنج زاویه اصلی بررسی می‌کنیم:
🌟 وضوح دامنه (Domain Clarity)
آیا دقیق می‌دونیم مشکل چیه و کسب‌وکار یا کاربر چی می‌خواد؟
🔄 مثال: پیاده‌سازی فرم لاگین = واضح. طراحی سیستم قیمت‌گذاری برای ۳ منطقه با قوانین در حال تغییر = مبهم.
🌟 وابستگی‌های فنی (Technical Dependencies)
چقدر این کار به سیستم‌های دیگه یا بخش‌های حساس و قدیمی بستگی داره؟
🔄 مثال: اضافه‌کردن یک تولتیپ ساده در UI = راحت. اتصال به API قدیمی یک سیستم ثالث = پیچیده و پرریسک.
🌟 وابستگی‌های بیرونی (External Dependencies)
آیا این تسک به ورودی یا تأیید تیم‌های دیگه، تأمین‌کننده‌ها یا بخش‌هایی مثل حقوقی وابسته‌ست؟
🔄 مثال: به‌روزرسانی مستندات داخلی = مستقل. راه‌اندازی فیچری که نیاز به تأیید حقوقی و هماهنگی با تأمین‌کننده داره = وابسته.
🌟 آشنایی تیم (Team Familiarity)
آیا تیم قبلاً این‌جور کارها رو با همین ابزارها انجام داده؟
🔄 مثال: رفع باگ در اپ اصلی = آشنا. ساخت سرویس جدید با زبانی که تیم بلد نیست = ناشناخته.
🌟 هماهنگی بین‌تیمی (Cross-Team Sync)
آیا این کار رو می‌تونیم کاملاً درون تیم انجام بدیم یا نیاز به هماهنگی و تأیید از جاهای دیگه داره؟
🔄 مثال: تغییر متن دکمه = مستقل. اضافه کردن فیچری که نیاز به تأیید حقوقی، دیزاین و دیتا داره = نیازمند هماهنگی بالا.
با امتیاز دادن به یک تسک بر اساس این ۵ عامل (از پیچیدگی کم تا زیاد)، درک خیلی دقیق‌تری از اونچه قراره انجام بشه به‌دست میاریم. این کمک می‌کنه بفهمیم آیا آماده اجراییم، یا باید اول کشف بیشتری انجام بدیم.
🔍 مثال واقعی:
مکتب‌خانه DDD
@DomainDrivenDesign_ir
در توسعه محصول، اغلب تحت فشاریم که "حدس بزنیم" یک کار چقدر زمان می‌برد. سؤال رایجی مثل این:
«این تسک چند روز طول می‌کشه؟»
اما بیشتر وقت‌ها، این تخمین‌ها بیشتر از اینکه بر پایه درک واقعی باشن، روی امید و حدس بنا شدن. و وقتی کار طبق برنامه پیش نمی‌ره، که خیلی وقت‌ها هم همین‌طوره، تیم‌ها دچار استرس، عجله یا سرزنش می‌شن.
مشکل اینجاست: ما با کار کردن روی محصول مثل یه کار ساده و قابل‌پیش‌بینی برخورد می‌کنیم. درحالی‌که بیشتر کارهای محصول پیچیده هستن و این پیچیدگی تابعی است از فاکتورهای مختلف و بهم مرتبط. و پیچیدگی با برنامه زمانی دقیق پیش نمی‌ره.
کاری که واقعاً کمک می‌کنه، اینه که به‌جای زور زدن برای تخمین زودهنگام، اول سعی کنیم اصل مسئله رو بهتر بفهمیم.
به‌جای اینکه بپرسیم «چقدر طول می‌کشه؟»، می‌پرسیم:
«چقدر این کار رو می‌فهمیم؟»
و اینو از پنج زاویه اصلی بررسی می‌کنیم:
🌟 وضوح دامنه (Domain Clarity)
آیا دقیق می‌دونیم مشکل چیه و کسب‌وکار یا کاربر چی می‌خواد؟
🔄 مثال: پیاده‌سازی فرم لاگین = واضح. طراحی سیستم قیمت‌گذاری برای ۳ منطقه با قوانین در حال تغییر = مبهم.
🌟 وابستگی‌های فنی (Technical Dependencies)
چقدر این کار به سیستم‌های دیگه یا بخش‌های حساس و قدیمی بستگی داره؟
🔄 مثال: اضافه‌کردن یک تولتیپ ساده در UI = راحت. اتصال به API قدیمی یک سیستم ثالث = پیچیده و پرریسک.
🌟 وابستگی‌های بیرونی (External Dependencies)
آیا این تسک به ورودی یا تأیید تیم‌های دیگه، تأمین‌کننده‌ها یا بخش‌هایی مثل حقوقی وابسته‌ست؟
🔄 مثال: به‌روزرسانی مستندات داخلی = مستقل. راه‌اندازی فیچری که نیاز به تأیید حقوقی و هماهنگی با تأمین‌کننده داره = وابسته.
🌟 آشنایی تیم (Team Familiarity)
آیا تیم قبلاً این‌جور کارها رو با همین ابزارها انجام داده؟
🔄 مثال: رفع باگ در اپ اصلی = آشنا. ساخت سرویس جدید با زبانی که تیم بلد نیست = ناشناخته.
🌟 هماهنگی بین‌تیمی (Cross-Team Sync)
آیا این کار رو می‌تونیم کاملاً درون تیم انجام بدیم یا نیاز به هماهنگی و تأیید از جاهای دیگه داره؟
🔄 مثال: تغییر متن دکمه = مستقل. اضافه کردن فیچری که نیاز به تأیید حقوقی، دیزاین و دیتا داره = نیازمند هماهنگی بالا.
با امتیاز دادن به یک تسک بر اساس این ۵ عامل (از پیچیدگی کم تا زیاد)، درک خیلی دقیق‌تری از اونچه قراره انجام بشه به‌دست میاریم. این کمک می‌کنه بفهمیم آیا آماده اجراییم، یا باید اول کشف بیشتری انجام بدیم.
🔍 مثال واقعی:
فرض کن تیم قراره فیچری اضافه کنه به اسم «پشتیبانی از یک پلن جدید پرداخت».نتیجه:
در ظاهر ساده به‌نظر می‌رسه، ولی وقتی تیم از زاویه این ۵ عامل نگاه می‌کنه، متوجه می‌شه:
- منطق قیمت‌گذاری مشخص نیست → (وضوح دامنه پایین).
- باید به سیستم یک تأمین‌کننده خارجی وصل بشه → (وابستگی زیاد).
- تیم قبلاً با سیستم پرداخت کار نکرده → (آشنایی کم).
این کار کوچیک نیست، و باید اول یک فاز کشف (Discovery) براش انجام بدن.
این روش کمک می‌کنه تیم‌ها هوشمندتر برنامه‌ریزی کنن، غافلگیر نشن، و از قبل در مورد ریسک‌ها صحبت کنن — نه وقتی خیلی دیر شده.
مکتب‌خانه DDD
@DomainDrivenDesign_ir
👍2