با سلام و احترام

با سپاس از استقبال بی‌نظیر شما همراهان گرامی، انجمن DDD ایران مفتخر است که سومین جلسه از سری کارگاه‌های Exploratory Domain Discovery را برگزار نماید.

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

🔵 مدرس: مسعود بهرامی
🔵 برگزارکننده: انجمن DDD ایران
🔵 محل برگزاری: تهران (حضوری)


برای کسب اطلاعات بیشتر می‌توانید از طریق اکانت تلگرام @masodbahrami با ما در ارتباط باشید.

لینک پیش‌ ‌ثبت‌نام:

https://docs.google.com/forms/d/e/1FAIpQLScaOq56nhLe6-e5ZbeVwwOl3NX7taJ-A72kgVKzY15XqCm72g/viewform?usp=header

Are consciousness and intelligence the same?
Why does it matter to distinguish them?

https://www.youtube.com/watch?v=1rtS2OEV6bM

I Hate Value Objects
Value Objects: A Barrier to DDD. 🔵⚡Descriptor Data to the Rescue
Part 1


I wrote a new article. I revealed my thoughts on one of the most confusing issues in the tactical world of DDD. Read it 👇

https://masoudbahrami.substack.com/p/i-hate-value-objects

📍Domain Driven Design Roadmap 🗺 🗾 📖

As a DDD instructor, I’ve often been asked to provide a roadmap for learning Domain Driven Design. Despite attempts, the vast scope of DDD, combined with the diverse backgrounds of people—such as product managers, developers, architects—means many roadmaps don’t cover its complexities. DDD spans both strategic and technical aspects, making it challenging to create a comprehensive roadmap for everyone.

To address this, I’ve created an initial version (0.0.1)! This roadmap guides learners through all levels of DDD, from concepts to advanced practices. Whether you’re starting with DDD or deepening your expertise, it offers structured paths for different stages of learning.

Link to the repo:👇
https://github.com/masoud-bahrami/domain-driven-design-roadmap

Domain Driven Design Roadmap 🗺

A guided journey through DDD, covering essential concepts and advanced topics.


Here’s a brief overview of the roadmap's structure:

-------------------------------------------------------

Why Domain-Driven Design?🤔
I. Pre-DDD Context for Different Roles 🧩
II. Glossary of Terms 📖🔤 Domain Jargon Demystified
III. Level 1: DDD Fundamentals 🌱
IV. Level 2: Collaborative Modeling and Designing 🤝
V. Level 3: Strategic Design ♟️
VI. Level 4: Tactical Design and Implementation🏗️
VII. Level 5: Architecture and DDD 🏛️🧩🏗️
XIII. Level 6: Domain-Driven Design with Event Sourcing and CQRS🌊💾
XXX. Measuring Success with DDD ✅📈
IX. Level 8: DDD and Programming Paradigms 💻⚙️🧩
X. Level 9: Advanced and Emerging Topics 🔮
XI. Level 10: Team Topologies and DDD 🧑‍🤝‍🧑🏢🤝
XII. Level 11: Strategic Analysis with Wardley Mapping and Related Techniques 🗺️📈🧭
XIII. Level 12: Visualizing DDD: Canvases for Collaboration and Clarity 🖼️🤝
XIV. Level 13: Supple Design: Techniques for Evolving Domain Models 🌿🌊🔄
XIV. Level 14: Breakthrough Refactoring: Refactoring Towards Deeper Insight 🚀💡
XV. Level 15: Scaling DDD 🚀🏢
XVI. Level 16: Dealing with Legacy Systems in DDD 🏛️➡️🔄
XVII. Level 17: Anti-Patterns in DDD 🚫🚧 Common Mistakes to Avoid
XVIII. Level 18: Practical Tools and Checklists for DDD 🛠️✅📝
XIX. Tools (Optional 🧰🛠️)

Software Architecture vs. Design Patterns


