📚 لیست منابع برای مطالعه بیشتر

1. کتاب Radical Candor
مدیریت انسانی، بازخورد صادقانه و محترمانه
🔗 https://www.radicalcandor.com/the-book

2. مقاله "Communication is The Job"
نوشته‌ی اندرو بوسورث (CTO متا) – اهمیت نقش ارتباطات در تیم‌ها
🔗 https://boz.com/articles/communication-is-the-job

3. پادکست WeAreNetflix – موضوع: Feedback
گفتگو درباره فرهنگ بازخورد در نتفلیکس
🔗 https://www.youtube.com/watch?v=M-NYcfyVMeU

4. ویدیو: 5 درس برتر رید هستینگز، مدیرعامل نتفلیکس
🔗 https://www.youtube.com/watch?v=BH-Dq50Cz8Q

5. سخنرانی Patty McCord – Creating High Performance Culture (Talks at Google)
🔗 https://www.youtube.com/watch?v=thzDy5A-KfE

6. Netflix’s Engineering Culture
پست / پادکست گرگ اوروز با CTO نتفلیکس، الیزابت استون
🔗 https://newsletter.pragmaticengineer.com/p/netflix

7. Sustaining a Day 1 Culture – Amazon
سخنرانی بث گالتی (Amazon SVP HR)
🔗 https://www.youtube.com/watch?v=oq69KKpq0b0

8. How Netflix builds a culture of excellence – Lenny’s Podcast
گفتگو با الیزابت استون (CTO)
🔗 https://www.youtube.com/watch?v=2XgU6T4DalY

📺How AI will change Software Engineering?

Hosted by Gergely Orosz from The Pragmatic Engineer with Martin Fowler

🔹Abstract:
In this episode, they discuss how AI is changing software development: the shift from deterministic! to non-deterministic! coding; where generative models help with legacy code; and the narrow but useful cases for vibe coding. Martin explains why LLM output must be tested rigorously, why refactoring is more important than ever, and how combining AI tools with deterministic techniques may be what engineering teams need.

They also revisit the origins of the Agile Manifesto and talk about why, despite rapid changes in tooling and workflows, the skills that make a great engineer remain largely unchanged.

🔵 Watch the video:
https://www.youtube.com/watch?v=CQmI4XKTa0U

🎬 ویدئوی رویداد: Exploratory Domain Discovery - Live Demo

🔵 معرفی کوتاه: Exploratory Domain Discovery(EDD) یک رویکرد مدل‌سازی و طراحی مشارکتی است که با شروع از نتیجه (Outcome) مورد انتظار از سیستم، فضای مسئله را به صورت معکوس (Backward) مدل‌سازی می‌کند.

این رویکرد با داشتن متدولوژی منحصر به فرد خود، ابزاری قدرتمند برای فهم و مدل‌سازی دامنه‌های پیچیده به شمار می‌رود. EDD یک روش تجربی و سریع است که به ما کمک می‌کند تا کلیدی‌ترین مفاهیمی که نقشی اساسی در طراحی و مدل‌سازی فضای مسئله دارند را کشف کنیم.

اجزای سازنده اصلی EDD (ساده و کم‌تعداد):
🔹 کارت مفهوم دامنه (Domain Concept)
🔹 ارتباطات بین مفاهیم دامنه
🔹 کارت مثال (Example) به ازای هر مفهوم دامنه
🔹 کارت سوال یا چالش
🔹 کارت قانون کسب‌وکار (Business Rule)

🎙 محتوای این رویداد:
مسعود بهرامی در این رویداد، ضمن معرفی کامل EDD، به صورت عملی و زنده (Live Demo) نشان داد که چطور می‌توان از این رویکرد برای مدل‌سازی یک دامنه پیچیده بهره برد.

خبر خوب برای علاقه‌مندان: در وبینار بعدی به صورت زنده نشان خواهیم داد که EDD چگونه می‌تواند در مرحله طراحی سیستم (System Design) به ما کمک کند.

لینک تماشای کامل ویدئو: 👇
https://www.youtube.com/watch?v=brMtD9s7Ne4&t

💭 سؤال گروهی امروز:
مسئله‌که در ادامه مطرح میشه، شاید کمی عجیب یا حتی بدیهی به نظر برسه در نگاه اول، اما کمی که غرق مسئله‌اش بشیم خواهیم دید که اینطوری هم فکر میکنیم نیست...

تو پروژه‌های مختلف، وقتی می‌خواید دامنه یک مسئله را درک کنید، معمولاً روی کدام تمرکز می‌کنید؟

