DDD and LLMs
By Eric Evans
At Explore DDD 2024

Abstract questions Eric talked about:

⭕️How large language models (LLMs) might be a tool for cultivating deep domain understanding?

⭕️Beyond the hype, how they might be used in our work of developing software that helps people operating in complex domains?

Highly recommended this very insightful and thoughtful 🧐, must viewed talk on the hype created by LLMs


https://m.youtube.com/watch?v=Tll_suxZluk


https://t.iss.one/DomainDrivenDesign_ir

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

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

https://domaindrivendesign.ir/ddd-plus

چالش اول DDD Plus

اولین چالش DDD Plus رو توی سال جدید-۱۴۰۳، با صورت مسئله‌ای از آخرین ورکشاپ سال ۱۴۰۲ (ورکشاپ Specification by Example)شروع می‌کنیم.

🔔 پیش زمینه:

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

📍 سناریو:
در جلسه ایونت استورمینگ که برای رسیدن به تصویر بزرگ این دومین برگزار شد، کارت زیر توسط یکی از مشارکت‌کنندگا روی دیوار پارک شد:


بعد از اون بین افراد در مورد صورت مسئله‌ی این کارت بحث‌هایی پیش آمد.

سوالاتی از جمله موارد زیر:
چرا ۳۰ روز؟
بهتر نیست ۱۵ روز باشه؟
این ۳۰ روز باید پشت سر هم باشد؟
اصلا روتین چیه؟
روتین با چیزهایی تکراری قبلی چه فرقی داشت؟

❓ صورت مسئله:
با توجه به صورت مسئله مطرح شده در بالا:
⬅ فکر می‌کنید این کارت و البته user story مربوط به اون چه مسئله یا چالشی ممکنه داشته باشه؟
⬅ سوالات مطرح شده در بالا به نظر شما سوالات مناسبی بودند؟
⬅ اگر شما بودید چطور با این مسئله مواجه می‌شدید؟
⬅ یک user story برای این مسئله بنویسید.

لینک به صورت مسئله هفته اول:

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

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

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

https://t.iss.one/DomainDrivenDesign_ir

برای بحث و تبادل نظر در مورد چالش‌های DDD Plus توی این گروه تلگرامی می‌توانید عضو بشید:

https://t.iss.one/AgileSoftwareDiscourse

📣 چالش دوم DDD Plus


در چالش این هفته‌ی DDD Plus که شماره‌ی دوم این سری از چالش‌ها است، سراغ مدلسازی در DDD خواهیم رفت. در این شماره یک سناریو پیچیده و جالب را زیر ذره‌بین خواهیم برد.

🔔 پیش زمینه:
فرض کنید به عنوان توسعه‌دهنده بر روی یک سیستم ERP مشغول به کار هستید. مفهوم “Product” یک مفهوم پایه‌ای و بسیار مهم در سیستم‌های ERP محسوب می‌شود که بک‌بن بسیاری از ماژول‌های یک سیستمERP را شامل می‌شود. به عنوان مثال در تمامی ماژول‌های فروش، انبار، تامین کالا، تولید، توزین و… مفهوم product نقش بسیار پررنگی بازی می‌کند. به عنوان مثال سیستم فروش بر پایه فروش محصول سوار شده است. ماژول انبار بر پایه مدیریت موجودی product بنا نهاده شده است. و یا سیستم تامین جهت مدیریت سفارشات و خرید product از تامین کنندگان توسعه داده می‌شود.

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

📍 سناریو:
فرض کنید مالک محصول با داستان کاربری زیر سراغتان می‌آید:
As a Sales Manager, I want the ERP system to provide a comprehensive and streamlined product modeling capability across the Sales, Inventory, and Purchase Order modules, ensuring accurate stock management, pricing consistency, and efficient procurement processes.


❓صورت مسئله:
با توجه به سناریو مطرح شده در بالا:

⬅ مفهوم product را مدل کنید؟
⬅ مفهوم product در ماژول‌های بالا چه ارتباطی با یکدیگر دارند؟
⬅ در این سناریو Single Source of Truth چگونه اعمال می‌شود؟
⬅ تعریف product در هر کدام از ماژول‌های فروش، انبار و خزانه چیست؟
⬅ شرایط پذیرش مستتر در داستان کاربری شامل ensuring accurate stock management و pricing consistency را در این سناریو هندل کنید؟ راه‌حل خودتون رو تشریح کنید.

خطر اسپویل:
چالش هفته‌ی بعد، بخش دیگری از سناریوی بالا را زیر زیر ذره‌بین قرار خواهد داد!😉


لینک به صورت مسئله هفته دوم:

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

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

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

https://t.iss.one/DomainDrivenDesign_ir

📣چالش سوم DDD Plus

در چالش این هفته‌ی DDD Plus که شماره‌ی سوم این سری از چالش‌ها است، سراغ Team Topologyمی‌رویم. این چالش، قسمت تیم‌سازی چالش مطرح شده در DDD Plus3 را زیر ذره‌بین قرار خواهد داد.