Simply put, both software architecture and design patterns are essential for good software. Architecture is the big picture, the overall structure. Design patterns are solutions to smaller, local problems. Understanding the difference is key for any software developer.


https://masoudbahrami.medium.com/software-architecture-vs-design-patterns-6ceb535cf9c9

What if you could treat dates and times as data in C# and Java?🤨

Are you looking for a better way to handle dates and times?

I'm exploring a homoiconic approach and developing a library to simplify date and time handling



https://medium.com/p/homoiconicity-inspired-date-time-handling-in-c-sharp-f38c7cf8704e

چالش‌های معماری نرم‌افزار و تصمیمات سخت 🚀


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

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

او همچنین به تشریح نحوه‌ی تحلیل‌های تعویض در معماری، ابزارهایی چون لیست‌های MECE (Mutually Exclusive, Collectively Exhaustive) و روش‌هایی برای تفکیک سرویس‌ها به منظور دستیابی به دقت مناسب خواهد پرداخت.

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

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

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


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

Introducing (Domain)Language-First Architecture

Imagine an architecture where the very language of your domain is the foundation upon which your software is built. This is the core principle of Language-First Architecture. As you can see in the diagrams, at the heart of LFA is Language itself. It's not just about using domain language in communication; it's about making it the blueprint for your system.

📌Introducing (Domain)Language-First Architecture

Imagine an architecture where the very language of your domain is the foundation upon which your software is built. This is the core principle of Language-First Architecture.

✅ As you can see in the diagrams, at the heart of LFA is Language itself. It's not just about using domain language in communication; it's about making it the blueprint for your system.

✅ Surrounding the Language core is the Model. Here, the domain language is transformed into concrete data structures and business rules, directly reflecting the language's vocabulary and grammar.

✅ Expanding further, we have the Context. This layer represents the environment in which the system operates, encompassing user interactions and external dependencies. It's where the language's meaning is understood within the system's real-world application.

✅ Finally, the Logic layer is the outermost shell. It's where the magic happens – where the domain language is processed and executed, driving the system's behavior.

The small squares you see represent the interaction points with the outside world – APIs, databases, user interfaces – all communicating with the system in the language it understands best.

Start with words: Use the same words your business uses every day.
Words make the rules: These words decide how the software works.

📌 چهار ضلع طراحی نرم‌افزار: زبان، مدل، متخصصان دامنه، و کد

وقتی از طراحی نرم‌افزار حرف می‌زنیم، خیلی‌ها سریع می‌رن سراغ معماری، فریم‌ورک، یا ساختارهای کدی. ولی اصل ماجرا از یه جای دیگه شروع می‌شه: مدل. مدلی که قراره بین آدم‌ها و کد یه پل بزنه، و ریشه‌ش توی دنیای واقعی باشه.
تو رویکرد DDD، مدل فقط یه دیاگرام نیست؛ یه گفت‌وگوی زنده‌ست، یه ابزار برای درک و بازنمایی مسئله — نه صرفاً راه‌حل.

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

💬 مدل‌سازی یه فرایند لحظه‌ای نیست، یه مسیر تدریجیه. وسط گفت‌وگوها شکل می‌گیره، توی برخورد با واقعیت‌ها اصلاح می‌شه، و دائم در حال تغییره. یک فرآیند Just-In-Time

💻 از طرف دیگه، کد هم ساکت نیست. وقتی مدل رو پیاده‌سازی می‌کنیم، کد بهمون می‌گه کجای مدل ساده‌سازی بیش از حد داشتیم یا کجا درک‌مون اشتباه بوده. حتی ممکنه راه‌حل‌های دیروزمون، الان خودشون مشکل‌زا شده باشن. در واقع، کد تبدیل می‌شه به آیینه‌ی مدل — همون‌قدر که مدل راهنمای کده، کد هم راهنمای مدل می‌شه.

