📺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

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

ما هم چند سال پیش در یکی از پروژه‌ها دنبال ساختن چارچوبی مشابه بودیم؛ مدلی که تیم‌ها بدون قضاوت بتونن بفهمن سرویس‌شون دقیقاً کجاست و چه چیزهایی باید بهبود پیدا کنه. تا حدی هم موفق بود، اما تجربه‌ی اجرا نکات جالبی داشت

سخت‌ترین و دارک‌ترین بخش همین context-aware تصمیم‌گیری بود، نه لزوما تعریف متریک‌ها برای حرکت سرویس‌ها توی لایه‌های مدل(اولش فکر میکردیم سخترینش تعریف و اعمال و پیاده‌سازی متریک‌هاست بعد دیدم واقعا ساده‌تر از چیزی که فکرش رو میکردیم و چالش اصلی جای دیگه است) بلکه فهمیدن و وزن‌دهی نقش واقعی هر سرویس توی بیزنس بخصوص برای کسب‌و‌کاری که دائما در حال تغییر و رفع باگ و افزودن فیچر جدید. اما context-aware کردن کل مدل، اونقدر پیچیده و nuanced بود که گاهی کل فرآیند رو فلج می‌کرد

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

​یه چالش دیگه که ما مستقیم کمتر باهاش درگیر شدیم ولی تو اسکیل بالا ناگزیره، نرخ sampling واسه سنجش صحت و سلامت هر سرویس برای تصمیم‌گیری داده‌محوره. سرویس‌های rate بالا، دیتای زیادی تولید می‌کنن و پرفورمنس توشون حیاتیه برا همین sampling می‌ره روی عددایی مثل ۰.۰۰۱٪. بر اساس دیتای ذخیره‌شده همه‌چیز خوبه، اما در عمل لزوماً این‌طور نیست. اینجا باید مراقب بود که آمار تبدیل به فکت نشن

توی Software Engineering at Google هم به تجربه مشابهی اشاره شده که آخرش می‌گه بلوغ‌های این‌جوری چون جنسشون استانداردسازیه و استانداردسازی یعنی محدودیت (و برای بعضی‌ها اجبار)، بهتره بر اساس outcomeها مثل کاهش MTTR سنجیده بشه که کار سختیه واقعا!

مارتین فاولر هم یه نوشته کوتاه داره به اسم The Maturity Model Fallacyکه میگه مدل‌ها اگر از کمک به گام بعدی تبدیل بشن به رتبه‌بندی ضد خودشون عمل می‌کنن.

​چالش دیگه توی تجربه من، فشار وحشتناک روی زیرساخت و ops بودش و خب بالاخره این فشار خودش رو توی قالب تجربه و بد اسمل‌های دیگه خودش رو نشون میده و میزنه بیرون. در حالی که تیم dev یا وقت نمی‌کرد توازن بین خروجی بیزنس و متریک‌ها رو تنظیم کنه یا چند سرویس به ارث رسیده بهش بود، یا اصلا سرویس‌های بی‌صاحب بودن :) که کسی از وجودشون خبر نداشت! context-aware نبودن اینجا هم دردسر می‌ساخت. بعدا فهیمیدم اسپاتیفای مدل جالبی رو پیش گرفته برای این سناریوها به اسم اسپاتیفای رویکرد golden paths

🔵 اما چه کردیم ما؟
حالا کاری که ما کردیم مدل رو از سطح‌دادن خام به سرویس‌ها بردیم سمت دسته‌بندی بر اساس ماهیت کسب‌وکاری و تاثیرشون روی زنده موندن بیزنس. متریک‌ها میانگین می‌گرفتن و اسکور هر چند وقت تکرار می‌شد. چون سرویسی مثل notification بعد ۶ ماه با رشد بیزنس، criticalityش عوض می‌شه. این‌طوری سرویس‌ها نیازمندی ops خودشون رو مشخص می‌کردن و از نگاه یکسان به همه خارج می‌شدیم، بدون اینکه سطح پایین یعنی کم‌کاری تیم باشه. خیلی مختصر و کوتاه بخوام بگم:

🔹معیارهای امتیازدهی ما
برای هر سرویس، این بُعد‌ها رو امتیاز می‌دادیم (ترکیب بیزنسی + فنی + سازمانی):

1- حیاتی بودن بیزنسی: core مثل پرداخت/جستجو/قیمت‌گذاری/کد تخفیف/پیشنهاد محصول یا حاشیه‌ای! وزنشون توی revenue/user journey چقدره
2- حجم/نوع ترافیک: read-heavy/mixed، latency-sensitive؟ downtime چقدر UX رو می‌زنه؟
3- موقعیت در dependency graph: failureش چند سرویس دیگه رو می‌ندازه؟ golden path کاربر ازش رد می‌شه؟
4- هم‌خوانی استک: مثلا با talent سازمان مچ می‌شه؟ learning curve/bus factor چقدر ریسکیه؟ تکنولوژی یه زبونی نباشه که هیشکی توی سازمان بلدش نیست، علی‌رغم اینکه خیلی هم تکنولوژی یا زبان برنامه نویسی خوبی هم براش انتخاب شده
5- مالکیت تیمی: تیم مشخص/توانمند داره یا ارثیه/بی‌صاحب؟😁 incidentش چند تیم رو درگیر می‌کنه؟ شعاع تاثیرش یا radius effectاش چقدر.
6- فرآیند dev: deploy frequency/rollback readiness، وابستگی به افراد کلیدی، end-to-end ownership؟

و نهایتا کنار این‌ها یا بهتره بگم بر اساس اینها MTTD/MTTR، deploy failure rate، alert quality، observability رو اضافه می‌کردیم. ترکیبشون نشون می‌داد کجا ارزش داره سرمایه‌گذار (ن)کنیم

معرفی الگوی طراحی نرم‌افزار Behavior as Data

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

جهت حل مشکل بالا، من الگوی طراحی Behavior as Data رو معرفی کردم که کمک می‌کنه بتونیم بر همچین سناریوهایی غلبه کنیم.

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

توی مقاله یکسری هیوریستیک و نشانه که به توسعه‌دهنده و افراد محصولی کمک می‌کنه به این موضوع پی ببرند به همراه مثال‌های واقعی ارایه شده


https://www.linkedin.com/pulse/introducing-behavior-data-pattern-masoud-bahrami-qc2cf