🔵 اطلاعیه برگزاری کارگاه آموزشی حضوری Exploratory Domain Discovery

انجمن DDD ایران، کارگاه آموزشی Exploratory Domain Discovery را در تاریخ‌های ششم و هفتم دی ماه سال ۱۴۰۳ برگزار خواهد کرد.

🔵 مدرس: مسعود بهرامی
🔵 تاریخ برگزاری: 6 و 7 دی‌ماه 1403 (پنجشنبه و جمعه)
🔵 ساعت: 9:30 صبح تا 17:00
🔵 مکان: شرکت آسان پرداخت پرشین


🔶 این کارگاه برای مدیران محصول، تحلیلگران کسب‌وکار، توسعه‌دهندگان نرم‌افزار و علاقه‌مندان به حوزه مدل‌سازی و طراحی سیستم‌ها مناسب است.

رویکرد Exploratory Domain Discovery یک رویکرد Collaborative Modelling and Designing است که توسط مسعود بهرامی طراحی شده است. با کمک EDD، می‌توانید درک عمیق‌تری از نیازهای کسب‌وکار خود پیدا کرده و مدل‌های دقیق‌تری برای حل فضای مسئله‌های پیچیده ایجاد کنید.

🔴 کارگاه آنلاین نیز به زودی اطلاع رسانی خواهد شد.

برای کسب اطلاعات بیشتر با @masodbahrami تماس بگیرید.

📖 آموزش Event Sourcing | بخش دوازدهم
💡مقدمه‌ای بر الگوی Inbox-Outbox

الگوی Inbox-Outbox به توسعه‌دهندگان یک سرویس کمک می‌کند تا بتوانند eventها را به صورت قابل اطمینان به دنیای بیرون از سرویس خود ارسال کنند. به بیان دیگر مهمترین مزیت و البته دلیل وجودی الگوی Inbox-Outbox تضمین at-least-once-delivery است. Inbox-Outbox الگویی است که برای مدیریت ارتباطات بین سرویس‌ها در معماری مبتنی بر Event Sourcing به کار می‌رود.

در این الگو، هر سرویس یک صندوق ورودی (Inbox) و یک صندوق خروجی (Outbox) دارد. پیاده سازی این صندوق‌ها می‌تواند به طرق مختلفی انجام شود. هر سرویس رویدادهایی قصد دارد به دنیای بیرون مخابره کند را ابتدا درون صندوق خروجی(outbox) خود قرار می‌دهد. این صندوق غالبا بصورت یک صف(Queue) ساده بدون اولویت پیاده‌سازی می‌شود. همچنین رویدادهایی که هر سرویس به آنها علاقمند است نیز درون صندوق ورودی آن سرویس نگه‍‌داری می‌شود. این صندوق هم بصورت پیش‌فرض یک صف(Queue) ساده بدون اولویت پیاده‌سازی است.

در شماره دوازدهم از سری آموزش‌های ایونت‌سورسینگ به معرفی الگوی Inbox-Outbox پرداختم:

http://domaindrivendesign.ir/event-sourcing-12-inbox-outbox-pattern-intro/

EventSourcing | Part 12

هشتگ:
#EventSourcing #ایونت_سورسینگ #آموزش_event_sourcing

@DomainDrivenDesign_ir

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

با سپاس از استقبال بی‌نظیر شما همراهان گرامی، انجمن 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

“Specification by Example” by Example

آن یکی شیر است که آدم میخورد
آن یکی شیر است که آدم میخورد

کان یکی شیر است اندر بادیه
کان یکی شیر است اندر بادیه

ابیات بالا منتسب به حضرت مولانا و از مجموعه داستان طوطی و بقال برگزیده شده.

اگر به اعجاز ابیات بالا نگاه کنیم میبینیم که کلمات شیر در دو مصرع اول، و بادیه(معنای کاسه) در دو‌ مصرع دوم، چگونه به زیبایی بکار گرفته شده اند.

شاعر در اینجا به زیبایی از صنایع ادبی استفاده کرده و شاهکاری ادبی خلق کرده.

