📣چالش پنجم DDD Plus

نوشتن تست اتوماتیک بخصوص برای سرویس‌هایی که بخش اعظمی از عملیات و داده‌های اساسی خود رو از سرویس‌های خارجی دریافت می‌کنند کار ساده‌ای نیست۰ چالش این هفته همین موضوع رو مورد بررسی و بحث قرار میده۰

🔔پیش‌زمینه:
شما در شرکت Flight.Com مشغول توسعه‌ی اپلیکیشنی برای فروش بلیت هواپیما هستید. شما پروازهای مختلف را از یک API که توسط شرکت FlightProvider.Com می‌باشد، گرفته و به کاربران نمایش می‌‍دهید. FlightProvider.Com یک API به شما داده است که می‌توانید تاریخ پرواز، مبدا و مقصد مورد نظر را داده و لیستی از پروازهایی که در آن روز از مبدا مورد نظر شما به سمت مقصد می‌روند را به شما بر می‌گرداند. شما این لیست را به کاربران نمایش داده و کاربران از بین لیست پروازها یکی را انتخاب ‌می‌کند.

📍سناریو:
همانطور که در تصویر بالا مشاهده می‌کنید API شرکت FlightProvider.Com تمامی مسیرهایی که از پاریس شروع شده و به آمستردام ختم می‌شوند را به شما بر‌ می‌گرداند. از شما خواسته شده است که پروایدر NewFlightProvider.Ir را به لیست پروایدرهای پرواز اضافه کنید.


❓صورت مسئله:
سیستم در حال حاضر هیچگونه تست پذیرش(Acceptance test) و تست دومین ندارد.
🔶شما باید قبل از پیاده‌سازی پروایدر جدید تست پذیرش و تست دومین را برای هر دو پروایدر برای سناریوهای زیر بنویسید.
🔶برای سناریو دریافت لیست پروازها تست پذیرش بنویسید؟
🔶برای سناریو رزرو یک flight یک تست پذیرش بنویسید؟
🔶دومین- Donain مسئله را در حالت رزرو و همچنین لیست پروزاها طراحی و پیاده‌سازی کنید؟
🔶فرض کنید این مسئله را بصورت CQRS پیاده‌سازی کنید. در اینحالت به سوالات بالا پاسخ دهید؟


لینک به چالش هفته پنجم:
https://domaindrivendesign.ir/ddd-plus5/

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

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

https://t.iss.one/DomainDrivenDesign_ir

Time, Change and Uncertainty in Software Architecture

Podcast with Barry O’Reilly- Author of the Residuality book

In this podcast Len Epp (co-founder of Leanpup) interviewed with Barry on his thought about the theory and philosophy of Residuality and how it’s related to software architecture.


About the Book

This book provides an easy introduction to the subject of Residuality Theory. A revolutionary new way to think about software architecture that fuses Software Engineering, Complexity Science, and Philosophy to provide an entirely new way to think about the problem of architecting software solutions.

About the Author

Barry is an architect with 25 years of experience. He has held Chief Architect positions within Microsoft as well as being the global lead for Solutions Architecture Community there. He is currently finsihing of a PhD in Complexity Science and Software Design.

https://youtu.be/_wS4BKMOLKo?si=2S_2icQOS9cwbNYA

چالش ششم DDD Plus

💡 پیشنهاد می‌کنم اگر محصولچی یا توسعه دهنده یا معمار سیستم هستید چالش این هفته‌ی DDD Plus را دنبال کنید.


چالش DDD Plus6 یک مسئله بسیار جذاب و رایج را در برمی‌گیرد. این چالش از مسائل اساسی مانند team topology، یکپارچه‌سازی و مالکیت محصول/سرویس(product ownership) تشکیل شده است.

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

🔴سناریو:
شما در حال توسعه دو ماژول جدید برای این اپ هستید.
یک ماژول ads که به مدیر بازاریابی شما این امکان را می‌دهد که بر اساس قراردادی که با کافه بسته است، آن کافه را در بالای لیست نمایش دهد.

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

