در این سری از پادکست‌های کانال Continuous Delivery ‌ آقای Dave Farely یکی از نویسندگان کتاب معروف Continuous Delivery گفتگویی جذاب و شنیدنی با Eric Evans نویسنده کتاب Domain-Driven Design داشته. کتابی که وجودش توی قفسه‌ی هر آدمی که به نوعی نقشی و تاثیری در تولید نرم‌افزار داره واجب و ضروری است.

حتما پیشنهاد می‌کنم این پادکست رو ببینید و بشنوید.

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

موضوع AI این روزها بحث داغ و نقل محافل است. بخصوص تاثیرات سازنده و مخرب AI بر آینده شغلی برنامه نویسان، و البته بر صنعت نرم‌افزار بصورت کلی.
توی این پادکست، همینطور می‌تونیم نظر Eric Evans رو در مورد میزان عملکرد AI بر مواردی از جمله دیزاین نرم‌افزار ببینیم و بشنویم.


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


@DomainDrivenDesign_ir

📣اطلاعیه برگزاری کارگاه Specification by Example: From User Stories to Implementing Well-Crafted Software

⭕️مربیان دوره: مسعود بهرامی، هادی احمدی

⭕️تاریخ برگزاری: ۲ الی ۴ اسفند ۱۴۰۲

♦️معرفی کارگاه:

افراد شرکت کننده در این ورکشاپ در قالب تیم‌های توسعه‌ی کوچک، و با هدایت منتور، اقدام به پیاده‌سازی کامل یک محصول از ایده‌ی اولیه تا طراحی ریلیزپلن‌های محصول و سپس پیاده‌سازی محصول با تکیه بر رویکرد Domain-Driven Design و تست اتوماتیک و همچنین craftsmanship خواهند کرد.

تیم‌ها در طول کارگاه یکسری Iteration تعریف خواهند کرد، و سعی می‌کنند محصول خود را در طول اسپرینت‌ها به مرور توسعه بدهند و تکمیل کنند.



📢جهت کسب اطلاعات بیشتر و شرکت در کارگاه با شماره 09120750671 یا تلگرام @masodbahrami‌ تماس بگیرید.
 

@DomainDrivenDesign_ir

📹ویدئوی اولین ورکشاپ Collaborative Modelling آپلود شد. میتونید ویدئو رو از آدرس زیر مشاهده کنید.

آدرس کانال یوتیوب مکتب‌خانه DDD رو هم می‌تونید زیر مشاهده کنید. اگر دوست داشتید میتونید سابسکرایب کنید 🤩


لینک مشاهده ویدئوی ورکشاپ Big picture EventStorming 👈
https://youtu.be/xRD1PAEnd_k?si=0079COFwLKlZhvnJ

آدرس کانال یوتیوب مکتب‌خانه DDD 👈
https://www.youtube.com/@domaindrivendesign.



@DomainDrivenDesign_ir

One of the most important points in DDD is its focus on Domain Language. A universal-unified language that exists from formal/informal conversations to analysis artifacts, through code and test implementations. Precise language, free of bias and multiple interpretations.

We know that language is very context sensitive. For example, consider the following sentence.

I saw her duck.

🦆

What can be understood from this sentence without context?

The sentence "I saw her duck" can have multiple meanings depending on the interpretation of the word "duck." Here are a few possible interpretations:

"Duck" as a noun (animal):

1️⃣ Meaning 1: I visually perceived a duck that belongs to her.
Example: "I saw her pet duck swimming in the pond."
"Duck" as a verb (action):

2️⃣ Meaning 2: I observed her physically lowering her body or head quickly to avoid something.
Example: "I saw her duck to avoid getting hit by the ball."
"Duck" as a verb (motion):

3️⃣ Meaning 3: I noticed her moving or walking like a duck.
Example: "I saw her duck waddling across the yard."


⚠️Please note that context plays a crucial role in determining the intended meaning of a sentence. Without additional context, it is challenging to determine the precise interpretation of the sentence "I saw her duck."


Without enclosing the language with a clearly defined border- in other words without adding a context to the language- it is not possible to achieve a precise, specific and unbiased language free from multiple interpretations.

Especially in software development, from this point of view, the importance of Contextualizing the Language is very important and vital.

Recently I started writing articles about Domain Language and Modeling Domain Language. The following is a brief introduction to the topic of contextualizing language.

Read the article 👉
https://masoudbahrami.substack.com/p/contextualized-domain-language


Subscribe to my SubStack channel👉 https://substack.com/@domainlanguage

سلام به همگی عزیزان و همراهان گرامی مکتب‌خانه DDD

سال جدید و عید نوروز ۱۴۰۳ رو به همگی همراهان و عزیزان تبریک و تهنیت عرض میکنیم.🎂

امید که امسال سرشار از شادی و موفقیت و خبرهای خوب باشه برای همگی عزیزان🥳

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