گزارش اولین ورکشاپ از سری جلسات Collaborative Modelling با موضوع Big Picture EventStorming
این جلسه به صابر راستی‌کردار عزیز🖤 به پاس زحمات بزرگ و ارزشمندی که برای وب فارسی کرده بود، تقدیم شد.
این گزارش مختصر رو میتونید از لینک زیر مشاهده کنید:
https://eventstorming.ir/blog/2023/11/18/collaborative-modelling-workshops-01-event-storming-story/
@DomainDrivenDesign_ir
این جلسه به صابر راستی‌کردار عزیز🖤 به پاس زحمات بزرگ و ارزشمندی که برای وب فارسی کرده بود، تقدیم شد.
این گزارش مختصر رو میتونید از لینک زیر مشاهده کنید:
https://eventstorming.ir/blog/2023/11/18/collaborative-modelling-workshops-01-event-storming-story/
@DomainDrivenDesign_ir
❤1
📣کارگاه ۳ روزه Specification by Example, from User Stories to Implementing Well-Crafted Software
پیش ثبت‌نام و رزرو کارگاه ۳ روزه SBE
در این ورکشاپ سه روزه شرکت کنندگان با تاکید بر collaborative modeling و collaborative design و تکیه بر اصول craftsmanship و در قالب تیم‌های چابک اقدام به تجزیه، تحلیل، جداسازی و پیاده‌سازی یک محصول خواهند کرد.
اطلاعات بیشتر رو از طریق لینک زیر می‌توانید مشاهده کنید:
https://domaindrivendesign.ir/product/specification-by-example-from-user-stories-to-implementing-well-crafted-software-workshop/
@DomainDrivenDesign_ir
پیش ثبت‌نام و رزرو کارگاه ۳ روزه SBE
در این ورکشاپ سه روزه شرکت کنندگان با تاکید بر collaborative modeling و collaborative design و تکیه بر اصول craftsmanship و در قالب تیم‌های چابک اقدام به تجزیه، تحلیل، جداسازی و پیاده‌سازی یک محصول خواهند کرد.
اطلاعات بیشتر رو از طریق لینک زیر می‌توانید مشاهده کنید:
https://domaindrivendesign.ir/product/specification-by-example-from-user-stories-to-implementing-well-crafted-software-workshop/
@DomainDrivenDesign_ir
مکتب‌خانه DDD
کارگاه عملی Specification By Example - From User Stories to Implementing Well-Crafted Software | مکتب‌خانه DDD
کارگاه عملی Specification By Example – From User Stories to Implementing Well-Crafted Software معرفی دوره: یکی از چالش‌های بزرگی و مهمی که در بیشتر مواقع با دوره‌های آموزشی وجود دارد این است که در نهایت نمی‌توان از محتوای یادگرفته شده در طول دوره، در محل…
❤2
کانال مکتب‌خانه DDD pinned «📣کارگاه ۳ روزه Specification by Example, from User Stories to Implementing Well-Crafted Software پیش ثبت‌نام و رزرو کارگاه ۳ روزه SBE در این ورکشاپ سه روزه شرکت کنندگان با تاکید بر collaborative modeling و collaborative design و تکیه بر اصول craftsmanship…»
کانال مکتب‌خانه DDD
📣کارگاه ۳ روزه Specification by Example, from User Stories to Implementing Well-Crafted Software پیش ثبت‌نام و رزرو کارگاه ۳ روزه SBE در این ورکشاپ سه روزه شرکت کنندگان با تاکید بر collaborative modeling و collaborative design و تکیه بر اصول craftsmanship…
⭕️با سلام خدمت همه عزیزان گرامی
📣کارگاه Specification by Example: From User Stories to Implementing Well-Crafted Software
از تاریخ ۲ الی ۴ اسفند ماه در تهران برگزار خواهد شد.
جهت شرکت و ثبت‌نام در این کارگاه با ای‌دی
@masodbahrami
تماس بگیرید.
⚠️اولویت شرکت با عزیزانی هست که از قبل رزرو کرده باشند.
📣کارگاه Specification by Example: From User Stories to Implementing Well-Crafted Software
از تاریخ ۲ الی ۴ اسفند ماه در تهران برگزار خواهد شد.
جهت شرکت و ثبت‌نام در این کارگاه با ای‌دی
@masodbahrami
تماس بگیرید.
⚠️اولویت شرکت با عزیزانی هست که از قبل رزرو کرده باشند.
کانال مکتب‌خانه DDD pinned «⭕️با سلام خدمت همه عزیزان گرامی 📣کارگاه Specification by Example: From User Stories to Implementing Well-Crafted Software از تاریخ ۲ الی ۴ اسفند ماه در تهران برگزار خواهد شد. جهت شرکت و ثبت‌نام در این کارگاه با ای‌دی @masodbahrami تماس بگیرید. ⚠️اولویت…»
کانال مکتب‌خانه DDD
⭕️با سلام خدمت همه عزیزان گرامی 📣کارگاه Specification by Example: From User Stories to Implementing Well-Crafted Software از تاریخ ۲ الی ۴ اسفند ماه در تهران برگزار خواهد شد. جهت شرکت و ثبت‌نام در این کارگاه با ای‌دی @masodbahrami تماس بگیرید. ⚠️اولویت…
اگر محصول‌چی باشید، حتما با چالش‌ها و دعواهای همیشگی با برنامه نویس‌ها سروکله زده‌اید. ⚔️👊اولین تصویری که از تقابل این دو گروه به ذهن خطور می‌کند، عدم وجود درک صحیح و همینطور نبود زبان مشترک بین این دو گروه است. گویی این دو گروه از دو قبیله متفاوت بنا به اقتضای کار و اجبار، ناچار باید با یکدیگر بر روی توسعه یک محصول کار کنند😃
چالش‌هایی از جمله:
• عدم شفافیت در تعریف و مفهوم محصول
• نبود عمق استراتژیک محصول
• نداشتن برداشت یکسان از تصویر بزرگ محصول
• بر روی یک صفحه نبودن اعضای تیم شامل محصول‌چی ها، ذینفعان کلیدی، توسعه دهندگان، متخصصان UI و UX و تیم QA و ...
• نبود درک صحیح از مفهوم ریلیز پلن بین اعضای تیم
• رفت و برگشت‌های پینک پنکی فیچرهای محصول بین افراد
• صرف ساعت‌های متمادی و حتی متوالی و تقلا برای شفاف کردن آیتم‌های محصول
اینها تنها بخشی از چالش‌های اساسی و پایه‌ای است که افراد در توسعه محصول همه روزه با آنها سروکله می‌زنند. نکته‌ی مهم و جالب‌تر فراگیر بودن این چالش‌ها است. به گونه‌ای که شما تقریبا در اکثر جاها می‌توانید به راحتی این چالش‌ها را تجربه کنید.
رویکردهای Collaborative Modelling and Design جهت غلبه بر مشکلات اشاره شده در بالا، رویه‌های مبتنی بر تشریک مساعی و همکاری همه‌ی افراد تاثیر گذار را در مراحل مختلف توسعه‌ی محصول تشویق و ترغیب می‌کند.
📍شما در ورکشاپ Specification by Example: From User Stories to Implementing Well-Crafted Software این فرصت را بدست می‌آورید تا با راهنمایی و مربی‌گری افراد با تجربه در این زمینه، مراحل مختلف توسعه‌ی محصول از ایده‌ی اولیه محصول تا طراحی ریلیز پلن‌ها و ایتریشن‌های محصول و همینطور پیاده‌سازی در این ایتریشن‌ها را در کنار یک تیم توسعه بصورت کامل تجربه کنید.
تکنیک‌هایی از جمله:
✅ Value Props
✅ Business Model Canvas
✅ Impact Mapping
✅ EventStorming
✅ DomainStoryTelling
✅ User Story Mapping
✅ Example Mapping
✅ Three Amigos
در این کارگاه سه روزه زیر ذره بین قرار خواهند گرفت، و شما بصورت فعال آنها را تجربه خواهید کرد.
در نهایت تیم ها یاد خواهند گرفت که چگونه dead line های محصول را میت کنند.
💭 اگر محصول‌چی هستید(Product Owner, Product Manager, Product Analysis, QA و ...) شما هم مخاطب این ورکشاپ هستید.
📅 این کارگاه روزهای 2 تا 4 اسفندماه 1402بصورت حضوری در تهران برگزار خواهد شد.
🔵 جهت شرکت و ثبت‌نام در این کارگاه با ای‌دی @masodbahrami تماس بگیرید.
چالش‌هایی از جمله:
• عدم شفافیت در تعریف و مفهوم محصول
• نبود عمق استراتژیک محصول
• نداشتن برداشت یکسان از تصویر بزرگ محصول
• بر روی یک صفحه نبودن اعضای تیم شامل محصول‌چی ها، ذینفعان کلیدی، توسعه دهندگان، متخصصان UI و UX و تیم QA و ...
• نبود درک صحیح از مفهوم ریلیز پلن بین اعضای تیم
• رفت و برگشت‌های پینک پنکی فیچرهای محصول بین افراد
• صرف ساعت‌های متمادی و حتی متوالی و تقلا برای شفاف کردن آیتم‌های محصول
اینها تنها بخشی از چالش‌های اساسی و پایه‌ای است که افراد در توسعه محصول همه روزه با آنها سروکله می‌زنند. نکته‌ی مهم و جالب‌تر فراگیر بودن این چالش‌ها است. به گونه‌ای که شما تقریبا در اکثر جاها می‌توانید به راحتی این چالش‌ها را تجربه کنید.
رویکردهای Collaborative Modelling and Design جهت غلبه بر مشکلات اشاره شده در بالا، رویه‌های مبتنی بر تشریک مساعی و همکاری همه‌ی افراد تاثیر گذار را در مراحل مختلف توسعه‌ی محصول تشویق و ترغیب می‌کند.
📍شما در ورکشاپ Specification by Example: From User Stories to Implementing Well-Crafted Software این فرصت را بدست می‌آورید تا با راهنمایی و مربی‌گری افراد با تجربه در این زمینه، مراحل مختلف توسعه‌ی محصول از ایده‌ی اولیه محصول تا طراحی ریلیز پلن‌ها و ایتریشن‌های محصول و همینطور پیاده‌سازی در این ایتریشن‌ها را در کنار یک تیم توسعه بصورت کامل تجربه کنید.
تکنیک‌هایی از جمله:
✅ Value Props
✅ Business Model Canvas
✅ Impact Mapping
✅ EventStorming
✅ DomainStoryTelling
✅ User Story Mapping
✅ Example Mapping
✅ Three Amigos
در این کارگاه سه روزه زیر ذره بین قرار خواهند گرفت، و شما بصورت فعال آنها را تجربه خواهید کرد.
در نهایت تیم ها یاد خواهند گرفت که چگونه dead line های محصول را میت کنند.
💭 اگر محصول‌چی هستید(Product Owner, Product Manager, Product Analysis, QA و ...) شما هم مخاطب این ورکشاپ هستید.
📅 این کارگاه روزهای 2 تا 4 اسفندماه 1402بصورت حضوری در تهران برگزار خواهد شد.
🔵 جهت شرکت و ثبت‌نام در این کارگاه با ای‌دی @masodbahrami تماس بگیرید.
❤1
Forwarded from Masoud Bahrami
Launching Airbnb and the Challenges of Scale
Brian Chesky at Stanford University
What can be the most important and biggest challenge or challenges in scaling a company like Airbnb❓
-Technology
- People
- Culture
- Customers ...?
What do you think❓
This is session 18 of Technology-enabled Blitzscaling, a Stanford University class taught by Reid Hoffman, John Lilly, Allen Blue, and Chris Yeh. This class features Reed Hoffman interviewing Brian Chesky, the Co-Founder and CEO of Airbnb.
https://www.youtube.com/watch?v=W608u6sBFpo
Brian Chesky at Stanford University
What can be the most important and biggest challenge or challenges in scaling a company like Airbnb❓
-Technology
- People
- Culture
- Customers ...?
What do you think❓
This is session 18 of Technology-enabled Blitzscaling, a Stanford University class taught by Reid Hoffman, John Lilly, Allen Blue, and Chris Yeh. This class features Reed Hoffman interviewing Brian Chesky, the Co-Founder and CEO of Airbnb.
https://www.youtube.com/watch?v=W608u6sBFpo
YouTube
Blitzscaling 18: Brian Chesky on Launching Airbnb and the Challenges of Scale
This is session 18 of Technology-enabled Blitzscaling, a Stanford University class taught by Reid Hoffman, John Lilly, Allen Blue, and Chris Yeh. This class features Reed Hoffman interviewing **Brian Chesky**, the Co-Founder and CEO of Airbnb.
👍1
در این سری از پادکست‌های کانال 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
حتما پیشنهاد می‌کنم این پادکست رو ببینید و بشنوید.
Eric در این پادکست در مورد پیشینه‌ی تحصیلی و کاری خودش، تفکراتش در مورد موضوع دیزاین و کد نویسی، تفکرات و ایده‌های زیربنایی DDD و خیلی موارد جذاب دیگر صحبت میکنه.
موضوع AI این روزها بحث داغ و نقل محافل است. بخصوص تاثیرات سازنده و مخرب AI بر آینده شغلی برنامه نویسان، و البته بر صنعت نرم‌افزار بصورت کلی.
توی این پادکست، همینطور می‌تونیم نظر Eric Evans رو در مورد میزان عملکرد AI بر مواردی از جمله دیزاین نرم‌افزار ببینیم و بشنویم.
https://www.youtube.com/watch?v=r_WRUFx7RLY
@DomainDrivenDesign_ir
YouTube
How AI Will Change Software Development In The Next 10 Years | Eric Evans TER Ep. 25
What does the future of software development look like? How will AI shape software engineer jobs? In this episode of the Engineering Room podcast, Dave is joined by author, software engineer and well-known thought leader, Eric Evans. They talk about Eric's…
👏2👍1
📣اطلاعیه برگزاری کارگاه Specification by Example: From User Stories to Implementing Well-Crafted Software
⭕️مربیان دوره: مسعود بهرامی، هادی احمدی
⭕️تاریخ برگزاری: ۲ الی ۴ اسفند ۱۴۰۲
♦️معرفی کارگاه:
افراد شرکت کننده در این ورکشاپ در قالب تیم‌های توسعه‌ی کوچک، و با هدایت منتور، اقدام به پیاده‌سازی کامل یک محصول از ایده‌ی اولیه تا طراحی ریلیزپلن‌های محصول و سپس پیاده‌سازی محصول با تکیه بر رویکرد Domain-Driven Design و تست اتوماتیک و همچنین craftsmanship خواهند کرد.
تیم‌ها در طول کارگاه یکسری Iteration تعریف خواهند کرد، و سعی می‌کنند محصول خود را در طول اسپرینت‌ها به مرور توسعه بدهند و تکمیل کنند.
📢جهت کسب اطلاعات بیشتر و شرکت در کارگاه با شماره 09120750671 یا تلگرام @masodbahrami تماس بگیرید.
@DomainDrivenDesign_ir
⭕️مربیان دوره: مسعود بهرامی، هادی احمدی
⭕️تاریخ برگزاری: ۲ الی ۴ اسفند ۱۴۰۲
♦️معرفی کارگاه:
افراد شرکت کننده در این ورکشاپ در قالب تیم‌های توسعه‌ی کوچک، و با هدایت منتور، اقدام به پیاده‌سازی کامل یک محصول از ایده‌ی اولیه تا طراحی ریلیزپلن‌های محصول و سپس پیاده‌سازی محصول با تکیه بر رویکرد Domain-Driven Design و تست اتوماتیک و همچنین craftsmanship خواهند کرد.
تیم‌ها در طول کارگاه یکسری Iteration تعریف خواهند کرد، و سعی می‌کنند محصول خود را در طول اسپرینت‌ها به مرور توسعه بدهند و تکمیل کنند.
📢جهت کسب اطلاعات بیشتر و شرکت در کارگاه با شماره 09120750671 یا تلگرام @masodbahrami تماس بگیرید.
@DomainDrivenDesign_ir
کانال مکتب‌خانه DDD
گزارش اولین ورکشاپ از سری جلسات Collaborative Modelling با موضوع Big Picture EventStorming این جلسه به صابر راستی‌کردار عزیز🖤 به پاس زحمات بزرگ و ارزشمندی که برای وب فارسی کرده بود، تقدیم شد. این گزارش مختصر رو میتونید از لینک زیر مشاهده کنید: https://…
📹ویدئوی اولین ورکشاپ Collaborative Modelling آپلود شد. میتونید ویدئو رو از آدرس زیر مشاهده کنید.
آدرس کانال یوتیوب مکتب‌خانه DDD رو هم میتونید زیر مشاهده کنید. اگر دوست داشتید میتونید سابسکرایب کنید 🤩
لینک مشاهده ویدئوی ورکشاپ Big picture EventStorming 👈
https://youtu.be/xRD1PAEnd_k?si=0079COFwLKlZhvnJ
آدرس کانال یوتیوب مکتب‌خانه DDD 👈
https://www.youtube.com/@domaindrivendesign.
@DomainDrivenDesign_ir
آدرس کانال یوتیوب مکتب‌خانه DDD رو هم میتونید زیر مشاهده کنید. اگر دوست داشتید میتونید سابسکرایب کنید 🤩
لینک مشاهده ویدئوی ورکشاپ Big picture EventStorming 👈
https://youtu.be/xRD1PAEnd_k?si=0079COFwLKlZhvnJ
آدرس کانال یوتیوب مکتب‌خانه DDD 👈
https://www.youtube.com/@domaindrivendesign.
@DomainDrivenDesign_ir
YouTube
Collaborative Modelling Part1- Big Picture EventStorming
اولین جلسه از سری ورکشاپ‌های Collaborative Modelling با موضوع Big Picture EventStorming
@Masoud.Bahrami
#DDD #Collaborativemodelling #eventstorming
@Masoud.Bahrami
#DDD #Collaborativemodelling #eventstorming
👍4
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.
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
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
Masoud’s Substack
Contextualized Domain Language
To communicate effectively, the code must be based on the same language used to write the requirements—the same language that the developers speak with each other and with domain experts. —Eric Evans Language of the Domain In Domain-Driven Design (DDD), language…
سلام به همگی عزیزان و همراهان گرامی مکتب‌خانه DDD
سال جدید و عید نوروز ۱۴۰۳ رو به همگی همراهان و عزیزان تبریک و تهنیت عرض میکنیم.🎂
امید که امسال سرشار از شادی و موفقیت و خبرهای خوب باشه برای همگی عزیزان🥳
سال جدید و عید نوروز ۱۴۰۳ رو به همگی همراهان و عزیزان تبریک و تهنیت عرض میکنیم.🎂
امید که امسال سرشار از شادی و موفقیت و خبرهای خوب باشه برای همگی عزیزان🥳
❤2
DDD and LLMs
By Eric Evans
At Explore DDD 2024
Abstract questions Eric talked about:
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
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
YouTube
DDD and LLMs - Eric Evans - Explore DDD 2024
Explore DDD 2024 - Denver, March 12-15
https://exploreddd.com | https://www.linkedin.com/company/exploreddd | https://twitter.com/ExploreDDD
Organized and sponsored by Virtual Genius (https://virtualgenius.com)
Eric Evans opened Explore DDD 2024 with a…
https://exploreddd.com | https://www.linkedin.com/company/exploreddd | https://twitter.com/ExploreDDD
Organized and sponsored by Virtual Genius (https://virtualgenius.com)
Eric Evans opened Explore DDD 2024 with a…
👌1
با سلام خدمت همه عزیزان و همراهان گرامی
توی فیوچراسپکتیو سال جدید، چندین برنامه رو در نظر گرفتیم که اجرا کنیم. یکی از این مواردی که تصمیم گرفتیم با همدیگر اجرا کنیم، برنامه تحت عنوان DDD Plus است. توی این برنامه قصد داریم که ابتدای هر هفته یک مسئله و چالشی رو مطرح کنیم و سپس توی طول هفته در مورد آن صحبت کنیم. آخر هر هفته هم جمع‌بندی نظرات مطرح شده رو منتشر میکنیم.
https://domaindrivendesign.ir/ddd-plus
توی فیوچراسپکتیو سال جدید، چندین برنامه رو در نظر گرفتیم که اجرا کنیم. یکی از این مواردی که تصمیم گرفتیم با همدیگر اجرا کنیم، برنامه تحت عنوان DDD Plus است. توی این برنامه قصد داریم که ابتدای هر هفته یک مسئله و چالشی رو مطرح کنیم و سپس توی طول هفته در مورد آن صحبت کنیم. آخر هر هفته هم جمع‌بندی نظرات مطرح شده رو منتشر میکنیم.
https://domaindrivendesign.ir/ddd-plus
مکتب‌خانه DDD
اطلاعیه چالش‌های هفتگی DDD Plus | مکتب‌خانه DDD
با سلام خدمت دوستان و همراهان عزیز و گرامی مکتب‌خانه DDD چون این پست رو توی بهبوهه تعطیلات نوروزی سال ۱۴۰۳ منتشر میکنیم، پس قبل از هر چیزی سال جدید رو به بهتون تبریک عرض میکنیم. امیدواریم سال سرشار از موفقیت و شادکامی و سلامتی پیش رو داشته باشید.😊❤🎁 توی…
👏4
چالش اول 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 رو توی سال جدید-۱۴۰۳، با صورت مسئله‌ای از آخرین ورکشاپ سال ۱۴۰۲ (ورکشاپ 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
DDD Plus #1 | مکتب‌خانه DDD
در اولین چالش DDD Plus یکی از چالش‌های مهم و همیشگی بین محصولچی‌ها و تیم توسعه را زیر ذره بین می‌بریم. در جلسه ایونت‌استورمینگ کارت زیر روی دیوار پارک شد...
👌1😍1
کانال مکتب‌خانه DDD
چالش اول DDD Plus اولین چالش DDD Plus رو توی سال جدید-۱۴۰۳، با صورت مسئله‌ای از آخرین ورکشاپ سال ۱۴۰۲ (ورکشاپ Specification by Example)شروع میکنیم. 🔔 پیش زمینه: دومینی که توی کارگاه زیر ذره بین بردیم، در مورد یک استارت‌آپ ساختگی بوده که این امکان رو به…
برای بحث و تبادل نظر در مورد چالش‌های DDD Plus توی این گروه تلگرامی می‌توانید عضو بشید:
https://t.iss.one/AgileSoftwareDiscourse
https://t.iss.one/AgileSoftwareDiscourse
👍1
📣 چالش دوم 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 خواهیم رفت. در این شماره یک سناریو پیچیده و جالب را زیر ذره‌بین خواهیم برد.
🔔 پیش زمینه:
فرض کنید به عنوان توسعه‌دهنده بر روی یک سیستم 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
DDD Plus #2 | مکتب‌خانه DDD
در چالش شماره دو DDD Plus مسئله مدلسازی در DDD را زیر ذره‌بین می‌بریم. فرض کنید در یک سیستم ERP در حال مدل کردن محصول برای ماژولهای Sales, Inventory و Purchase Order هستید...
📣چالش سوم DDD Plus
در چالش این هفته‌ی DDD Plus که شماره‌ی سوم این سری از چالش‌ها است، سراغ Team Topologyمی‌رویم. این چالش، قسمت تیم‌سازی چالش مطرح شده در DDD Plus3 را زیر ذره‌بین قرار خواهد داد.
🔔پیش‌زمینه:
همانطور که در بالا اشاره شد در این شماره DDD Plus جنبه تیم‌سازی را در سناریوی مطرح شده در چالش دوم DDD Plus خواهیم کرد. جهت سادگی دنبال کردن مسئله صورت مسئله یک‌بار دیگه در پایین بصورت کامل مطرح می‌شود.
فرض کنید به عنوان توسعه‌دهنده بر روی یک سیستم ERP مشغول به کار هستید. مفهوم “Product” یک مفهوم پایه‌ای و بسیار مهم در سیستم‌های ERP محسوب می‌شود که بک‌بن بسیاری از ماژولهای یک سیستمERP را شامل می‌شود. به عنوان مثال در تمامی ماژولهای فروش، انبار، تامین کالا، تولید، توزین و… مفهوم product نقش بسیار پررنگی بازی می‌کند. به عنوان مثال سیستم فروش بر پایه فروش محصول سوار شده است. ماژول انبار بر پایه مدیریت موجودی product بنا نهاده شده است. و یا سیستم تامین جهت مدیریت سفارشات و خرید product از تامین کنندگان توسعه داده می‌شود.
در حقیقت ارتباط این ماژول‌ها بر اساس تمرکز آنها بر مفهوم product می‌باشد. از همین رو هم این ماژول‌ها از طریق همین مفهوم product با یکدیگر صحبت و تعامل می‌کنند. ماژول فروش به ماژول انبار برای داشتن اطلاعات دقیق و آنلاین از موجودی کالاها نیازمند است. از طرف دیگر ماژول تامین سطح موجودی کالا در انبار را مانیتور کرده و سعی می‌کند با ثبت سفارش و تامین به موقع هر کالا، موجودی آن کالا در انبار را همیشه در سطح معینی نگه دارد.
فرض کنید مالک محصول با داستان کاربری زیر سراغتان می‌آید:
📍سناریو:
فرض کنید ۱۰ برنامه‌نویس با سطح توانایی متفاوت جهت توسعه این سیستم در اختیار دارید. این افراد دارای مهارت‌های توسعه محصول در بخش 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 که شماره‌ی سوم این سری از چالش‌ها است، سراغ 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
DDD Plus 3 | مکتب‌خانه DDD
در چالش سوم DDD Plus 3 مسئله Team Topology را در یک سناریوی واقعی زیر ذره‌بین خواهیم برد. در این چالش که ادامه چالش شماره دوم DDD Plus است مطرح خواهیم کرد ...
👍1
📣چالش چهارم 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
🔔پیش‌زمینه:
شما در شرکت 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
DDD Plus 4 | مکتب‌خانه DDD
در چالش شماره 4 DDD Plus سناریوی متداول کال کردن و چتینگ سرویس‌های خارجی در کانتسکت DDD رو زیر ذره‌بین بردیم. چگونه از leak شدن language سرویس‌های مختلف به یکدیگر می‌تواند مراقبت و جلوگیری کرد ...