فرض کنید یک تیم مسئول توسعه‌ی تعریف منو برای هر کافه و ثبت سفارش است. تیم دیگری مسئول توسعه‌ی ماژول ads است. تیم دیگری هم بر روی توسعه ماژول CoffeeTime کار می‌کند.

🔴صورت مسئله:
همانطور که متوجه شده‌اید نمایش لیست کافه‌ها در صفحه اول اپ شما، متاثر از پارامترهای مختلفی است:
آیا کافه A دارای امتیاز بالا یا پایین ست؟
آیا قرارداد ads با ما بسته است؟
آیا در طرح CoffeeTime فعال مشارکت دارد یا خیر؟

با توجه به شرایط بالا به این سوالات پاسخ دهید:
🔶مسئله نمایش لیست کافه‌ها در صفحه اول اپ را به کدام تیم واگذار می‌کنید؟
🔶در صورتی که این مسئولیت به هیچکدام از تیم‌های ads و CoffeeTime داده نشود، تیم‌های ads و CoffeeTime چگونه با این تیم همکاری می‌کنند؟
🔶مالک/مدیر محصول این اپیک شرح داده شده در بالا بر عهده کیست؟
🔶چگونه از اعمال سیاست‌های نمایش لیست کافه‌ها(با توجه به پیچیدگی‌هایی که در بالا شرح داده شد) مطمئن می‌شوید؟
🔶 تست‌های پذیرش برای اطمینان از صحت عملکرد اپ را بنویسید؟

لینک به چالش هفته ششم:

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

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

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

https://t.iss.one/DomainDrivenDesign_ir

📣 چالش هفتم DDD Plus

📝 پیش‌زمینه:
شما در حال توسعه یک social media app‌ برای شرکت SayHelloToTheWonderfulWorld dot Com 😍هستید. در این app افراد می‌توانند تجارب سفر خود را با دیگران به اشتراک بگذارند. ویژگی‌های متداول یک social media app در این app که شما در حال توسعه آن هستید وجود دارد. فعالیت‌هایی از جمله دنبال کردن و لایک کردن و چت کردن.

📍 سناریو:
شما در حال پیاده‌سازی امکان اشتراک گذاری پست در این app هستید. از شما خواسته شده است که در نسخه‌اول این برنامه تمامی پست‌ها‌ی کاربران باید قبل از انتشار توسط کاربر admin! تائید شود. همانطور که می‌توان متصور شد، هر کاربر ممکن است پس از انتشار یک پست ویرایشی در آن ایجاد کند. پست‌های ویرایش شده نیز باید قبل از انتشار توسط کاربر admin تائید شوند.
یک استثنا در اینجا وجود دارد. اگر پست توسط تیم تولید محتوای شرکت  SayHelloToTheWonderfulWorld dot Com  ایجاد شود، یا بعدا ویرایش شود، نیازی به confirm شدن پیش از انتشار را ندارد.

❓ صورت مسئله:
با توجه به سناریوی بالا، به سوالات زیر پاسخ دهید:
🔶 پست را مدل‌سازی و پیاده کنید؟
🔶 چگونه بین پست‌هایی که نیاز به تائید دارند و آنهایی که نیاز به تائید ندارند، تفکیک قایل می‌شوید؟
🔶 داستان کاربری و شرایط پذیرش را برای سناریوهای مطرح شده در بالا بنویسید؟
🔶 چه سناریوهایی تستی برای این مسئله می‌توانید طراحی کنید ؟
🔶 صورت مسئله تائید و رد یک پست را چطور مدل می‌کنید؟
🔶 مسئله ویرایش‌های یک پست را با توجه به اینکه تغییرات در یک پست قبل از انتشار نیاز به تائید دارد را چگونه مدل می‌کنید؟ در نظر داشته باشید که یک پست پس از انتشار اولیه، ممکن است چندین بار ویرایش شود؟
🔶 چالش بعدی DDD Plus سناریوی دیگری از همین صورت مسئله را زیر ذره‌بین خواهد برد.


