📣 اطلاع رسانی سومین جلسه آنلاین DDD Plus

جلسه سوم DDD Plus این هفته جمعه از ساعت ۱۸:۰۰ الی ۱۹:۰۰ برگزار خواهد شد.

توی این جلسات آنلاین، در مورد چالش‌های مطرح شده تحت عنوان DDD Plus با همدیگر به بحث و تبادل نظر می‌پردازیم و سعی می‌کنیم از همدیگر یاد بگیریم.

دست به دست هم اگر کنید که به اطلاع افراد علاقمند به شرکت در جلسه برسه، کمال تشکر رو دارم

لینک ثبت‌نام در رویداد:
https://lu.ma/jo0n3suj

💬 گروه بحث و تبادل نظر:
https://t.me/DomainDrivenDesignGroup

💬 کانال مکتب‌خانه DDD:
https://t.me/DomainDrivenDesign_ir

⭕️استخدام توسعه‌دهنده/مهندس نرم‌افزار

ما در حال ساخت تیم‌های توسعه‌ی Product Focused هستیم که رویکرد Domain-Driven Design را در توسعه‌ی محصول در پیش می‌گیرند.

‎مایندست تیم‌های توسعه مبتنی بر کیفیت است و از همین رو تست اتوماتیک نرم‌افزار یک فرهنگ غالب در تیم‌های توسعه خواهد بود.

لطفا رزومه‌تون رو به آدرس ایمیل زیر ارسال بفرمائید:
[email protected]

💡  چالش شماره 12 DDD Plus

🔴 پیش‌زمینه:
شما در شرکت MyPayroll.Com به عنوان توسعه‌دهنده محصول مشغول توسعه محصول حقوق و دستمزد هستید. این سیستم به سازمان‌ها این امکان را می‌دهد که حقوق کارمندان خود را بر اساس فاکتورهای مختلفی از جمله نوع همکاری ساعتی، ماهانه یا مشاوره، کارکرد کارمندان، پاداش و عیدی و فاکتورهای مشابه دیگر محاسبه کند.

🔴 سناریو:
قراردادهای همکاری فی‌ما‌بین کارمندان و یک سازمان می‌تواند حالت‌های مختلفی از همکاری را به خود بگیرد. به عنوان مثال شما ممکن است با مجموعه‌ای بصورت تمام وقت، یا بصورت مشاوره یا حتی ساعتی همکاری کنید.
بسته به نوع قرارداد همکاری شما، برخی آیتم‌های مهم کارکردی برای شما ممکن است مهم باشد یا نباشد. مثلا وقتی شما قرارداد تمام وقت با سازمانی داشته باشید، در طول ماه ۲٫۵ روز مرخصی استحقاقی یا ۱۶ ساعت مرخصی ساعتی استحقاقی خواهید داشت. همچنین آیتم‌های پاداشی از جمله عیدی به شما تعلق می‌گیرد.
در مقابل در صورتی که نوع همکاری شما ساعتی باشد، موارد بالا برای شما محلی از اعراب ندارند.

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

این مورد نیز توسط مدیر محصول عنوان شده که: انواع استخدام در هر سازمانی با سازمان دیگر متفاوت هست.

🔴 صورت مسئله:
با در نظر گرفتن سناریوی بالا و اینکه شما در حال پیاده‌سازی آیتم نوع استخدام هستید به سوالات زیر پاسخ دهید:
🔶 چه چالشی در نوع بیان مسئله در بالا می‌بینید؟
🔶 دومین این مسئله را طراحی کنید؟
🔶 مواردی که در سناریوی بالا گفته شد چه تاثیری در طراحی شما دارد؟
🔶 باندد کانتسک(ها) را در مسئله بالا طراحی کنید؟

لینک به چالش شماره 12:

http://domaindrivendesign.ir/ddd-plus-12

💬گروه بحث و تبادل نظر در مورد این چالش:
https://t.me/DomainDrivenDesignGroup

هشتگ‌:
#DDDP | #DDD_Plus | #dddp12

https://t.me/DomainDrivenDesign_ir

مکتب‌خانه DDD

چالش دوازدهم DDD Plus | مکتب‌خانه DDD

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

با سلام خدمت همه عزیزان و همراهان گرامی

لطفا جهت شرکت در برنامه از طریق لینک زیر اقدام بفرمائید.

https://lu.ma/3odgar5o

💬 گروه بحث و تبادل نظر:
https://t.me/DomainDrivenDesignGroup

💬 کانال مکتب‌خانه DDD:
https://t.me/DomainDrivenDesign_ir

lu.ma

DDD Plus #1 · Luma

