کانال مکتب‌خانه DDD

📌 ارتباط حل مسئله به روش جورج پولیا و EDD

چند وقت پیش، داشتم کتاب ارزشمند "چگونه مسئله را حل کنیم" اثر جورج پولیا را تورق می‌زدم. جورج پولیا توی این کتاب یه چارچوب ساده ولی قدرتمند برای حل مسئله ارائه می‌ده:
1️⃣ درک مسئله: قبل از هر اقدامی، مطمئن بشیم دقیقاً با چی طرفیم.
2️⃣ طراحی نقشه: یه استراتژی ما برای رسیدن به جواب.
3️⃣ اجرای نقشه: گام به گام پیش می‌ریم و برنامه‌مون رو عملی می‌کنیم.
4️⃣ بازبینی و تعمق: بعد از حل، یه نگاه بندازیم به مسیری که طی کردیم و درس‌هایی که گرفتیم.

یک همپوشانی جالب بین این توصیه‌ها و رویکرد Exploratory Domain Discovery وجود داره.
توی EDD، اولین قدم تیم برای طراحی یه سیستم اینه که بپرسه:

"هدف نهایی این سیستم چیه؟" خودمونی‌ترش اینه که: "تهش قراره به چی برسیم و جه مسئله‌ای رو حل کنیم؟". یا به قول پولیا، "صورت مسئله رو درست بفهمیم." .

1️⃣ درک مسئله: مثلاً، وقتی داریم سیستم حقوق و دستمزد طراحی می‌کنیم، "هدف نهایی" اینه که هر کارمند بعد از محاسبه دقیق حقوقش، یک فیش حقوقی عاری از خطا کنه. این میشه نقطه‌ی کانونی ما(Main Point).

2️⃣ طراحی نقشه: بعد، درست مثل نقشه‌ی پولیا، ما از اون هدف نهایی شروع می‌کنیم به عقبگرد و کشف عواملی که بهش منجر می‌شن: ثبت ساعات کاری دقیق، فرمول‌های محاسبه‌ی حقوق، انواع کسورات و... 🗺️ این دقیقاً همون مرحله‌ی "حرکت عقب‌گرد" یا "Backward Moving" در EDD هست.

3️⃣ اجرای نقشه:در مرحله‌ی بعد، با استفاده از ابزارهایی مثل کارت‌های مفهومی برای مدلسازی، برگزاری جلسات بحث و تبادل نظر با متخصصان دامنه و ایجاد نمونه‌های واقعی، سیستم رو می‌سازیم ("اجرای نقشه"). 🛠️

4️⃣ بازبینی و تعمق: و در نهایت، فرآیند EDD شامل چندین دور اکتشاف (Discovery)، تست مدل با مثال‌های واقعی، پرسیدن سوالات برای رفع ابهامات و بازبینی مستمر مدله. این همون "بازبینی و تعمق" پولیاست که به ما کمک می‌کنه مطمئن بشیم راه‌حل درستی رو پیدا کردیم و چیزهای جدیدی یاد گرفتیم. 🔄

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

به نظر من، EDD در مواجهه با پیچیدگی‌های دنیای نرم‌افزار، همون منطق قدرتمندی رو دنبال می‌کنه که پولیا برای حل مسائل ریاضی پیشنهاد داده بود. فقط ابزارها متفاوت شدن: کارت‌های Domain Concept و ارتباطات بین این کارت‌ها به‌جای معادلات، و همکاری تیمی به‌جای کار انفرادی روی کاغذ. 🤝

اما سوال اساسی در هر دو رویکرد یکیه:

"ما واقعاً در تلاش برای حل چه مشکلی هستیم؟" 🤔


برای من EDD ادامه‌ی همون نگاه پولیاست؛ فقط این‌بار در دنیای پیچیده‌تر، مشارکتی‌تر و زنده‌ترِ طراحی نرم‌افزار.
نه معادله می‌نویسیم، نه تابع مشتق می‌گیریم. ولی همون منطق رو دنبال می‌کنیم.

یکی از شعارهای اساسی در EDD این است:

See the ending. Discover the meaning. Design with purpose

این ارتباط عمیق بین تفکر ریاضی و طراحی نرم‌افزار همیشه برام جذاب بوده.


🎯 برای اطلاعات بیشتر در مورد Exploratory Domain Discovery به لینک زیر مراجعه کنید:
https://exploratorydomaindiscovery.com/

Exploratorydomaindiscovery