لینک به چالش هفته هفتم:

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

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

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

https://t.iss.one/DomainDrivenDesign_ir

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

چند مسئله مهم، مجزا ولی متاثر از هم در بالا مطرح شد:
💡زبان، فکر کردن، تکامل، پیشرانه و طراحی.

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

پیشنهاد میکنم این سخنرانی جالب از آقای David Sumpter رو که در دانشگاه آکسفورد ارائه شده است ببینید.

https://www.youtube.com/watch?v=PPCfDe8TfJQ


به ما بپیوندید
@DomainDrivenDesign_ir

💡 چالش شماره 8 DDD Plus
https://domaindrivendesign.ir/ddd-plus-8

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

این مسئله بخصوص از این جهت حائز اهمیت است که اکثر اوقات ما تمامی این اطلاعات را بصورت همزمان از مالک/مدیر محصول نمی شنویم. و ممکن است در طی چند اسپرینت(گاها غیر متوالی) با این موارد مواجه شویم.

این سناریو سناریویی بسیار متداول در توسعه یک محصول است. بخصوص هنگامی که با ویژگیهایی از محصول سروکار داریم که جنبه qualitative دارند و مالک/مدیر محصول نیازمند سطح زیادی از تجربه گرایی در طراحی و دست یابی به قابلیت نهایی محصول است.

در اصل باید اینطور بگم که این یکی از abilityهای مهم در طراحی محصول به شمار می رود که شما به عنوان توسعه دهنده، طراح یا معمار سیستم میتوانید به محصولچیهای خود بدهید یا از اونها دریغ کنید!

🔴 پیش‌زمینه:

شما در حال توسعه یک social media app‌ برای شرکت SayHelloToTheWonderfulWorld.Com 😍هستید.

🔴 سناریو:

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

مثلا شما شخص A را دنبال می‌کنید. شخص A شخص B را دنبال می‌کند. در نتیجه برنامه ممکن است شخص B را به شما جهت فالو کردن پیشنهاد دهد. همانطور که متوجه شدید در این مثال برنامه یک لول در بین افرادی که شما دنبال کرده‌اید جلو رفته است. اما می‌توانیم متصور شویم که این سطح می‌تواند طولانی تر نیز باشد. مثل شما A را دنبال می‌کنید. A شخص B و B شخص C و در نهایت در سطح nام ممکن است شخص Y شخص Z را دنبال می‌کند. در نتیجه ممکن است از شما خواسته شود که برنامه شخص X را نیز در نهایت به شما پیشنهاد دهد.

همچنین این دنبال کردن دارای تاثیرات جانبی مهم دیگری نیز می‌باشد. به عنوان مثال در صفحه هوم برنامه از شما خواسته شده است که لیستی از تجربه‌های سفر را به نحوی به کاربر نشان دهید، که تجارب به اشتراک گذاشته شده توسط افرادی که شما دنبال کرده‌اید در اولویت قرار گیرد. به عنوان مثال در صورتی که ۲۰ نفر در برنامه شما تجارب خود را به اشتراک گذاشته باشند و شما ۵ نفر از آنها را دنبال کرده باشید، در صفحه اول برنامه وقتی وارد اپ می‌شوید، تجاربی که این ۵ نفر به اشتراک گذاشته‌اند در بالای لیست قرار می‌گیرد. همانند مثال بالا، سایر افرادی که شما مستقیما دنبال نمی‌کنید ولی توسط ۵ نفری که شما دنبال می‌کنید، در صورتی که تجربه‌ای را به اشتراک گذاشته باشند، اولویت بالاتری نسبت به سایر افراد؛ از نقطه نظر نمایش تجارت به اشتراک گذاشته شده آنها برای شما در صفحه اول، خواهند داشت.


🔴 صورت مسئله:

