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

لطفا جهت شرکت در برنامه از طریق لینک زیر اقدام بفرمائید.

https://lu.ma/3odgar5o



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

💬 کانال مکتب‌خانه DDD:
https://t.iss.one/DomainDrivenDesign_ir

با تشکر از همه عزیزانی که استقبال کردند.
ظرفیت ثبت‌نام تکمیل شده 😍 ولی می‌تونید ثبت‌نام رو انجام بدید و به ویت لیست اضافه بشید

تعداد زیادی از عزیزان پشت در موندن 😅 با توجه به زمان محدودی که داشتیم و اینکه دیر اطلاع رسانی کردیم تصور میشد عزیزان کمتری شرکت کنند

از همگی تشکر میکنم بابت استقبال.😍❤️

اولین جلسه هست و قطعا کم و کسری و نا بلدی زیادی داریم. از همینجا از همگی عذرخواهی میکنیم. تا جایی که ظرفیت اجازه بده حتما با افتخار در خدمت همگی دوستان هستیم تا از همدیگه یاد بگیریم و کسب و تجربه کنیم.

بقول اریک اونس:

Let's Practice DDD together.

ممنون از همگی عزیزانی که توی جلسه شرکت کردند.❤️🌹

امیدواریم که جلسه مفیدی بوده باشه.

💬 اگر نظر یا انتقادی در مورد جلسه امروز داشتید حتما عنوان بفرمایید. قطعا نظر شما برای ما بسیار ارزشمند و مفید خواهد بود و به بهبود جلسات آینده کمک شایانی خواهد کرد.

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

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

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

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

این مورد نیز توسط مدیر محصول عنوان شده که: انواع استخدام در هر سازمانی با سازمان دیگر متفاوت هست.


🔴 صورت مسئله:
با در نظر گرفتن سناریوی بالا و اینکه شما در حال پیاده‌سازی آیتم نوع استخدام هستید به سوالات زیر پاسخ دهید:
🔶 چه چالشی در نوع بیان مسئله در بالا می‌بینید؟
🔶 دومین این مسئله را طراحی کنید؟
🔶 مواردی که در سناریوی بالا گفته شد چه تاثیری در طراحی شما دارد؟
🔶 باندد کانتسک(ها) را در مسئله بالا طراحی کنید؟



لینک به چالش شماره 12:

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



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

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

https://t.iss.one/DomainDrivenDesign_ir

📣 اطلاع رسانی دومین جلسه آنلاین DDD Plus

جلسه دوم DDD Plus این هفته جمعه از ساعت ۱۸:۰۰ الی ۱۹:۰۰ برگزار خواهد شد.

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


لینک ثبت‌نام در رویداد:
https://lu.ma/wzzazb2n


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

💬 کانال مکتب‌خانه DDD:
https://t.iss.one/DomainDrivenDesign_ir

ظرفیت این رویداد تکمیل شده😍

از همه عزیزانی که ثبت‌نام کردند نهایت تشکر رو داریم.

متاسفانه بدلیل فرمت جلسات DDD Plus، ظرفیت برگزاری رویدادهای DDD Plus محدود هست.

🔹 ظرفیت waitlist هنوز پر نشده و می‌تونید ثبت‌نام بفرمایید.

رویداد دوم DDD Plus تا ساعاتی دیگر آغاز می‌شود. بی‌صبرانه مشتاق دیدار شما عزیزان هستیم😍

https://t.iss.one/DomainDrivenDesign_ir

a Good and simple argument on Whether or not TDD is a rocket-science?
by Kent Beck

TDD, imposes constraints on motion between program states.

📖Read the article: https://tidyfirst.substack.com/p/tdd-is-not-hill-climbing

📣 اطلاع رسانی سومین جلسه آنلاین DDD Plus

جلسه سوم DDD Plus این هفته جمعه از ساعت ۱۸:۰۰ الی ۱۹:۰۰ برگزار خواهد شد.

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

