پیرو صحبت با کارشناسان معماری نرم افزار شرکت برنامه نویسی رادنت؛ در خصوص سفارش نرم افزار توسط سازمانهای بزرگ و در واقع اصل نحوه کنترل هزینه نگهداری و پشتیبانی نرم افزارهای Enterprise ؛ به اصل DDD رسیدیم.
رادنت می گوید Domain Driven Design (به اختصار DDD) مبحثی است که در سال های اخیر به شدت مورد توجه جامعه ی نرم افزاری دنیا بوده و رویکرد بسیاری از شرکت های نرم افزاری را برای تحلیل و توسعه ی نرم افزارها به شدت مورد تاثیر قرار داده است. این مبحث اولین بار در سال ۲۰۰۳ توسط آقای Eric Evans در کتاب Domain-driven design مطرح گردید.
دامین درایو دیزاین رویکردی برای تولید و توسعه ی نرم افزارهای بزرگ با فرآیندها و قوانین زیاد، پیچیده و در حال تغییر می باشد.
اصطلاح Domain به حوزه و دامنه ی اصلی فعالیت نرم افزار اطلاق می شود که نرم افزار برای پیاده سازی آن توسعه می یابد.
هسته ی اصلی DDD مجموعه ای از مفاهیم و تکنیک هاست که برای تحلیل Domain و ساخت یک مدل از روی آن (Domain Model) به کار برده می شود.
تمرکز و توجه اصلی این رویکرد بر روی توسعه ی این مدل می باشد. تحلیل و طراحی Domain Model اختصاصا به منظور تولید نرم افزار در ابعاد Enterprise و با فرآیند های پیچیده و زیاد مناسب می باشد. Domain Model طراحی شده با جزئیات دقیق بوده و مفاهیم و قوانین (Business Rules) در آن پیاده سازی میشوند.
DDD بر زوایای دیگری از فرآیند توسعه ی نرم افزار نیز تاثیر گذار است. برای مثال تاکید زیادی در ارتباط دو طرفه ی تیم توسعه ی نرم افزار و کاربران متخصص Domain (برای مثال انبارداران در سیستم انبار) دارد. از آنجا که ممکن است در این ارتباط دو طرفه، تیم توسعه ی نرم افزار در فهمیدن برخی مفاهیم و مسائل دچار اشتباه و دوگانگی شوند لذا ایجاد زبان یکسان بین دو تیم (Ubiquitous Language) در مورد مفاهیم Domain امری الزامی است. DDD همچنین راهکارهایی برای تقسیم نرم افزار به بخش های جدا و مستقل (مفهوم Bounded Context) و همچنین ارتباط این بخش ها با یکدیگر ارائه میکند. این امر سبب می شود تا فرآیند توسعه ی نرم افزار به صورت موازی بین چند تیم انجام شده و همچنین معماران سیستم را قادر می سازد تا از معماری ها و تکنولوژی های مختلف در بخش های مختلف استفاده نمایند.
همانطور که مطرح شد، رویکرد Domain-Driven برای نرم افزارهای بزرگ و پیچیده مناسب می باشد. لذا استفاده از آن در پروژه های کوچک و ساده و یا پروژه هایی که صرفا نیاز به ذخیره و خواندن اطلاعات دارند و Business خاصی ندارند، ممکن است تنها زمان و هزینه ی پروژه نرم افزاری را افزایش داده و مزیتی خاصی به همراه نداشته باشد.
- تمرکز اصلی پروژه، باید صرف فائق آمدن بر مشکلات و پیچیدگیهای موجود در دامین شود.
- پیچیدگیهای موجود در دامین پس از شناسایی به یک مدل تبدیل شوند.
- برقراری یک رابطه‌ی خلاق بین متخصصان دامین و افراد تیم توسعه برای بهبود مستمر مدل ارائه شده که نهایتا راه حل مشکلات دامین است بسیار مهم می‌باشد
طراحی متاثر از حوزه‌ی کاری (Domain Driven Design) منجر به کاهش، درک و نهایتا قابل مدیریت کردن پیچیدگیهای موجود در حوزه عملیاتی نرم افزار (Domain) می‌شود. توجه کنیم که تحلیل و مدلسازی، فعالیتهای رایج در حوزه هایی مانند حمل و نقل، اکتشافات، هوا فضا، شبکه‌های اجتماعی و … می‌تواند بسیار دشوار باشد.