Exploratory Domain Discovery | The art of Strategic Decision-Making

Exploratory Domain Discovery is yet another collaborative modelling and designing tool, that

helps a team be on the same page about the complex domain being modelled. It helps you with a

model that can back your strategic decision making.

❤1

www.tgoop.com/DomainDrivenDesign_ir/264

705 viewsMay 17 at 17:08

📌 ارتباط حل مسئله به روش جورج پولیا و EDD

چند وقت پیش، داشتم کتاب ارزشمند "چگونه مسئله را حل کنیم" اثر جورج پولیا را تورق می‌زدم. جورج پولیا توی این کتاب یه چارچوب ساده ولی قدرتمند برای حل مسئله ارائه می‌ده:
1️⃣ درک مسئله: قبل از هر اقدامی، مطمئن بشیم دقیقاً با چی طرفیم.
2️⃣ طراحی نقشه: یه استراتژی ما برای رسیدن به جواب.
3️⃣ اجرای نقشه: گام به گام پیش می‌ریم و برنامه‌مون رو عملی می‌کنیم.
4️⃣ بازبینی و تعمق: بعد از حل، یه نگاه بندازیم به مسیری که طی کردیم و درس‌هایی که گرفتیم.

یک همپوشانی جالب بین این توصیه‌ها و رویکرد Exploratory Domain Discovery وجود داره.
توی EDD، اولین قدم تیم برای طراحی یه سیستم اینه که بپرسه:

"هدف نهایی این سیستم چیه؟" خودمونی‌ترش اینه که: "تهش قراره به چی برسیم و جه مسئله‌ای رو حل کنیم؟". یا به قول پولیا، "صورت مسئله رو درست بفهمیم." .

1️⃣ درک مسئله: مثلاً، وقتی داریم سیستم حقوق و دستمزد طراحی می‌کنیم، "هدف نهایی" اینه که هر کارمند بعد از محاسبه دقیق حقوقش، یک فیش حقوقی عاری از خطا کنه. این میشه نقطه‌ی کانونی ما(Main Point).

2️⃣ طراحی نقشه: بعد، درست مثل نقشه‌ی پولیا، ما از اون هدف نهایی شروع می‌کنیم به عقبگرد و کشف عواملی که بهش منجر می‌شن: ثبت ساعات کاری دقیق، فرمول‌های محاسبه‌ی حقوق، انواع کسورات و... 🗺️ این دقیقاً همون مرحله‌ی "حرکت عقب‌گرد" یا "Backward Moving" در EDD هست.

3️⃣ اجرای نقشه:در مرحله‌ی بعد، با استفاده از ابزارهایی مثل کارت‌های مفهومی برای مدلسازی، برگزاری جلسات بحث و تبادل نظر با متخصصان دامنه و ایجاد نمونه‌های واقعی، سیستم رو می‌سازیم ("اجرای نقشه"). 🛠️

4️⃣ بازبینی و تعمق: و در نهایت، فرآیند EDD شامل چندین دور اکتشاف (Discovery)، تست مدل با مثال‌های واقعی، پرسیدن سوالات برای رفع ابهامات و بازبینی مستمر مدله. این همون "بازبینی و تعمق" پولیاست که به ما کمک می‌کنه مطمئن بشیم راه‌حل درستی رو پیدا کردیم و چیزهای جدیدی یاد گرفتیم. 🔄

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

به نظر من، EDD در مواجهه با پیچیدگی‌های دنیای نرم‌افزار، همون منطق قدرتمندی رو دنبال می‌کنه که پولیا برای حل مسائل ریاضی پیشنهاد داده بود. فقط ابزارها متفاوت شدن: کارت‌های Domain Concept و ارتباطات بین این کارت‌ها به‌جای معادلات، و همکاری تیمی به‌جای کار انفرادی روی کاغذ. 🤝

اما سوال اساسی در هر دو رویکرد یکیه:

"ما واقعاً در تلاش برای حل چه مشکلی هستیم؟" 🤔


برای من EDD ادامه‌ی همون نگاه پولیاست؛ فقط این‌بار در دنیای پیچیده‌تر، مشارکتی‌تر و زنده‌ترِ طراحی نرم‌افزار.
نه معادله می‌نویسیم، نه تابع مشتق می‌گیریم. ولی همون منطق رو دنبال می‌کنیم.

یکی از شعارهای اساسی در EDD این است:

See the ending. Discover the meaning. Design with purpose

BY کانال مکتب‌خانه DDD