دست به دست هم اگر کنید که به اطلاع افراد علاقمند به شرکت در جلسه برسه، کمال تشکر رو دارم

لینک ثبت‌نام در رویداد:
https://lu.ma/jo0n3suj


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

💬 کانال مکتب‌خانه DDD:
https://t.iss.one/DomainDrivenDesign_ir

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

برنامه سوم DDD Plus تا ساعتی دیگر شروع می‌شود.
ظرفیت ثبت‌نام تکمیل شده، ولی می‌تونید ثبت‌نام بفرمائید ولی ظرفیتی برای دوستانی که هنوز موفق نشدند ثبت‌نام کنند و پشت در موندند اضافه شده است.

خیلی خیلی مشتاقیم شما رو هم توی جمعمون ببینیم😍

An interview with Jeff Weinstein on Lenny podcast.

Jeff Weinstein is a product lead at Stripe where he helped grow their payment APIs to hundreds of billions in volume and transformed the way founders start companies into a few simple clicks with Atlas. Prior to Stripe, Jeff led several startups and sold companies to Groupon and Box.

He’s known for his customer obsession, craft, quality, and building beloved products businesses rely on.

In the conversation, they discuss:
🔸 The power of customer obsession and how to operationalize it in your product development process
🔸 How to pick the right metrics and use them to drive impact
🔸 Techniques for getting things done at big companies
🔸 A group practice Jeff started to uplevel product craft, called Study Group
🔸 The story behind Stripe Atlas and its mission to increase entrepreneurship globally
🔸 Lessons from working with the founders of Stripe

Some key takeaways:

1. Before focusing on craft, experience, or quality, you need to ensure that you’re solving a burning problem for someone. One of Jeff’s first companies went offline for hours and not a single customer reached out—that’s when he knew they didn’t have product-market fit. If users aren’t clamoring for your product, you’re not solving a real need. Think about it this way: solving the core problem is the main course; perfecting craft, UX, and quality are the desserts.

2. Jeff emphasizes the “go, go, go ASAP + optimistic, long-term compounding” approach: seize opportunities with enthusiasm while maintaining a strategic focus on long-term growth. Stripe’s evolution in global payment methods exemplifies how combining rapid execution with thoughtful, enduring strategies leads to significant, sustainable results.

3. When customers take the time to complain or provide feedback, treat it as a gift. Respond promptly to complaints or feedback, even if it means interrupting other tasks, as it creates a direct signal between you and the customer. This responsive attitude can lead to a loyal customer base and product improvement.

4. Ask customers to describe what a “bad day” looks like when using your product, and then find ways to track metrics around those frustrations. You don’t necessarily need to solve every issue right away, but having this problem library builds awareness to inform your roadmap.

Listen to the podcast: 👇

https://youtu.be/qbZQjprTnrU

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


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

پیشنهاد می‌کنم چالش این هفته را بصورت کامل از لینک زیر مطالعه کنید:


لینک به چالش شماره 13: 👇

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


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

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

https://t.iss.one/DomainDrivenDesign_ir

🎬 ویدئوی رویداد اول DDD Plus

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

ویدئوی اولین رویداد DDD Plus منتشر شد. شما می‌توانید از طریق لینک زیر به ویدئو دسترسی پیدا کنید:

https://domaindrivendesign.ir/ddd-plus-01-video/





ما را دنبال کنید:

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

💬 کانال مکتب‌خانه DDD:
https://t.iss.one/DomainDrivenDesign_ir
🎥کانال یوتیوب:
https://www.youtube.com/@Masoud.Bahrami

Language can and should play an important role in exploring and modeling a complex domain.


As you know, the greatest complexity of the vast majority of the software domain lies in the understanding of the domain itself. Every domain, simple or complex, is somehow expressed in formal or informal language by domain experts, product managers or software owners and developers. We must look for the drivers of our solution in the problem space. As mentioned earlier, the problem is expressed in formal or informal language.

