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

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

🔴 سناریو:
در نظر داشته باشید که مسئله‌ای که در ادامه مشاهده می‌کنید فرم ساده‌ شده‌ی صورت مسئله مدل کردن هتل می‌باشد

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

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


🔴 صورت مسئله:

با توجه به صورت مسئله بالا به سوالات زیر پاسخ دهید:

🔶 چه تست‌های SBE (Scenario-Based Testing) می‌توان طراحی کرد تا رفتار کلی سیستم قیمت‌گذاری را به درستی بررسی کند؟ این تست‌ها چه موارد مهمی را پوشش می‌دهند؟
🔶 چه تست‌های پذیرش (Acceptance Tests) می‌توان نوشت تا مطمئن شد که قیمت‌گذاری اتاق‌ها به درستی محاسبه می‌شود؟ این تست‌ها چه سناریوهایی را پوشش می‌دهند؟
🔶 امکانات اضافی هر اتاق را چگونه می‌توان مدل‌سازی کرد؟ آیا باید یک لیست از امکانات در HotelRoom نگهداری شود یا می‌توان از یک مدل دیگر استفاده کرد؟
🔶 چگونه می‌توان قیمت پایه هر HotelRoom را محاسبه کرد؟ آیا این قیمت پایه باید به صورت یک فیلد در کلاس HotelRoom نگهداری شود؟
🔶 چه روشی برای محاسبه تغییرات قیمت بر اساس تقاضا و موجودی اتاق‌ها وجود دارد؟ آیا این محاسبات باید در کلاس HotelRoom انجام شود یا در یک کلاس جداگانه؟
🔶 چگونه می‌توان قیمت نهایی هر HotelRoom را با در نظر گرفتن تمام عوامل مؤثر (نوع اتاق، موقعیت، امکانات اضافی و تغییرات تقاضا) محاسبه کرد؟


چالش بعدی DDD Plus در مورد جنبه‌ی دیگری از همین صورت مسئله است.😉
لینک به چالش هفته دهم:

https://domaindrivendesign.ir/ddd-plus-10

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

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

https://t.iss.one/DomainDrivenDesign_ir

📖 آموزش Event Sourcing | بخش هشتم

💡بخش هشتم: ویرایش ایونت، آری یا خیر؟

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

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

توی این پست به این موضوعات پرداختم. می‌تونید جواب این سوالات رو توی لینک زیر مشاهده بفرمایید:

https://domaindrivendesign.ir/event-sourcing-08-editing-event/



EventSourcing | Part 8

هشتگ:
#EventSourcing #ایونت_سورسینگ #آموزش_event_sourcing

@DomainDrivenDesign_ir

In CQRS:

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

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

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

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

🔴 سناریو:

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

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

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

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

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



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

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

https://t.iss.one/DomainDrivenDesign_ir

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

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

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

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

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

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


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

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

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

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

https://lu.ma/3odgar5o



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

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

با تشکر از همه عزیزانی که استقبال کردند.
ظرفیت ثبت‌نام تکمیل شده 😍 ولی می‌تونید ثبت‌نام رو انجام بدید و به ویت لیست اضافه بشید

تعداد زیادی از عزیزان پشت در موندن 😅 با توجه به زمان محدودی که داشتیم و اینکه دیر اطلاع رسانی کردیم تصور میشد عزیزان کمتری شرکت کنند

از همگی تشکر میکنم بابت استقبال.😍❤️

اولین جلسه هست و قطعا کم و کسری و نا بلدی زیادی داریم. از همینجا از همگی عذرخواهی میکنیم. تا جایی که ظرفیت اجازه بده حتما با افتخار در خدمت همگی دوستان هستیم تا از همدیگه یاد بگیریم و کسب و تجربه کنیم.

بقول اریک اونس:

Let's Practice DDD together.

ممنون از همگی عزیزانی که توی جلسه شرکت کردند.❤️🌹

امیدواریم که جلسه مفیدی بوده باشه.

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

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

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

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

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

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


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



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

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



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

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

https://t.iss.one/DomainDrivenDesign_ir

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

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

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


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


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

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

ظرفیت این رویداد تکمیل شده😍

از همه عزیزانی که ثبت‌نام کردند نهایت تشکر رو داریم.

متاسفانه بدلیل فرمت جلسات DDD Plus، ظرفیت برگزاری رویدادهای DDD Plus محدود هست.

🔹 ظرفیت waitlist هنوز پر نشده و می‌تونید ثبت‌نام بفرمایید.

رویداد دوم DDD Plus تا ساعاتی دیگر آغاز می‌شود. بی‌صبرانه مشتاق دیدار شما عزیزان هستیم😍

https://t.iss.one/DomainDrivenDesign_ir

a Good and simple argument on Whether or not TDD is a rocket-science?
by Kent Beck

TDD, imposes constraints on motion between program states.

📖Read the article: https://tidyfirst.substack.com/p/tdd-is-not-hill-climbing

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

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

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

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

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


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

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

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

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

خیلی خیلی مشتاقیم شما رو هم توی جمعمون ببینیم😍

An interview with Jeff Weinstein on Lenny podcast.

Jeff Weinstein is a product lead at Stripe where he helped grow their payment APIs to hundreds of billions in volume and transformed the way founders start companies into a few simple clicks with Atlas. Prior to Stripe, Jeff led several startups and sold companies to Groupon and Box.

He’s known for his customer obsession, craft, quality, and building beloved products businesses rely on.

In the conversation, they discuss:
🔸 The power of customer obsession and how to operationalize it in your product development process
🔸 How to pick the right metrics and use them to drive impact
🔸 Techniques for getting things done at big companies
🔸 A group practice Jeff started to uplevel product craft, called Study Group
🔸 The story behind Stripe Atlas and its mission to increase entrepreneurship globally
🔸 Lessons from working with the founders of Stripe

Some key takeaways:

1. Before focusing on craft, experience, or quality, you need to ensure that you’re solving a burning problem for someone. One of Jeff’s first companies went offline for hours and not a single customer reached out—that’s when he knew they didn’t have product-market fit. If users aren’t clamoring for your product, you’re not solving a real need. Think about it this way: solving the core problem is the main course; perfecting craft, UX, and quality are the desserts.

2. Jeff emphasizes the “go, go, go ASAP + optimistic, long-term compounding” approach: seize opportunities with enthusiasm while maintaining a strategic focus on long-term growth. Stripe’s evolution in global payment methods exemplifies how combining rapid execution with thoughtful, enduring strategies leads to significant, sustainable results.

3. When customers take the time to complain or provide feedback, treat it as a gift. Respond promptly to complaints or feedback, even if it means interrupting other tasks, as it creates a direct signal between you and the customer. This responsive attitude can lead to a loyal customer base and product improvement.

4. Ask customers to describe what a “bad day” looks like when using your product, and then find ways to track metrics around those frustrations. You don’t necessarily need to solve every issue right away, but having this problem library builds awareness to inform your roadmap.

Listen to the podcast: 👇

https://youtu.be/qbZQjprTnrU

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


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

پیشنهاد می‌کنم چالش این هفته را بصورت کامل از لینک زیر مطالعه کنید:


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

https://domaindrivendesign.ir/ddd-plus-13


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

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

https://t.iss.one/DomainDrivenDesign_ir