An informative and must-be-viewed presentation by Kent Beck on coach, coaching, and stuff like that
https://www.youtube.com/watch?v=LHgeNKGhZnE
https://www.youtube.com/watch?v=LHgeNKGhZnE
YouTube
What I Learned About Coaching in the Back of an Ambulance - Kent Beck
In this insightful kenote, prominent software engineer Kent Beck shares his unique journey from suffering a medical emergency that left him unable to speak, to redefining his coaching technique. Beck discusses the transformation he underwent, moving away…
👍2
چالش شماره 16 DDD Plus📣
چالش این هفته، شما رو به سمت مدل‌سازی یک سیستم رزرواسیون سفر با تمرکز بر نیازهای خاص یک شرکت (بانک) سوق می‌دهد. این چالش، درک عمیقی از مفاهیم کلیدی DDD مانند Bounded Context، Entities، Aggregates، و Value Objects را می‌طلبد.
چالش را بصورت کامل در زیر می‌توانید مشاهده و دنبال کنید:
لینک به چالش شماره 16: 👇
https://domaindrivendesign.ir/ddd-plus-16/
💬گروه بحث و تبادل نظر در مورد این چالش: 👇
https://t.iss.one/DomainDrivenDesignGroup
هشتگ:
#DDDP | #DDD_Plus | #dddp16
چالش این هفته، شما رو به سمت مدل‌سازی یک سیستم رزرواسیون سفر با تمرکز بر نیازهای خاص یک شرکت (بانک) سوق می‌دهد. این چالش، درک عمیقی از مفاهیم کلیدی DDD مانند Bounded Context، Entities، Aggregates، و Value Objects را می‌طلبد.
چالش را بصورت کامل در زیر می‌توانید مشاهده و دنبال کنید:
لینک به چالش شماره 16: 👇
https://domaindrivendesign.ir/ddd-plus-16/
💬گروه بحث و تبادل نظر در مورد این چالش: 👇
https://t.iss.one/DomainDrivenDesignGroup
هشتگ:
#DDDP | #DDD_Plus | #dddp16
❤3
Forwarded from Masoud Bahrami
The Dance Between Authors and Audiences
When audiences engage with a story, they're looking for the main point or message. To guide readers towards this understanding, authors often build suspense by starting with context and revealing the main point later.
Every software has a story. The story is the domain of that software. So every software or every domain has a main point, covered by a vast majority of information serving as its context.
As software developers, We are the authors of the story not the audiences. So it is crucial to start with the main point and provide and design the context based on the main idea.
As software developers, we're not simply reading a story; we're writing it. It's essential to begin with the core purpose of the software and then design the features and functionalities to support that purpose.
When audiences engage with a story, they're looking for the main point or message. To guide readers towards this understanding, authors often build suspense by starting with context and revealing the main point later.
Every software has a story. The story is the domain of that software. So every software or every domain has a main point, covered by a vast majority of information serving as its context.
As software developers, We are the authors of the story not the audiences. So it is crucial to start with the main point and provide and design the context based on the main idea.
As software developers, we're not simply reading a story; we're writing it. It's essential to begin with the core purpose of the software and then design the features and functionalities to support that purpose.
❤7
Forwarded from Masoud Bahrami
Obviously!
Understanding that my understanding might be wrong is essential.
Understanding that my understanding might be wrong is essential.
👍4
Forwarded from انجمن DDD ایران
🔵 اطلاعیه برگزاری کارگاه آموزشی حضوری Exploratory Domain Discovery
انجمن DDD ایران، کارگاه آموزشی Exploratory Domain Discovery را در تاریخ‌های ششم و هفتم دی ماه سال ۱۴۰۳ برگزار خواهد کرد.
🔵 مدرس: مسعود بهرامی
🔵 تاریخ برگزاری: 6 و 7 دی‌ماه 1403 (پنجشنبه و جمعه)
🔵 ساعت: 9:30 صبح تا 17:00
🔵 مکان: شرکت آسان پرداخت پرشین
🔶 این کارگاه برای مدیران محصول، تحلیلگران کسب‌وکار، توسعه‌دهندگان نرم‌افزار و علاقه‌مندان به حوزه مدل‌سازی و طراحی سیستم‌ها مناسب است.
🔴 کارگاه آنلاین نیز به زودی اطلاع رسانی خواهد شد.
برای کسب اطلاعات بیشتر با @masodbahrami تماس بگیرید.
انجمن DDD ایران، کارگاه آموزشی Exploratory Domain Discovery را در تاریخ‌های ششم و هفتم دی ماه سال ۱۴۰۳ برگزار خواهد کرد.
🔵 مدرس: مسعود بهرامی
🔵 تاریخ برگزاری: 6 و 7 دی‌ماه 1403 (پنجشنبه و جمعه)
🔵 ساعت: 9:30 صبح تا 17:00
🔵 مکان: شرکت آسان پرداخت پرشین
🔶 این کارگاه برای مدیران محصول، تحلیلگران کسب‌وکار، توسعه‌دهندگان نرم‌افزار و علاقه‌مندان به حوزه مدل‌سازی و طراحی سیستم‌ها مناسب است.
رویکرد Exploratory Domain Discovery یک رویکرد Collaborative Modelling and Designing است که توسط مسعود بهرامی طراحی شده است. با کمک EDD، می‌توانید درک عمیق‌تری از نیازهای کسب‌وکار خود پیدا کرده و مدل‌های دقیق‌تری برای حل فضای مسئله‌های پیچیده ایجاد کنید.
🔴 کارگاه آنلاین نیز به زودی اطلاع رسانی خواهد شد.
برای کسب اطلاعات بیشتر با @masodbahrami تماس بگیرید.
❤3
Forwarded from انجمن DDD ایران
🔵اولین جلسات رسمی از کارگاه Exploratory Domain Discovery با استقبال خوبِ نزدیک به ۶۰ نفر، پنجشنبه و جمعه به میزبانی مجموعه آسان پرداخت پرشین برگزار شد. Exploratory Domain Discovery یک رویکرد Collaborative Modelling است که توسط مسعود بهرامی معرفی شده، و این اولین باری بود که بدین شکل مدون و رسمی ارائه می‌شد.
این کارگاه فرصتی مناسب برای شرکت کنندگان شامل برنامه نویسان و تحلیلگران و مدیران محصول بود تا با مفاهیم و تکنیک‌های EDD آشنا بشن. حضور پرشور نزدیک به ۶۰ شرکت‌کننده نشون داد که این موضوع چقدر برای جامعه تخصصی مهمه و به ما انگیزه داد که این کارگاه‌ها را بیشتر و بهتر برگزار کنیم.
نکته‌ی ویژه‌ای که باید بهش اشاره کنیم، تقدیم این کارگاه به دو بانوی دانشمند برجسته و الهام‌بخش بود. کارگاه روز پنجشنبه رو به یاد و خاطره‌ی ارزشمند رزالیند فرانکلین، شیمی‌دان برجسته‌ای که نقش حیاتی در کشف ساختار DNA داشت، و کارگاه روز جمعه رو به مریم میرزاخانی، ریاضیدان نابغه و اولین زن برنده‌ی مدال فیلدز، تقدیم کردیم.
🟡کارگاه بعدی نیز به زودی اعلام رسانی خواهد شد.
🔴به زودی گزارش کاملی از هر دو روز منتشر میکنیم.
@DDD_IRAN
این کارگاه فرصتی مناسب برای شرکت کنندگان شامل برنامه نویسان و تحلیلگران و مدیران محصول بود تا با مفاهیم و تکنیک‌های EDD آشنا بشن. حضور پرشور نزدیک به ۶۰ شرکت‌کننده نشون داد که این موضوع چقدر برای جامعه تخصصی مهمه و به ما انگیزه داد که این کارگاه‌ها را بیشتر و بهتر برگزار کنیم.
نکته‌ی ویژه‌ای که باید بهش اشاره کنیم، تقدیم این کارگاه به دو بانوی دانشمند برجسته و الهام‌بخش بود. کارگاه روز پنجشنبه رو به یاد و خاطره‌ی ارزشمند رزالیند فرانکلین، شیمی‌دان برجسته‌ای که نقش حیاتی در کشف ساختار DNA داشت، و کارگاه روز جمعه رو به مریم میرزاخانی، ریاضیدان نابغه و اولین زن برنده‌ی مدال فیلدز، تقدیم کردیم.
🟡کارگاه بعدی نیز به زودی اعلام رسانی خواهد شد.
🔴به زودی گزارش کاملی از هر دو روز منتشر میکنیم.
@DDD_IRAN
❤4👍2🙏1
📖 آموزش Event Sourcing | بخش دوازدهم
💡مقدمه‌ای بر الگوی Inbox-Outbox
در شماره دوازدهم از سری آموزشهای ایونت‌سورسینگ به معرفی الگوی Inbox-Outbox پرداختم:
https://domaindrivendesign.ir/event-sourcing-12-inbox-outbox-pattern-intro/
EventSourcing | Part 12
هشتگ:
#EventSourcing #ایونت_سورسینگ #آموزش_event_sourcing
@DomainDrivenDesign_ir
💡مقدمه‌ای بر الگوی Inbox-Outbox
الگوی Inbox-Outbox به توسعه‌دهندگان یک سرویس کمک می‌کند تا بتوانند eventها را به صورت قابل اطمینان به دنیای بیرون از سرویس خود ارسال کنند. به بیان دیگر مهمترین مزیت و البته دلیل وجودی الگوی Inbox-Outbox تضمین at-least-once-delivery است. Inbox-Outbox الگویی است که برای مدیریت ارتباطات بین سرویس‌ها در معماری مبتنی بر Event Sourcing به کار می‌رود.
در این الگو، هر سرویس یک صندوق ورودی (Inbox) و یک صندوق خروجی (Outbox) دارد. پیاده سازی این صندوق‌ها می‌تواند به طرق مختلفی انجام شود. هر سرویس رویدادهایی قصد دارد به دنیای بیرون مخابره کند را ابتدا درون صندوق خروجی(outbox) خود قرار می‌دهد. این صندوق غالبا بصورت یک صف(Queue) ساده بدون اولویت پیاده‌سازی می‌شود. همچنین رویدادهایی که هر سرویس به آنها علاقمند است نیز درون صندوق ورودی آن سرویس نگه‍‌داری می‌شود. این صندوق هم بصورت پیش‌فرض یک صف(Queue) ساده بدون اولویت پیاده‌سازی است.
در شماره دوازدهم از سری آموزشهای ایونت‌سورسینگ به معرفی الگوی Inbox-Outbox پرداختم:
https://domaindrivendesign.ir/event-sourcing-12-inbox-outbox-pattern-intro/
EventSourcing | Part 12
هشتگ:
#EventSourcing #ایونت_سورسینگ #آموزش_event_sourcing
@DomainDrivenDesign_ir
مکتب‌خانه DDD
آموزش Event Sourcing قسمت 12 | مقدمه‌ای بر الگوی Inbox-Outbox | مکتب‌خانه DDD
در بخش دوازدهم از سری آموزشهای event sourcing به معرفی الگوی Inbox-Outbox پرداختیم. این الگو در سیستم‌های توزیع شده جهت اطمینان از دریافت پیام‌ها توسط طرف مقابل نقش اساسی‌ای را بازی می‌کند...
❤4👍2
Forwarded from انجمن DDD ایران
با سلام و احترام
با سپاس از استقبال بی‌نظیر شما همراهان گرامی، انجمن DDD ایران مفتخر است که سومین جلسه از سری کارگاه‌های Exploratory Domain Discovery را برگزار نماید.
به منظور برنامه‌ریزی هرچه بهتر و پاسخگویی به نیازهای شما، خواهشمندیم فرم زیر را جهت نیازسنجی اولیه این کارگاه تکمیل فرمایید.
🔵 مدرس: مسعود بهرامی
🔵 برگزارکننده: انجمن DDD ایران
🔵 محل برگزاری: تهران (حضوری)
برای کسب اطلاعات بیشتر می‌توانید از طریق اکانت تلگرام @masodbahrami با ما در ارتباط باشید.
لینک پیش ثبت‌نام:
https://docs.google.com/forms/d/e/1FAIpQLScaOq56nhLe6-e5ZbeVwwOl3NX7taJ-A72kgVKzY15XqCm72g/viewform?usp=header
با سپاس از استقبال بی‌نظیر شما همراهان گرامی، انجمن DDD ایران مفتخر است که سومین جلسه از سری کارگاه‌های Exploratory Domain Discovery را برگزار نماید.
به منظور برنامه‌ریزی هرچه بهتر و پاسخگویی به نیازهای شما، خواهشمندیم فرم زیر را جهت نیازسنجی اولیه این کارگاه تکمیل فرمایید.
🔵 مدرس: مسعود بهرامی
🔵 برگزارکننده: انجمن DDD ایران
🔵 محل برگزاری: تهران (حضوری)
برای کسب اطلاعات بیشتر می‌توانید از طریق اکانت تلگرام @masodbahrami با ما در ارتباط باشید.
لینک پیش ثبت‌نام:
https://docs.google.com/forms/d/e/1FAIpQLScaOq56nhLe6-e5ZbeVwwOl3NX7taJ-A72kgVKzY15XqCm72g/viewform?usp=header
❤6
Are consciousness and intelligence the same?
Why does it matter to distinguish them?
https://www.youtube.com/watch?v=1rtS2OEV6bM
Why does it matter to distinguish them?
https://www.youtube.com/watch?v=1rtS2OEV6bM
YouTube
The Politics of Consciousness | video lecture with Yuval Noah Harari
What is consciousness? Who has consciousness? And why is it so dangerous to confuse it with intelligence? How does our understanding of consciousness impact the ethical, political and legal debates about abortion, animal rights and the legal status of AI?…
❤2👎1
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
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
Masoud’s Substack
I Hate Value Objects
Value Objects: A Barrier to DDD. Descriptor Data to the Rescue - Part 1
❤2👍1
“Specification by Example” by Example
ابیات بالا منتسب به حضرت مولانا و از مجموعه داستان طوطی و بقال برگزیده شده.
اگر به اعجاز ابیات بالا نگاه کنیم میبینیم که کلمات شیر در دو مصرع اول، و بادیه(معنای کاسه) در دو مصرع دوم، چگونه به زیبایی بکار گرفته شده اند.
شاعر در اینجا به زیبایی از صنایع ادبی استفاده کرده و شاهکاری ادبی خلق کرده.
از زاویه‌ای دیگر اما، با نگاهی دقیق‌تر به شعر بالا، این شعر بهمون نشون می‌ده که برای جلوگیری از اشتباه و ابهام، باید مفاهیم رو دقیق و واضح تعریف کنیم. همونطور که "شیر" در این شعر دو معنی کاملاً متفاوت داره، ایضا “بادیه”، در تعریف ویژگیهای محصول باید از بکار بردن عمدی یا سهوی این صنایع ادبی جدا خودداری کنیم.
رویکرد Specification by Example با همین هدف به وجود اومده: به جای تعریف‌های انتزاعی، با مثالهای ملموس و قابل فهم، رفتار سیستم رو مشخص میکنیم و نشون میدیم که دقیقاً چطور باید کار کنه تا از هرگونه ابهامی جلوگیری بشه. ما از با کمک ارائه مثالهای ملموس، ساده، و مشخص، ویژگی(specification) و بصورت کلی چیزی که در ذهن داریم رو مشخص میکنیم.
فرض کنید میخوایم یک ماشین حساب ساده را طراحی کنیم. اسم این ماشین حساب را "حسابچی" میذاریم. "حسابچی" باید عملیات اصلی ریاضی مثل جمع، تفریق، ضرب و تقسیم رو انجام بده.
برای تعریف دقیق نحوه عملکرد جمع در "حسابچی"، از رویکرد Specification by Example استفاده میکنیم. به این ترتیب، با ارائه مثالهای مشخص، انتظاراتمون رو از ویژگی جمع بیان میکنیم. این کار رو به صورت یک مکالمه بین دو نفر، تقی و نقی، نشون میدم:
مکالمه بین تقی و نقی:
همانطور که مشاهده کردید، در این روش با ارائه مثالهای ملموس و گام به گام، ویژگیهای سیستم را مشخص کردیم.
هر مثال، بر پایه مثال قبلی بنا شده و جنبه جدیدی از رفتار سیستم رو آشکار کرد. همین کار باعث شد که که همگی ذینفعان درک مشترکی از چیزی که قرار تولید کنند داشته باشند. این مثالها همینطور حکم proof-of-work کار نهایی رو هم دارند.
یعنی قبل از پیاده‌سازی هر خط کدی ما مکانیزم نهایی اعتبار سنجی سیستم رو بهش دست پیدا کردیم.
آن یکی شیر است که آدم میخورد
آن یکی شیر است که آدم میخورد
کان یکی شیر است اندر بادیه
کان یکی شیر است اندر بادیه
ابیات بالا منتسب به حضرت مولانا و از مجموعه داستان طوطی و بقال برگزیده شده.
اگر به اعجاز ابیات بالا نگاه کنیم میبینیم که کلمات شیر در دو مصرع اول، و بادیه(معنای کاسه) در دو مصرع دوم، چگونه به زیبایی بکار گرفته شده اند.
شاعر در اینجا به زیبایی از صنایع ادبی استفاده کرده و شاهکاری ادبی خلق کرده.
از زاویه‌ای دیگر اما، با نگاهی دقیق‌تر به شعر بالا، این شعر بهمون نشون می‌ده که برای جلوگیری از اشتباه و ابهام، باید مفاهیم رو دقیق و واضح تعریف کنیم. همونطور که "شیر" در این شعر دو معنی کاملاً متفاوت داره، ایضا “بادیه”، در تعریف ویژگیهای محصول باید از بکار بردن عمدی یا سهوی این صنایع ادبی جدا خودداری کنیم.
رویکرد Specification by Example با همین هدف به وجود اومده: به جای تعریف‌های انتزاعی، با مثالهای ملموس و قابل فهم، رفتار سیستم رو مشخص میکنیم و نشون میدیم که دقیقاً چطور باید کار کنه تا از هرگونه ابهامی جلوگیری بشه. ما از با کمک ارائه مثالهای ملموس، ساده، و مشخص، ویژگی(specification) و بصورت کلی چیزی که در ذهن داریم رو مشخص میکنیم.
فرض کنید میخوایم یک ماشین حساب ساده را طراحی کنیم. اسم این ماشین حساب را "حسابچی" میذاریم. "حسابچی" باید عملیات اصلی ریاضی مثل جمع، تفریق، ضرب و تقسیم رو انجام بده.
برای تعریف دقیق نحوه عملکرد جمع در "حسابچی"، از رویکرد Specification by Example استفاده میکنیم. به این ترتیب، با ارائه مثالهای مشخص، انتظاراتمون رو از ویژگی جمع بیان میکنیم. این کار رو به صورت یک مکالمه بین دو نفر، تقی و نقی، نشون میدم:
مکالمه بین تقی و نقی:
تقی: خب، برای جمع تو "حسابچی" اول از یه چیز خیلی ساده شروع کنیم: ۲ + ۲، جوابش میشه ۴، درسته؟
نقی: آره، این که خیلی واضحه. جمع دو تا عدد صحیح و مثبت.
تقی: حالا یه کم بزرگترش کنیم: ۲ + ۱۰، میشه ۱۲.
نقی: اوکی، اینم مثل قبلیه. فقط اعداد بزرگتر شدن.
تقی: حالا ۲ + ۱۲۵۰ رو امتحان کن.
نقی: خب، اینم میشه ۱۲۵۲. پس "حسابچی" باید از اعداد صحیح بزرگ هم پشتیبانی کنه.
تقی: دقیقاً. حالا فرض کن بخوایم اعداد اعشاری رو هم جمع کنیم. مثلاً ۲ + ۱۰.۲.
نقی: خب، این میشه ۱۲.۲. پس "حسابچی" باید اعداد اعشاری رو هم در نظر بگیره.
تقی: عالیه. حالا یه کم پیچیده‌ترش کنیم. ۲ + ۱۰.۲ + ۲۵ چی؟ یعنی سه تا عدد رو با هم جمع کنیم.
نقی: این میشه ۳۷.۲. پس "حسابچی" باید بتونه چند تا عدد رو هم با هم جمع کنه، حتی اگه اعشاری باشن.
تقی: آفرین. حالا یه چیز دیگه. ۲ + ۲ + (۲ * ۲) رو حساب کن. اینجا یه عبارت ریاضی داریم که هم جمع داره و هم ضرب.
نقی: خب، طبق قواعد ریاضی، اولویت با ضربه، پس ۲ ضربدر ۲ میشه ۴، بعدش با ۲ و ۲ جمع میشه که میشه ۸. پس "حسابچی" باید از عبارات ریاضی (expressions) و تقدم عملگرها هم پشتیبانی کنه. یعنی بدونه اول ضرب رو حساب کنه بعد جمع رو.
تقی: دقیقاً همینطوره.
همانطور که مشاهده کردید، در این روش با ارائه مثالهای ملموس و گام به گام، ویژگیهای سیستم را مشخص کردیم.
هر مثال، بر پایه مثال قبلی بنا شده و جنبه جدیدی از رفتار سیستم رو آشکار کرد. همین کار باعث شد که که همگی ذینفعان درک مشترکی از چیزی که قرار تولید کنند داشته باشند. این مثالها همینطور حکم proof-of-work کار نهایی رو هم دارند.
یعنی قبل از پیاده‌سازی هر خط کدی ما مکانیزم نهایی اعتبار سنجی سیستم رو بهش دست پیدا کردیم.
❤6👍1
📍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
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
👍6👌1