🔹جمع‌آوری نیازها (Requirements) از بیزنس و ذینفعان، مثل لیست فیچرها، KPIها، محدودیت‌ها و توقعات مدیر محصول

🔹ساخت و تثبیت زبان مشترک دامنه (Ubiquitous Language) بین تیم توسعه و بیزنس، یعنی همه درباره مفاهیم کلیدی دامنه با یک زبان واحد حرف بزنند و مدل ذهنی مشترک شکل بگیره

💡 تفاوت دیدگاه‌ها در اینجا مطرح هست. برخی معتقدند:

🔵 اول باید Requirements کامل فهمیده شود و بعد سراغ مدل‌سازی و زبان مشترک رفت.

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

❓ پرسش برای بحث:
- آیا بدون زبان مشترک می‌توانیم Requirements واقعی را درست بفهمیم؟
- یا بدون جمع‌آوری نیازها، زبان مشترک دقیقی شکل نمی‌گیرد؟


🔹 تجربه شما چیست و شما کدام رو برای شروع ترجیح می‌دهید؟ توی گروه کانال می‌تونید نظرات و تجربیاتتون رو به اشتراک بگذارید

پنج‌شنبه‌ی گذشته توی یک ورکشاپ خصوصی طراحی شی‌ءگرا که سهیل کرمی برگزار کرده بود شرکت کردم. قرار بود بازی Catan رو یاد بگیریم، مدل کنیم و طراحی کنیم.

برای من که تجربه‌ی زیادی در بازی‌های اینچنینی ندارم، دنیای این بازی واقعاً پیچیده بود و طبیعتاً مدل‌سازی‌ش هم همینطور 😋😏
اما جذاب‌ترین بخش ماجرا همکاری دولوپرهایی بود با تجربه‌های متفاوت از نظر quantity، quality و depth و اینکه چطور با هم توی مدل‌سازی یک مسئله‌ی پیچیده همکاری می‌کردند.

بچه‌ها مشغول بازی شدن، دیاگرام می‌کشیدن، تست‌کیس می‌نوشتن، حرف می‌زدن، کد می‌زدن و دوباره اصلاح می‌کردن.
میز و کد ظرف چند دقیقه تبدیل شد به جنگلی از اسم‌ها(تا جایی که حضور ذهن دارم!):
Hexagon, Tile, Board, Player, Road, Dice, City, Village, Wood, Brick, Sheep, … 🌪

و خیلی زود این جنگل از اسم‌ها باعث یک سردرگمی مشترک شد:
🔴 پیدا کردن مسیر طراحی بین یک عالمه اسم و رابطه‌ی احتمالی.

توی چنین لحظه‌هایی یک اصل ساده همیشه به من کمک کرده، و همونجا پیشنهاد دادم امتحانش کنن:

از مفاهیم Active شروع کنید، نه Passive
خیلی خلاصه اگر بخوام بگم.
🔹 مفاهیم Passive در دامنه چیزهایی هستند که هیچ جریان فعالی را شروع نمی‌کنند. مدل می‌شوند، یک جایی قرار می‌گیرند، و منتظر می‌مانند تا توسط یک use case دیگر تریگر شوند. معمولاً اطلاعات پایه و context را شکل می‌دهند. مثلاً در حسابداری: Account، Currency، CostCenter

🔹 مفاهیم Active در نقطه مقابل قرار دارند، چیزهایی که اتفاق را رقم می‌زنند. رفتار ایجاد می‌کنند، تصمیم می‌گیرند و بقیه اجزا را به هم وصل می‌کنند. مثلاً: PostTransaction, TransferMoney, PlaceOrder, BookAppointment

حتی در مثال Catan، شما اول Board و قطعات و مخلفاتش رو می‌سازید؛ اما تا وقتی Player شروع به بازی نکند، هیچ اتفاق معناداری نمی‌افتد. همون لحظه است که ارتباط مفاهیم آشکار می‌شود.

وقتی مدل‌سازی را از Active شروع می‌کنیم:

🔹 نقطه ورود روشن می‌شود
🔹 رفتار سیستم شکل می‌گیرد
🔹 ساختار و وابستگی‌ها به طور طبیعی کشف می‌شوند
🔹 به جای نمودارهای زیبا و بی‌معنی، یک سیستم زنده ساخته می‌شود
🔹 مدل‌سازی اسم‌ها نیست؛ مدل‌سازی اتفاق‌هاست
🔹این Behavior است که ساختار را می‌سازد، نه برعکس