با در نظر گرفتن سناریوی بالا، و اینکه شما در حال پیاده‌سازی ویژگی دنبال کردن در این app هستید، به موارد زیر پاسخ دهید:

🔶 داستان(های) کاربری مربوط به سناریوهای بالا را بنویسید؟
🔶 شرایط پذیرش را برای داستان(های) کاربری خود بنویسید؟
🔶 برای سناریوهای بالا، سناریوهای تست پذیرش که منجر به اطمینان از صحت عملکرد برنامه شما می‌شود را بنویسید؟
🔶 مسئله فالو کردن کاربران، را مدل کنید؟
🔶 چگونه از وجود خاصیت evovability را برای مسئله بالا که با طیف وسیعی از ویژگی‌های qualitative سرو کار دارد، در مدلی که برای این مسئله ارائه دادید مطمئن می‌شوید؟
🔶 نیازمندیهای ارائه شده در بالا، در طیف نیازمندیهایی هستند که به شدت تغییر پذیری هستند. بدین معنی که با گذشت زمان و دریافت اطلاعات بیشتر از دومین و نحوه‌ی استفاده کاربران از برنامه، امکان تغییر در نیازمندیهایی که جنبه quantitative دارند وجود دارند. در همچنین مواقعی چه استراتژی‌ای در توسعه برنامه در پیش می‌گیرید؟

لینک به چالش هفته هشتم:

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

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

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

https://t.iss.one/DomainDrivenDesign_ir

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

🔴 پیش‌زمینه:

شما در شرکت MyHotels.Com مشغول کار هستید. شما در حال پیاده‌سازی فیچری هستید که در آن از شما خواسته شده است که یک هتل را برای فروش بتوان در سیستم تعریف کرد.

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

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

همچنین هر هتل دارای یکسری طبقه است که در هر طبقه یکسری اتاق وجود دارد. کاربری طبقات با همدیگر متفاوت می‌باشد. مثلا طبقه اول/همکف ممکن است دارای کاربری لابی باشد. یا مثلا طبقه چهارم دارای کاربری رستوران باشد.

نوع اتاق‌های هر طبقه نیز با یکدیگر متفاوت می‌باشد. مثلا اتاق‌ها ممکن است سینگل، دبل یا توئین باشد. مساحت هر نوع اتاق نیز می‌تواند متفاوت باشد. به عنوان مثال اتاق سینگل ممکن است هم شامل اتاق‌های ۴۰ متری و هم اتاق‌های ۵۰ متری باشد. از نظر امکاناتی نیز اتاق‌ها ممکن است با یکدیگر متفاوت باشند. به عنوان نمونه یک اتاق دبل ممکن است هم بصورت استاندارد ارائه شود و هم بصورت سوپریور(Superior )– اتاق سوپریور همانطور که از نامش پیداست دارای خدماتی ویژه‌تر نسبت به سایر اتاق‌ها هستند.-


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


🔶 هتل شامل مشخصات هتل، تصاویر، طبقات و اتاق‌های یک هتل را مدل کنید؟
🔶 نزدیکی هتل به مراکز مهم تفریحی، دسترسی‌های هتل، نزدیکی به سفارت و … را مدل کنید؟
🔶 یک هتل ممکن است دارای ۵۰ اتاق و هتل دیگر ممکن است دارای ۸۰۰ اتاق باشد. دانستن این مسئله چه تاثیری در مدلسازی شما دارد؟
🔶 ظرفیت مسافرپذیری هتل را چگونه مدل می‌کنید؟ مثلا سوالاتی از قبیل اینکه هتل دارای چند اتاق است، چه تعداد از اتاق‌های هتل در طبقه دوم و چه تعداد در طبقه اول قرار دارد؟
🔶 سناریوهای تست پذیرش و تست دومین را برای موارد بالا بنویسید و پیاده‌سازی کنید؟


لینک به چالش هفته نهم:

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

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

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

https://t.iss.one/DomainDrivenDesign_ir

💡 چالش شماره 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