DDD Plus #1 online meetup. Hosted by DomainDrivenDesign.ir Discussing together the real challenges of DDD

*📣 اطلاع رسانی اولین جلسه آنلاین DDD Plus*

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

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

تا به امروز 11 چالش DDD Plus رو مطرح کردیم.

قصد داریم هر هفته بصورت آنلاین در مورد یکی از چالش‌های مطرح شده به بحث و تبادل نظر بپردازیم.

اولین جلسه این هفته جمعه ساعت 18 الی 19 برگزار می‌کنیم.

💬 گروه بحث و تبادل نظر:
https://t.me/DomainDrivenDesignGroup

💬 کانال مکتب‌خانه DDD:
https://t.me/DomainDrivenDesign_ir

💡  چالش شماره 11 DDD Plus
کمسیون فروش توسط همکاران B2B را چگونه در یک مسئله پیچیده مثل قیمت‌ گذاری اتاق‌های یک هتل دخیل می‌کنید؟
آیا قیمت گذاری فروش B2B نیازمند یک Bounded Context جداگانه است؟
مسئله fair بودن فروش را این سناریوها به چه صورت هندل می‌کنید؟

در این چالش DDD Plus این سوالات بالا را به چالش خواهیم کشید:

🔴 پیش‌زمینه:
در این چالش نیز، شما هنوز در شرکت MyHotels.Com مشغول هستید و روی فروش هتل کار می‌کنید.

🔴 سناریو:

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

🔴 صورت مسئله:
قیمت گذاری، همانگونه که در بالا نیز اشاره شد، تابع فاکتورهای زیادی است. از طرف دیگر قیمت یک اتاق به دلیل تغییر نرخ ارزها، و همچنین عرضه و تقاضا و عوامل دیگر، نیز ممکن است دستخوش تغییر شود. مثلا قیمت یک اتاق سینگل در هفته اول ۱۰ دلار، هفته دوم ۱۱ دلار و هفته سوم ۹ دلار باشد.
شما قیمت گذاری را با تمام پیچیدگی‌های عنوان شده در بالا، در چالش شماره قبل حل کردید.
در اینجا فرض کنید، برای فروش B2B و فروش به آژانس‌های همکار قصد قیمت گذاری هتل را دارید. با در نظر گرفتن این مورد به سوالات زیر پاسخ دهید:

🔶 قیمت نهایی یک اتاق ممکن است برای همکاران B2B بصورت کمیسیون و درصدی از فروش اعمال شود. به این معنی که قیمت اتاق سینگل توسط شما ۱۰ دلار تعیین می‌شود، و در صورتی که این اتاق توسط آژانس همکار شما فروش رفته باشد، برای مشتری همان ۱۰ دلار حساب می‌شود، و درصدی از ۱۰ دلار، مثلا ۲درصد از فروش آن به آژانس همکار داده می‌شود. این موضوع را چطور در قیمت گذاری لحاظ می‌کنید؟
🔶 ممکن است شرکت شما فقط کف قیمت اتاق‌ها را تعیین کند، و هر آژانس اجازه داشته باشد که با درصدی بالاتر آن اتاق رو به فروش برساند. مثلا شما قیمت یک اتاق سینگل را ۱۰ دلار تعیین کردید، حال اگر آژانسی آن اتاق را ۱۱ دلار بفروشد، ۱ لار به آن آژانس داده می‌شود. این سناریو رو چطور مدلسازی می‌کنید؟
🔶 برای میزان فروش هر آژانس همکار یک ظرفیت تعیین کنید تا از فروش تمامی ظرفیت هتل توسط یک آژانس جلوگیری کنید؟
🔶 تعداد آژانس‌های همکار ممکن است بسیار زیاد باشد. آیا این موضوع در مسئله‌های مطرح شده در بالا تاثیری خواهد داشت؟

لینک به چالش شماره 11:

http://domaindrivendesign.ir/ddd-plus-11

💬گروه بحث و تبادل نظر در مورد این چالش:
https://t.me/DomainDrivenDesignGroup

هشتگ‌:
#DDDP | #DDD_Plus | #dddp11

https://t.me/DomainDrivenDesign_ir

مکتب‌خانه DDD

چالش یازدهم DDD Plus | مکتب‌خانه DDD

در چالش شماره 11 DDD Plus مشاهده خواهیم کرد که قیمت گذاری فروش B2B و سفارشی سازی یک مسئله پیچیده مثل قیمت‌گذاری اتاق‌های یک هتل چگونه می‌تواند طراحی دومین مسئله را تحت تاثیر قرار دهد

In CQRS:

Query side of Eventual Consistency is technical oriented.
but
Command side of it must be BUSINESS oriented.