So focus on the language of the domain to be modeled.

🌎 More information: https://LanguageDrivenDesign.Com


One of the most important activities in any language development is the wording or naming.

Why is naming so important?

Read this groundbreaking essay by Gottlob Frege - On Sense and Reference

https://www.slideshare.net/slideshow/on-sense-and-reference-52471284/52471284

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

Design, Composition, and Performance❗

Watch this groundbreaking talk by Rich Hickey, the creator of Clojure and designer of Datomic, where he delves into the core principles of design and composition and their impact on the way we build software.

Intrigued? Here's why you should watch:

In the talk Rich delve into:

Design & Composition: This talk explores the fundamental building blocks of software development and how they influence our practices and tools.

📣 📢 چهارمین رویداد آنلاین DDD Plus
با موضوع، "چگونه تیم خوشحال(تری) داشته باشیم؟" این هفته جمعه از ساعت 18 الی 19 برگزار می‌شود.

زمان: جمعه 26 مرداد 1403
ساع: 18 الی 19

شما چه فکر می‌کنید؟ تعریف یک تیم خوشحال چیست؟ چه فاکتورهایی برای داشتن یک تیم خوشحال نیاز داریم؟ اصلا چه ترکیبی برای داشتن یک تیم خوشحال می‌توان متصور شد؟

توی این رویداد سعی می‌کنیم این سوالات رو به بحث و چالش بکشونیم.

📆 تاریخ: جمعه 26 مرداد 1403
⏰ ساعت: 18 الی 19

لینک ثبت‌نام در رویداد:
https://lu.ma/8rmq1sff

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

چالش این شماره متفاوت‌تر از چالش‌های قبلی است. 5شنبه‌ی هفته گذشته در دورهمی اعضای تهران جاگ(Tehran JUG) حضور پیدا کردم. موضوع درهمی DDD بود. مسئله‌ای در باب استفاده از Value Object و تقدس و شرارت Value Objectمطرح شد. چالش این شماره همین موضوع بسیار متداول و کلاسیک در DDD را زیر ذره‌بین برده است.

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



🔴 سناریو:
تصور کنید شما یک متخصص DDD در شرکت DDD-To-The-Rescue.Com هستید. شما در حال طراحی یک سیستم سفارش‌گیری هستید که مشتریان می‌توانند چندین آدرس مختلف برای ارسال سفارشات خود ثبت کنند و هر سفارش نیز می‌تواند شامل محصولات مختلفی باشد.

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

بین شما و سایر افراد این بحث پیش می‌آید که آدرس را Value Object در نظر بگیریم یا Object. آدرس‌ها را چطور؟ با توجه به این سناریو آشنا به سوالات زیر پاسخ دهید.


🔴 صورت مسئله:

با توجه به سناریو بالا به سوالات زیر پاسخ دهید:

🔶 آیا آدرس یک مشتری باید به عنوان یک Value Object (VO) یا Entity در نظر گرفته شود؟
🔶 بهترین روش برای مدل‌سازی چندین آدرس برای یک مشتری چیست؟ از VO یا Entity استفاده کنیم؟
🔶 تفاوت اساسی بین Value Object و Entity چیست و چرا این تفاوت در این سناریو مهم است؟
🔶 آیا واقعا تفاوت بین این دو مفهوم آنقدرها که فکر می‌کنیم اساسی و ضروری است؟
🔶 چگونه باید مشتری را مدل‌سازی کنیم؟
🔶 تاثیر انتخاب مدل مناسب برای آدرس‌ها بر نحوه ذخیره‌سازی و بازیابی اطلاعات چیست؟
🔶 چگونه باید آیتم‌های موجود در یک سفارش را مدل‌سازی کنیم؟

پیشنهاد می‌کنم چالش این هفته را بصورت کامل از لینک زیر مطالعه کنید:


لینک به چالش شماره 14: 👇

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

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

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

https://t.iss.one/DomainDrivenDesign_ir