♻️ این تعامل بین چهار ضلع طراحی نرم‌افزار — زبان، مدل، متخصصان دامنه و کد — یه چرخه‌ی بازخورد دائمی می‌سازه. چرخه‌ای که باعث می‌شه نرم‌افزار هم دقیق‌تر بشه، هم قابل نگهداری‌تر، و هم واقعاً به درد بخور.

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


http://domaindrivendesign.ir/the-four-angles-of-software-design/

تصور کنید می‌خواهید بفهمید یک سیستم حقوق و دستمزد آنلاین چطور کار می‌کند.

🟡 ایونت استورمینگ: چه اتفاقی چه زمانی می‌افتد؟ ⏰
مثل این است که یک جدول زمانی از تمام اتفاقات مهم در سیستم حقوق و دستمزد درست کنید.

⬅ تمرکز: ترتیب رویدادها.
⬅ شروع: اولین رویداد مهم چیست؟ شاید «اطلاعات کارمند ثبت شد». بعدش چی؟ «ساعت‌های کاری وارد شد». بعد چی؟ «حقوق محاسبه شد». بعد «پرداخت انجام شد».
⬅ شبیه: کشیدن یک نمودار جریان ساده از تمام مراحل کلیدی در پرداخت حقوق.


🔴 دومین استوری تلینگ: چه کسی چه کاری می‌کند؟ 👤⚙️

مثل این است که داستان‌های ساده‌ای درباره افرادی که با سیستم حقوق و دستمزد کار می‌کنند تعریف کنید.

⬅ تمرکز: چه کسی چه عملی انجام می‌دهد.
⬅ شروع: تصور کنید یک «مدیر منابع انسانی» «اطلاعات کارمند جدید» را «وارد سیستم می‌کند». این یک داستان است. تصور کنید «سیستم» به صورت خودکار «مالیات» را از «حقوق» «کسر می‌کند». این یک داستان دیگر است.
⬅ شبیه : درست کردن یک نوار خیلی ساده از داستان‌های فرآیندهای مختلف در سیستم است، که نشان می‌دهد افراد مختلف (مدیر منابع انسانی، کارمند، سیستم) چه کارهایی انجام می‌دهند.


🟢 Exploratory Domain Discovery:
نقطه کانونی و مرکزی و هسته‌ی اصلی در مسئله حقوق و دستمزد چیست؟ 🎯

مثل این است که بفهمید هدف اصلی این سیستم حقوق و دستمزد چیست.
⬅ تمرکز: هدف اصلی و مهم‌ترین چیز.
⬅ شروع: چرا این سیستم حقوق و دستمزد وجود دارد؟ شاید هدف اصلی «پرداخت دقیق و به موقع حقوق به کارمندان» باشد. بعد به این فکر می‌کنید که برای رسیدن به این هدف چه چیزهایی واقعاً ضروری است (اطلاعات کارمندان، اطلاعات مربوط به حقوق و دستمزد، محاسبات حقوق، فرایند پرداخت).
⬅ شبیه: کشیدن یک دایره ساده با ایده اصلی «پرداخت دقیق و به موقع حقوق»، و بعد کشیدن دایره‌های دیگر دور آن برای تمام مفاهیم مهم مرتبط (اطلاعات کارمند، قوانین مالیاتی، گزارش‌های حقوقی). هر زمان نیاز باشد میتوانیم زوم را در هر جای این دایره را بیشتر یا کمتر کنیم.


----------------------------

💡 در مجموع:
• ایونت استورمینگ: نشان می‌دهد مراحل پرداخت حقوق به چه ترتیبی انجام می‌شود.
• دامین استوری تلینگ: نشان می‌دهد چه کسی در فرایند پرداخت حقوق چه کاری انجام می‌دهد.
• EDD: کمک می‌کند بفهمید هدف اصلی سیستم حقوق و دستمزد چیست و مهم‌ترین بخش‌هایی که باید روی آن‌ها تمرکز کنید کدامند.

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

🔍 معرفی مختصر Exploratory Domain Discovery (EDD)

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

