📣کارگاه ۳ روزه 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

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

📣کارگاه 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 تماس بگیرید.

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

در این سری از پادکست‌های کانال 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