سلام مدتی بود که میخواستم راجع به Domain Driven Design بنویسم که بالاخره تصمیممو گرفتم و شروع کردم. از اینجا شروع کنیم که ببینیم اصلا Domain Driven Design چیست؟ Domain Driven Design که به اختصار بهش DDD میگن اولین بار در سال ۲۰۰۳ توسط آقای Eric Evans در کتاب Domain-driven design مطرح گردید.
این رویکرد در سال های گذشته به شدت توجه جامعه نرم افزاری رو به خودش جلب کرده. در اصل DDD یک نوع تفکر و یا رویکردی برای تولید و توسعه ی نرم افزارهای بزرگ با فرآیندها و قوانین زیاد و پیچیده میباشد که از قسمت تحلیل گرفته تا قسمت کد نویسی یک محصول همراه ماست در اصل در دو قسمت استراتژیک و تکنیکال به ما ایده میده (البته خود آقای Eric Evans در کتابش بیشتر در مورد مفاهیم استراتژیک صحبت میکنه)و تمرکز اصلیش هم روی بیزینس اصلی نرم افزاریه که میخواهیم بنویسیم که همون Domain ماجراست. در واقع کار DDD از یک آرزو یا مشکل بیزینسی (Problem Domain) شروع میشود.
تعریف خود آقای Eric Evans از دامنه یا همون Domain به شرح زیره: "محدوده‌ای که کاربر برای برنامه اعمال میکند".
همونطور که تا الان صحبت کردم و متوجه شدیم DDD برای محصولاتی که بیزینس پیچیده ای دارن خیلی مفیده لذا استفاده از آن در پروژه های کوچک و ساده و یا پروژه هایی که صرفا نیاز به ذخیره و خواندن اطلاعات دارند و Business خاصی ندارند، ممکن است تنها زمان و هزینه ی پروژه را افزایش داده و مزیتی خاصی هم به همراه نداشته باشد.
از دیگر زوایایی که DDD روی آن تاکید خاصی دارد تعامل سازنده و بهینه بین برنامه نویسان و افراد متخصص دامنه (Domain) که بهشون Bussiness Expert گفته میشه داره. به خاطر همین ایجاد یک زبان مشترک به نام Ubiquitous Language در مورد مفاهیم دامنه امری الزامی است. که این زبان مشترک رو هم در مستندات تحلیل میبینیم و هم در کد. در اصل یکی از قدرت های DDD استفاده از زبان مشترک است. برای مثال به دو تصویر زیر دقت کنید، تصویر اول یک سناریو برای ارسال و تحویل پیتزا میباشد و تصویر دوم پیاده سازی متد همین سناریو میباشد. همان طور که میبینیم در هر دو تصویر سعی بر این آمده است که از زبان مشترک استفاده شود. (تصاویر برگرفته از کتاب The Anatomy Of Domain Driven Design)
تصویر اول: (مستند سناریو تحویل پیتزا)
تصویر دوم : (پیاده سازی سناریو تحویل پیتزا)
هروقت از DDDصحبت شد یاد شکستن بیوفتید در واقع DDD همه چیز رو میشکنه یعنی اینکه مسائل رو میشکنه تا راحتتر باهاشون برخورد کنه مثل Knowledge Crunching(شکستن دانش) و یا اینکه دامنه رو به یکسری SubDomain میشکونه و یا راهکارهایی برای تقسیم نرم افزار به بخش های جدا و مستقل از هم و همچنین ارتباط این بخش ها با یکدیگر ارائه میکند. این امر سبب می شود تا فرآیند توسعه ی نرم افزار به صورت موازی بین چند تیم انجام شده و همچنین معماران سیستم را قادر می سازد تا از معماری ها و تکنولوژی های مختلف در بخش های مختلف استفاده نمایند. اگه بخوام یکم بیشتر راجبه SubDomain ها صحبت کنم میتونم بگم اون ها رو به 3 دسته تقسیم کردن:
1- دامنه اصلی (Core Domain): محدوده اصلی دانش و مسئله ای که با اون سروکار داریم رو بهش میگن دامنه اصلی. بیشترین تلاش و هزینه هر شرکتی روی دامنه اصلیه حتی خیلی از شرکتها نیروی های ماهرشون رو روی این قسمت میزارن که کار کنند در اصل اینجوری بگم که کلید موفقیت هر پروژه موفقیت در Core Domain هستش.
2- دامنه پشتیبان و دامنه عمومی(Supporting Domain و Generic Domain):
در طول یک پروژه ممکن است با بخش‌هایی مواجه شویم که اصل کسب و کار را تشکیل نمی‌دهند ولی وجودشون برای اینکه کار اصلی دامنه به هدف برسه ضروری و لازمه و حتی میتونیم این بخش ها را از شرکت های دیگه ای خریداری کنیم. مثل ارسال ایمیل یا اس ام اس ...
در واقع انتخاب sub domainها یک موضوع کاملا نسبی است و هیچ قاعده و قانونی نداره در واقع هیچ انتخاب قطعی درست یا غلط راجبش وجود نداره و کاملا به تیم بستگی دارد.
تمام مفاهیمی که تا به اینجا مطرح شد در فضای مسئله بودند و هنوز وارد فضای راه حل نشدیم. در اصل تشخیص subdomain ها و یا زبان مشترک.... در فضای تعریف خود مسئله است(problem space) نه در فضای راه حل مسئله.(solution space).
در این مقاله من سعی کردم یکسری از مفاهیم اولیه و کلی که مربوط به DDDبود رو عنوان کنم حالا تو قسمتای بعدی سعی میکنم بیشتر در مورد مفاهیم استراتژیک و تکنیکال صحبت کنم و بیشتر وارد فضای حل مسئله شیم.
