قبل از پاسخ به این سوال مختصرا توضیح می‌دهم که DDD رویکردی برای طراحی و مدل سازی دامین‌های پیچیده است. دامین‌هایی که نیازمندی‌ها در ابتدای پروژه شفاف نیستند و به مرور و به واسطه‌ی کسب آموخته‌های جدید، کشف و ظاهر می‌شوند.
هر چند در سالیان اخیر، توسعه به سبک چابک در بین توسعه دهندگان نرم افزار از اقبال بیشتری برخوردار شده است، اما کمتر دیده‌ام که مفاهیم و اصولی که می‌توانند به یک تیم اجایل قدرت بیشتری بدهند، به اندازه کافی مورد بررسی و توجه قرار بگیرند و این باعث می‌شود که متدولوژی‌های چابک، به تدریج ناکارآمد جلوه کنند و به یک شیر بی یال و دم تبدیل شوند.
استفاده از پیشنهادهای Domain Driven Design  در مدل‌سازی و توسعه محصول در دامین های پیچیده، از موضوعاتی است که می‌تواند یک تیم اجایل را اجایل‌تر کند و به تقویت میزان پایداری به اصول و شاخص‌های چابکی در تیم، بیانجامد. ولی چگونه؟ فرهنگ و زمینه‌های فکری چابکی، با فضای فکری DDD چه خویشاوندی دارند؟ ارتباط آنها چیست؟

اول باید بدانیم که یک تیم اجایل، وقتی اجایل است که به ارزش‌های زیر وفادار بماند:

(Individuals and interactions over processes and tools)

 ارتباط با اشخاص را بر استفاده از ابزار ترجیح می‌دهیم.

(Working software over comprehensive documentation) 

نرم افزاری کارآمد را بر مستند‌سازی ترجیح می‌دهیم.

(Customer collaboration over contract negotiation) 

همکاری مشتری را بر تقید به مفاد قرارداد ترجیح می‌دهیم.

(Responding to change over following a plan) 

آماده پذیرش تغییرات آینده هر چند دیرهنگام، هستیم.


خب، هم نوایی این اصول با DDD در چیست؟


از اولین اصل شروع می کنیم:

(Individuals and interactions over processes and tools)

تعامل با افراد درگیر در پروژه ارجحیت دارد به استفاده از ابزارها.

تیمی از توسعه‌دهندگان را در نظر بگیرید که با وجود داشتن بهترین ابزارها، بحث و گفتگویی بین آنها وجود ندارد و هر کدام در عالم خویش مشغول به کار خودش است.
در مقابل تیمی دیگر را در نظر بگیرید که حداقلی از ابزارهای مورد نیاز خود را در اختیار دارند ولی تعامل قوی و مطلوبی بین آنها و مشتری برقرار است و جلسات مستمری با مشتری برگذار می‌کنند. ایده هایشان را مطرح می‌کنند، آموخته هایشان را به اشتراک می‌گذارند و شفافیت بالایی از جریان کار بین آنها وجود دارد.
کدام تیم موفق‌تر عمل خواهد کرد؟
DDD با این اصل چابکی، هم‌خوانی دارد. در DDD تاکید بر این است که همه افراد درگیر پروژه مانند توسعه دهندگان، آزمون‌گران، مشتریان، مدیران، مستند نویسان و ... در تولید زبانی مشترک که اصطلاحا، زبان فراگیر یا (Ubiquitous language) نامیده می‌شود فعالانه عمل کنند و از آن در گفتگوها، کد، تست، نمودارها و مستندات استفاده کنند. طبیعی است که خلق و بسط و تقویت این زبان مشترک حاصل نمی‌شود جز با تعامل با همه اشخاص درگیر پروژه. فعالیت‌هایی مانند جلسات صبح‌گاهی - روزانه، Spike، Iteration Zero, Sprint Planning  همگی با تاکیدات DDD همخوانی دارند.

برای کسب اطلاعات بیشتر در مورد (Ubiquitous language) بخوانید: لینک