🔔پیش‌زمینه:
همانطور که در بالا اشاره شد در این شماره DDD Plus جنبه تیم‌سازی را در سناریوی مطرح شده در چالش دوم DDD Plus خواهیم کرد. جهت سادگی دنبال کردن مسئله صورت مسئله یک‌بار دیگه در پایین بصورت کامل مطرح می‌شود.
فرض کنید به عنوان توسعه‌دهنده بر روی یک سیستم ERP مشغول به کار هستید. مفهوم “Product” یک مفهوم پایه‌ای و بسیار مهم در سیستم‌های ERP محسوب می‌شود که بک‌بن بسیاری از ماژول‌های یک سیستمERP را شامل می‌شود. به عنوان مثال در تمامی ماژول‌های فروش، انبار، تامین کالا، تولید، توزین و… مفهوم product نقش بسیار پررنگی بازی می‌کند. به عنوان مثال سیستم فروش بر پایه فروش محصول سوار شده است. ماژول انبار بر پایه مدیریت موجودی product بنا نهاده شده است. و یا سیستم تامین جهت مدیریت سفارشات و خرید product از تامین کنندگان توسعه داده می‌شود.
در حقیقت ارتباط این ماژول‌ها بر اساس تمرکز آنها بر مفهوم product می‌باشد. از همین رو هم این ماژول‌ها از طریق همین مفهوم product با یکدیگر صحبت و تعامل می‌کنند. ماژول فروش به ماژول انبار برای داشتن اطلاعات دقیق و آنلاین از موجودی کالاها نیازمند است. از طرف دیگر ماژول تامین سطح موجودی کالا در انبار را مانیتور کرده و سعی می‌کند با ثبت سفارش و تامین به موقع هر کالا، موجودی آن کالا در انبار را همیشه در سطح معینی نگه دارد.
فرض کنید مالک محصول با داستان کاربری زیر سراغتان می‌آید:

As a Sales Manager, I want the ERP system to provide a comprehensive and streamlined product modeling capability across the Sales, Inventory, and Purchase Order modules, ensuring accurate stock management, pricing consistency, and efficient procurement processes.

📍سناریو:
فرض کنید ۱۰ برنامه‌نویس با سطح توانایی متفاوت جهت توسعه این سیستم در اختیار دارید. این افراد دارای مهارت‌های توسعه محصول در بخش front-end و back-end رو دارند. از این نظر دارای محدودیت نمی‌باشید.

❓صورت مسئله:
با توجه به افراد در دسترس بالا:

⬅تیم‌های توسعه‌ی محصولات فروش، انبارداری و تامین کالا را تشکیل دهید؟
⬅یک context map برای این سه BC بکشید؟
⬅در این context map الگوهای ارتباطی بین این تیم‌(ها) را شرح دهید؟
Ownership مفهوم کالا را در بین ⬅تیم‌های تشکیل داده‌ شرح دهید؟


لینک به صورت مسئله هفته سوم:
https://domaindrivendesign.ir/ddd-plus-3

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

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

https://t.iss.one/DomainDrivenDesign_ir

📣چالش چهارم DDD Plus


🔔پیش‌زمینه:

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


📍سناریو:

در حال حاضر API شرکت FlightProvider.Com تمامی مسیرهایی که از پاریس شروع شده و به آمستردام ختم می‌شوند را به شما بر‌ می‌گرداند. ولی این امکان را به شما نمی‌دهد که فقط مسیرهایی که شامل یک یا دو lge هستند را درخواست کنید. قیمت بلیت‌ مسیرهایی از پاریس تا آمستردام بسته به تعداد leg های آن متفاوت هستند. همچنین قوانین پروازی و روادید در مسیرهایی دارای چندین leg نیز ممکن است برای مشتری مشکلاتی را ایجاد کنید.

❓صورت مسئله:

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

⬅ در کدام لایه از برنامه این منطق را پیاده‌سازی می‌کنید؟

⬅ چه مکانیزمی جهت leak نشدن این منطق به لایه دومین خواهید داشت؟

⬅ فرض کنید شرکت MyFlightProvider.Com را نیز به لیست پروایدرهای پرواز اضافه کردید. اکنون دو پروایدر پرواز دارید. در این حالت این منطق را کجا و چگونه پیاده‌سازی می‌کنید؟

⬅ میانگین زمان پاسخ API شرکت FlightProvider.Com 7 ثانیه می‌باشد. شما باید ظرف مدت ۸ ثانیه پاسخ را به کاربر برگردانید، در غیر اینصورت مکانیزم Circuit Breaker فعال می‌شود. در این حالت پاسخ خود را تشریح کنید. کد مورد نظر را بنویسید؟



لینک به صورت مسئله هفته چهارم:

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


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

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

https://t.iss.one/DomainDrivenDesign_ir

📣چالش پنجم 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