این رویکرد، ریشه در تفکر سیستماتیک و روایت‌محور دارد. درست مثل یک فیلم یا رمان که همه‌ی اتفاقات برای انتقال یک پیام اصلی طراحی شده‌اند، در دامنه‌ی یک نرم‌افزار هم بیشتر اجزای سیستم در خدمت یک «مفهوم کلیدی» یا همان Main Point هستند؛ چیزی که بدون آن، کل ساختار بی‌معنا می‌شود. در EDD ما تلاش می‌کنیم این نقطه‌ی مرکزی را پیدا کرده و روابط علّی و ساختارهای اطراف آن را کشف کنیم.

🌀 فرآیند اکتشاف در EDD به‌صورت چرخشی (Iterative) و عرضی (Breadth-First) انجام می‌شود. فرض کنید Main Point در مرکز یک‌سری دایره‌ی هم‌مرکز قرار دارد. در دور اول، تصویری کلی و انتزاعی از دامنه ساخته می‌شود. در دورهای بعدی، این دایره تنگ‌تر شده و وارد جزئیات بیشتری می‌شویم. این مدل‌سازی لایه‌لایه، کمک می‌کند پیچیدگی‌ها را بهتر درک کرده و رفتارهای تکرارشونده را بشناسیم.

✨ یکی از ویژگی‌های کلیدی EDD، روایت معکوس (Backward Storytelling) است — یعنی به‌جای اینکه با «از کجا شروع کنیم؟» آغاز کنیم، می‌پرسیم: «ته داستان چیست؟». این دیدگاه باعث می‌شود روابط علت و معلولی واضح‌تر و دقیق‌تر دیده شوند.


🧩 در EDD ما با سه ابزار اصلی کار می‌کنیم:

🟦 مفهوم Domain Concept: هر مفهوم کلیدی که در دامنه وجود دارد را روی یک کارت می‌نویسیم.

🔄 مفهوم Relation : رابطه‌ی بین این مفاهیم را مشخص می‌کنیم، از انتها به ابتدا.

📝 مفهوم Example : برای هر مفهوم، یک نمونه واقعی و قابل لمس می‌نویسیم تا فهم مشترک بین افراد تیم شکل بگیرد.

🎯 مثال کاربردی:

فرض کنید در حال تحلیل یک سیستم حقوق و دستمزد هستید.
از سؤال «ته داستان چیست؟» شروع می‌کنیم: مثلاً صدور فیش حقوقی خروجی نهایی است. آن را روی یک کارت مفهومی (domain concept) یادداشت می‌کنیم. سپس یک گام به عقب: فیش حقوقی حاصل محاسبه‌ی فرمول‌های حقوق است. این فرمول‌ها هم بر اساس کارکرد ماهانه‌ی کارمند محاسبه می‌شوند.
با همین روال، مفاهیم را از پایان به ابتدا کشف و یادداشت می‌کنیم. سپس روابط میان آن‌ها را (باز هم از انتها به ابتدا) ثبت می‌کنیم. در پایان، برای هر مفهوم یک مثال واقعی (concrete example) می‌نویسیم تا از درستی و شفافیت مدل اطمینان حاصل شود.

🧠 فلسفه‌ی EDD:

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

🔁 الگوهای رایج (Patterns):

• چرخه‌های زمانی مثل حقوق ماهیانه یا فرایند رزرو
• مفهوم کلیدی (Main Point) که سایر اجزای دامنه حول آن شکل می‌گیرند
• روایت معکوس برای کشف روابط علت و معلولی

✅ در نهایت اینکه:
EDD ابزارهای ساده‌ای داره — مثل کارت‌های مفهومی و مثال — اما قدرتش در طرز فکر پشتشه: اینکه قبل از ورود به طراحی یا کدنویسی، دقیقاً بفهمیم چه چیزی را طراحی می‌کنیم و چرا.

📎 اطلاعات بیشتر:
https://exploratorydomaindiscovery.com

-انجمن DDD ایران
@DDD_Iran