در بسیاری از پروژه‌ها، تیم‌ها خیلی زود سراغ معماری، طراحی سرویس‌ها یا API می‌روند، در حالی که هنوز تصویر مشترکی از دامنه ندارند.همه فکر می‌کنند «می‌دانیم سیستم قرار است چه‌کار کند»، اما وقتی بحث جلو می‌رود، معلوم می‌شود هرکس یک مدل ذهنی متفاوت دارد، گاهی حتی در بدیهی‌ترین مفاهیم. در همچین سناریوهایی Exploratory Domain Discovery (EDD) می‌تواند وارد بازی شود و به شما کمک کند.

برای مطالعه بیشتر در مورد EDD به وب‌سایت رسمی آن مراجعه کنید:

Introducing Exploratory Domain Discovery

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

و مهم‌تر از همه:
EDD یک متد طراحی نیست. یک متد کاوش و فهم است، پیش‌نیازی برای طراحی درست.

DDD توسط مسعود بهرامی معرفی شد است.

چالش اصلی سروکله زدن در دومین‌های پیچیده چیست؟

در دامنه‌های پیچیده، مشکل اصلی معمولاً کمبود اطلاعات نیست، ابهام، برداشت‌های مختلف، و عدم‌هم‌ترازی است.
EDD این مشکلات را حل می‌کند:

Exploratory Domain Discovery (EDD) یک روش مشارکتی برای فهم دامنه‌های پیچیده است که با کاوش و روایت مشترک به جای طراحی زود هنگام کار می‌کند. هدفش این است که قبل از نوشتن یک خط کد یا طراحی ساختار نهایی، تیم یک درک مشترک از چیزی وجود دارد و چه چیزی واقعاً مهم است بسازد.

نحوه کارِ EDD به زبان ساده (فرآیند کلی)

Start from the End – Backward Storytelling: از خروجی/نتیجه‌ای که کاربر/کسب‌وکار انتظار دارد شروع می‌کنیم و داستان را به عقب روایت می‌کنیم تا مفاهیم پایه‌ای پیدا شوند.
Breadth-first exploration (Round 1): در دور اول سطحِ گسترده‌ای از Domain Concepts (اسامی/نهادها) را می‌گِیریم، خیلی سطحی اما جامع.
Attach Examples: برای هر مفهوم یک مثال عینی می‌گذاریم تا ابهام حذف شود.
Map Relationships & Rules: روابط بین مفاهیم و قوانین کسب‌وکاری را می‌نویسیم (این‌جا تراکنش‌ها/قواعدِ حفاظتی مشخص می‌شوند).
Iterate Selectively (Round 2+): از بین مفاهیمِ ظاهر شده، کاندیداهای «core» را انتخاب و روی آن‌ها عمیق می‌شویم (selective depth).
Find Circular Patterns & Main Point: دنبال الگوهای چرخه‌ای می‌گردیم، آنچه تکرار می‌شود معمولاً ما را به Main Point می‌رساند (هسته‌ای که بقیه مفاهیم حول آن می‌گردند).
Capture Questions & Decisions: پرسش‌ها و تصمیمات باز را یادداشت می‌کنیم؛ آن‌ها تبدیل به Backlog یا نقاط تحقیق بعدی می‌شوند.

ویژگی‌های متمایز کننده EDD از سایر رویکردهای مدلسازی مشارکتی

نقطهٔ شروع: از انتها به ابتدا

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

مثلاً در یک سرویس سفارش غذا، به جای اینکه از «ثبت سفارش» شروع کنیم، از نتیجه شروع می‌کنیم:
سفارش با موفقیت به دست مشتری رسید.
بعد به عقب برمی‌گردیم و می‌پرسیم:
برای اینکه این اتفاق بیفتد، چه چیزهایی باید وجود داشته باشد؟

به این ترتیب مفاهیمی مثل سفارش، مشتری، رستوران، آیتم منو، پرداخت، وضعیت سفارش، پیک و… یکی‌یکی ظاهر می‌شوند. اما در این مرحله فقط نام‌ها را جمع می‌کنیم؛ هنوز وارد طراحی یا مدل‌سازی عمیق نمی‌شویم.

بر روی کشف مفاهیم احتمام بورزید!

EDD روی Domain Concepts تمرکز می‌کند، چون اینها نشانهٔ چیزهایی هستند که در واقعیت وجود دارند. تیم برای هر مفهوم یک مثال واقعی می‌سازد تا ابهام از بین برود. این کار ساده اما بسیار قدرتمند است: چون معمولاً جای‌خالی‌ها، سوء‌تفاهم‌ها و تناقض‌ها همین‌جا خودشان را نشان می‌دهند.

در ادامه بین این مفاهیم رابطه‌ها و قوانین کشف می‌شود:
مثلاً هر سفارش باید حداقل یک آیتم داشته باشد»، یا «قیمت سبد خرید باید قبل از پرداخت ثبت شود.

جایی که EDD خاص می‌شود: کشف الگوهای چرخه‌ای

وقتی مفاهیم و مثال‌ها زیاد می‌شوند، رفتارها و ارزش‌ها شروع به تکرار می‌کنند. این‌جا یکی از نشانه‌های مهم EDD خودش را نشان می‌دهد:
الگوی چرخه‌ای یا Domain Circular Pattern.

برای مثال در همان سرویس سفارش غذا:
سفارش ایجاد می‌شود → وضعیتش تغییر می‌کند → آماده‌سازی انجام می‌شود → ارسال می‌شود → دوباره وضعیت عوض می‌شود → تحویل می‌شود → فیدبک جمع می‌شود.
این یک چرخهٔ تکرارشونده است.

چرخه‌ها معمولاً ما را به چیزی می‌رسانند که در EDD به آن Main Point می‌گوییم؛ یعنی قلب دامنه، همان جایی که ارزش واقعی تولید می‌شود. در مثال بالا: جریان سفارش معمولاً همان Main Point است.

در مورد Domain Circular Pattern بیشتر بخوانید:

Domain Circular Patterns

از فهم دامنه تا طراحی سیستم

خروجی یک جلسهٔ EDD یک مدل کامل نیست. هدفش این است که مواد خام لازم برای طراحی را فراهم کند.
وقتی مفاهیم، روابط، مثال‌ها، قوانین و چرخه‌ها روشن شدند، تیم می‌تواند خیلی مقتدرتر وارد مرحلهٔ طراحی سرویس‌ها، تعیین Bounded Context، ساخت Aggregates و ماژولار کردن سیستم شود.

مثلاً در مثال سفارش غذا، EDD ممکن است نشان دهد که پرداخت، سبد خرید و پروفایل رستوران چرخه‌های جداگانه‌ای دارند و باید در کانتکست‌های مستقل طراحی شوند؛ اما «جریان سفارش» باید به‌صورت منسجم در یک بافت مستقل قرار گیرد.

چرا EDD چنین تأثیری دارد؟

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