از زاویه‌ای دیگر اما، با نگاهی دقیق‌تر به شعر بالا، این شعر بهمون نشون می‌ده که برای جلوگیری از اشتباه و ابهام، باید مفاهیم رو دقیق و واضح تعریف کنیم. همونطور که "شیر" در این شعر دو معنی کاملاً متفاوت داره، ایضا “بادیه”، در تعریف ویژگی‌های محصول باید از بکار بردن عمدی یا سهوی این صنایع ادبی جدا خودداری کنیم.

‌
رویکرد Specification by Example با همین هدف به وجود اومده: به جای تعریف‌های انتزاعی، با مثال‌های ملموس و قابل فهم، رفتار سیستم رو مشخص می‌کنیم و نشون میدیم که دقیقاً چطور باید کار کنه تا از هرگونه ابهامی جلوگیری بشه. ما از با کمک ارائه مثال‌های ملموس، ساده، و مشخص، ویژگی(specification) و بصورت کلی چیزی که در ذهن داریم رو مشخص میکنیم.

فرض کنید میخوایم یک ماشین حساب ساده را طراحی کنیم. اسم این ماشین حساب را "حسابچی" میذاریم. "حسابچی" باید عملیات اصلی ریاضی مثل جمع، تفریق، ضرب و تقسیم رو انجام بده.

برای تعریف دقیق نحوه عملکرد جمع در "حسابچی"، از رویکرد Specification by Example استفاده میکنیم. به این ترتیب، با ارائه مثالهای مشخص، انتظاراتمون رو از ویژگی جمع بیان میکنیم. این کار رو به صورت یک مکالمه بین دو نفر، تقی و نقی، نشون میدم:

مکالمه بین تقی و نقی:

تقی: خب، برای جمع تو "حسابچی" اول از یه چیز خیلی ساده شروع کنیم: ۲ + ۲، جوابش میشه ۴، درسته؟

نقی: آره، این که خیلی واضحه. جمع دو تا عدد صحیح و مثبت.

تقی: حالا یه کم بزرگترش کنیم: ۲ + ۱۰، میشه ۱۲.

نقی: اوکی، اینم مثل قبلیه. فقط اعداد بزرگتر شدن.

تقی: حالا ۲ + ۱۲۵۰ رو امتحان کن.

نقی: خب، اینم میشه ۱۲۵۲. پس "حسابچی" باید از اعداد صحیح بزرگ هم پشتیبانی کنه.

تقی: دقیقاً. حالا فرض کن بخوایم اعداد اعشاری رو هم جمع کنیم. مثلاً ۲ + ۱۰.۲.

نقی: خب، این میشه ۱۲.۲. پس "حسابچی" باید اعداد اعشاری رو هم در نظر بگیره.

تقی: عالیه. حالا یه کم پیچیده‌ترش کنیم. ۲ + ۱۰.۲ + ۲۵ چی؟ یعنی سه تا عدد رو با هم جمع کنیم.

نقی: این میشه ۳۷.۲. پس "حسابچی" باید بتونه چند تا عدد رو هم با هم جمع کنه، حتی اگه اعشاری باشن.

تقی: آفرین. حالا یه چیز دیگه. ۲ + ۲ + (۲ * ۲) رو حساب کن. اینجا یه عبارت ریاضی داریم که هم جمع داره و هم ضرب.

نقی: خب، طبق قواعد ریاضی، اولویت با ضربه، پس ۲ ضربدر ۲ میشه ۴، بعدش با ۲ و ۲ جمع میشه که میشه ۸. پس "حسابچی" باید از عبارات ریاضی (expressions) و تقدم عملگرها هم پشتیبانی کنه. یعنی بدونه اول ضرب رو حساب کنه بعد جمع رو.

تقی: دقیقاً همینطوره.

همانطور که مشاهده کردید، در این روش با ارائه مثالهای ملموس و گام به گام، ویژگیهای سیستم را مشخص کردیم.

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

📍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