خلاصه پیشنهادم برای دامنه‌های پیچیده یا ناشناخته:
✔️ از رفتار شروع کنید
✔️ طراحی را از مفاهیم Active آغاز کنید
✔️ اجازه دهید ساختار از دل اتفاق‌ها شکل بگیرد

📄 کل مقاله و مثال‌های بیشتر را اینجا بخوانید:
https://masoudbahrami.com/article/active-vs-passive-domain-concepts-in-designing-complex-domains/

🔔Design Time Exploratory Domain Discovery

در رویداد قبل، به‌صورت لایو و عملی نشان دادیم چطور می‌توان Exploratory Domain Discovery (EDD) را برای مدلسازی یک دومین پیچیده به‌کار برد.

در جلسه‌ی پیش‌رو، یک گام جلوتر خواهیم رفت و بررسی می‌کنیم که EDD چگونه می‌تواند در طراحی سرویس‌ها، تعیین مرزهای Bounded Context، ساخت Aggregates و ماژولار‌سازی سیستم نقش کلیدی داشته باشد.

در این جلسه به‌طور عملی خواهیم دید که EDD چگونه به موارد زیر کمک می‌کند:
✅ شفاف‌سازی مرزهای سرویس‌ها و باندد کانتکست‌ها
✅ بهبود طراحی اگریگیت‌ها و ساختار ماژولار سیستم
✅ اتخاذ تصمیم‌های طراحی بر اساس فهم مشترک و مشارکتی

📅 زمان: پنجشنبه 13 آذرماه 1404، ساعت 14:00 الی 15:30
🌐 محل: آنلاین – LinkedIn Live
💬 شرکت رایگان است

در این جلسه، با کمک EDD به‌صورت عملی طراحی سرویس‌ها و مدل‌سازی دامنه را بررسی خواهیم کرد و کاربرد آن در پروژه‌های واقعی را مرور می‌کنیم.

🔗 لینک رویداد(لطفاً دکمه Attend را بزنید)
linkedin.com/events/7400403756896399360/

🔗 اطلاعات بیشتر درباره EDD:
exploratorydomaindiscovery.com
🔗 مکتب‌خانه DDD:
domaindrivendesign.ir

سلام به همگی عزیزان
داریم برای لایو آماده میشیم. 🫰

با تشکر از همه عزیزانی که در لایو شرکت کردند.❤️

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

در نهایت هم لطفا فیدبک خودتون رو هم مطرح کنید این باعث میشه برنامه‌های بعدی خیلی بهتر طراحی و اجرا بشوند.


🟡🔴همانطور که جلسه قبل هم اشاره شد، همانند طرحی که سال گذشته اجرا کردیم، اگر تصمیم گرفتید EDD رو توی تیم خودتون اجرا کنید، می‌تونید پیام بدید، که در حد ۱-۲ جلسه، کارگاه رو براتون به عنوان facilitator برگزار کنیم. این اجرا هزینه‌ای برای شما نخواهد داشت.

دو نوع ورکشاپ متفاوت در Exploratory Domain Discovery وجود دارد:

ورکشاپ Discovery-Time EDD: این نوع برای مدلسازی فضای مسئله در یک دومین پیچیده استفاده می‌شود.

ورکشاپ Design-Time EDD: این ورکشاپ برای فاز طراحی و ترسیم مرزهای تفکیک دومین کاربرد دارد.

در رویداد زنده‌ی امروز، تمرکز ما بر Design-Time EDD بود. در این جلسه، چند رهیافت معرفی و بررسی شدند که می‌توانند در فرآیند Design-Time EDD مفید واقع شوند. این رهیافت‌ها به صورت خلاصه در زیر آمده‌اند:

🔵 Heuristic 1 – Invariants Define Boundaries
مرزها(خواه در سطح یک سرویس باشند و خواه در سطح طراحی یک AR) جایی ایجاد می‌شوند که یک قاعده همیشه باید برقرار باشد.

🔵 Heuristic 2 – Events Connect, Not Shared Data
مرزهای Bounded Context‌ها باید از طریق رویدادها با هم ارتباط برقرار کنند، نه با اشتراک داده‌ها یا جداول.

🔵 Heuristic 3 – High-Churn Areas Should Be Separate
بخش‌هایی از دومین که تغییرات زیادی دارند بهتر است در باوندد کانتکست جداگانه‌ای قرار بگیرند.

🔵 Heuristic 4 – Model the Rules First, Not the Data
ابتدا با قواعد کسب‌وکار شروع کنید و سپس داده‌ها را اضافه کنید. در غیر این صورت، Aggregate حجیم و ناکارآمد خواهد شد.