اصل دوم: Working software over comprehensive documentation

فراموش نکنیم که هدف اصلی از توسعه نرم افزار، تولید یک نرم افزار است نه تولید مستندات. در غیر اینصورت باید گفت کار ما Documentation development است نه Software development!
DDD با این اصل هم، سازگار است به این نحو که در DDD  تمرکز اصلی بر غلبه بر مشکلاتی است که در دامین وجود دارد. این مشکلات همان‌هایی هستند که اساسا مشتری برای حل آنها، هزینه پرداخت می‌کند. در متدولوژی‌های چابک، توصیه اکید این است که فعالیت‌ها معطوف به خلق بیشترین ارزش برای مشتری شوند و این موضوع از تاکیدات DDD است. (Eric Evans: Focus on the Core Domain)
با الهام از آموزه‌های DDD می‌توان سریع‌تر و دقیق‌تر انعکاسی از دامین در مدل بوجود آورد. هر چند مدل اکتشافی است اما همین مدل‌های اولیه با مشارکت متخصصان دامین به سرعت تبدیل به بخشی از محصول نهایی خواهند شد که برای مشتری ارزشمند خواهند بود.
مهم نیست که شما چقدر برای طراحی مدل‌هایتان وقت صرف می‌کنید. قطعا مدل‌های شما نیاز به بهبود خواهند داشت. بهبود مدل هم میسر نمی‌شود مگر با دریافت بازخوردهای مشتریان در یک فرآیند توسعه‌ی افزایشی (Incremental).

اصول Customer collaboration over contract negotiation و Responding to change over following a plan:

فقط مشتریان (یا نمایندگان او) می‌توانند بگویند نیازشان چیست. داشتن قرار داد با مشتری مهم است تا مسئولیت‌ها شفاف شوند ولی قرار داد جایزگزینی برای گفتگو نیست و نباید به آن اکتفا کرد. تیم‌های موفق با مشتریان خود به گفتگو می‌نشینند و از این طریق نیازهای او را کشف می کنند و تاکییدی بر پایبندی به مفاد قرار دادی که صرفاً یک پیش بینی از نیازمندی‌ها در آن آمده است، نمی‌کنند. اما این اصل با DDD چه خویشاوندی دارد؟ در DDD هم تاکید بر شناخت مسائل حوزه کاری (Domain) با مشارکت فعال مشتری شده است. توجه کنیم که توسعه نرم‌‌افزار در دامین‌های پیچیده، یک فرآیند مکاشفه‌ای است. نرم افزار کامل نمی شود. نیازمندیها کشف می شوند. به همین دلیل فکر اینکه در قالب قراردادی چفت و بست دار پروژه ای را آغاز کنید و با رضایت کامل مشتری به پایان برسانید، حداقل به گواهی تجربه، بسیار نادر است. DDD ذاتا بر اکتشاف بنا نهاده شده است تا در طی یک فرآیند تکرار پذیر (Iterative) به اکتشاف بپردازد و بصورت تدریجی (Incremental) به حل مشکلات دامین بپردازد. اما منبع اکتشاف و خلق فضای راه حل چیست؟ مسلماً فضای مسئله. دانش دامین در اختیار کیست؟  متخصص دامین و این یعنی اینکه باید با متخصص دامین تعامل داشت. در متدولوژی‌های اجایل معادل متخصص دامین، نقش‌هایی مانند صاحب محصول یا On-Site Customer وجود دارد. در DDD تاکید شده بر اینکه دانش دامین تکه تکه به دست می‌آید و هر بار کامل‌تر از قبل می‌شود. نگران اکتشافی بودن دامین نباید بود. بلکه باید سازوکاری تدارک دید تا همواره مدل انعکاس کارآمدی از دامین باشد.
سرانجام اینکه همه افراد درگیر پروژه از مدل و سازوکار آن مطلع‌اند و نسبت به کارآمدی آن مسئول هستند. این یک تیم موفق در بکارگیری DDD  است. این یک تیم اجایل است.