🔵 Heuristic 5 – Focus on Flow of Value (Not Components)
پرسش کنید: ارزش کجا ایجاد، تبدیل و تحویل داده می‌شود؟

🔵 Heuristic 6 – Each Aggregate Protects Only One Critical Consistency Rule
یک Aggregate که چندین قاعده‌ی حیاتی را اعمال کند، Aggregate شکست خورده‌ای است(تصحیح می‌کنم :)).

🔵 Heuristic 7 – Domain Circular Pattern: Finding Natural Boundaries

🔵 Heuristic 8 – Ubiquitous Language: Why Words Matter

برای مطالعه‌ی کامل‌تر و جزئیات بیشتر درباره‌ی Design-Time EDD، می‌توانید به لینک‌های زیر مراجعه کنید:
🔹 Introducing Design-Time EDD

🔹 EDD Heuristics for Design-Time

🔵 Clean Code Mastery – Advanced Software Craftsmanship Workshop


در سال‌های اخیر، بسیاری از تیم‌ها با رشد پروژه و اضافه‌شدن فیچرها، به‌جای سرعت بیشتر، با کدهای سنگین، سخت‌خوان، پر از بدهی فنی و توسعه‌پذیری پایین روبه‌رو شده‌اند. از Refactorهای پرهزینه گرفته تا باگ‌هایی که در ساده‌ترین تغییرات ظهور می‌کنند.

تقریباً تمام تیم‌ها در نقطه‌ای از مسیر توسعه، با یک حقیقت تلخ روبه‌رو می‌شوند:
مشکل اصلی، زبان برنامه‌نویسی یا تکنولوژی‌ها نیست، کیفیت کدی است که هر روز تولید می‌شود. حتی در حضور و ظهور AI.

⚪️ ویژگی‌های کلیدی دوره:
🔹آموزش عملی Clean Code، Refactoring، Design Principles و معماری تمیز
🔹تمرین‌های واقعی روی کدهای Legacy
🔹شناسایی و حذف Code Smellها در پروژه‌های واقعی
🔹کارگروهی، Code Review، PR Workflow و تحلیل مشکلات واقعی تیم‌ها
🔹آشنایی با معماری‌های Clean/Hexagonal و رویکرد DDD در سطح کاربردی
🔹یادگیری TDD، Unit/Integration Testing و طراحی Evolvable Code


📅ساختار دوره:
۵ جلسه تخصصی × ۴ ساعت
یک جلسهٔ Hands-on عملی + Q&A

برای جزئیات کامل و ثبت‌نام:
🔗domaindrivendesign.ir

🌟 رویداد پنجم نقطه:
شفافیت در کار تیمی: چطور بگوییم چه می‌خواهیم؟
نقطه به ایستگاه ششم خود (ایندکس پنجم!) رسید.

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

گاهی در هیاهوی زندگی و روزمرگی‌های کاری، حرف‌هایمان در ذهن‌مان گم می‌شوند. بیایید لحظه‌ای توقف کنیم، گوش دهیم و با هم هم‌کلام شویم؛ دور از شلوغی‌ها و دغدغه‌های روزانه، فرصتی برای تبادل نظر و اشتراک تجربه‌هایمان با یکدیگر.

🗓 تاریخ: سه‌شنبه، 25 آذر ۱۴۰۴
🕖 زمان: ۱۹:۰۰ – ۲۰:۳۰
💻 مکان: آنلاین(لینک رویداد برای افراد بعدا ارسال خواهد شد)

🔗 ثبت‌نام: https://luma.com/kkyijah7

سلام به همگی👋
برنامه در حال شروع هست

خیلی خیلی ممنون و سپاسگزارم از همه بچه هایی که اومدن و نظراتشون رو شیر کردند. خیلی جلسه خوبی بود. می‌طلبه یه جلسه دیگه رو هم کمی مشخص‌تر باز به همین موضوع بپردازیم

🍉✨ شب یلداتون مبارک ✨🍉

صحبتِ حُکام، ظلمتِ شبِ یلداست
نور ز خورشید جوی، بو که برآید


امشب،
شبِ موندنِ نور در دلِ تاریکیه
شبِ قصه، انار،
و صبری که به صبح ختم می‌شه.

امید که این شب بلند،
با دل‌های روشن،
خنده‌های گرم
و امید به فردایی روشن‌تر
به خیر و خوشی بگذره 🌱

یلداتون پر از مهر و روزهاتون کوتاه از غم 🍀

مکتب‌خانه DDD
https://news.1rj.ru/str/DomainDrivenDesign_ir