Domain Driven Design چیست؟ [بررسی دامنه]

مقدمه‌

به طور کلی هر حوزه تخصصی را دامنه یا Domain می‌نامیم. کمی دقیق‌تر اگر بخواهیم تعریف کنیم، مجموعه‌ای مفاهیم و دانش‌های منسجم در یک حوزه‌ دامنه آن حوزه است. در حوزه Domain Driven Design که از این به بعد به آن DDD می‌گوییم، محدوده‌ کسب و کاری که نرم‌افزار ما قرار است در آن به فعالیت بپردازد را دامنه می‌نامیم.
تعریف آقای vaughn vernon نویسنده کتاب ارزنده Implementing Domain-driven Design از دامنه این است: « آن چیزی که سازمان انجام می‌دهد و دنیایی که آن کار را در آن انجام می‌دهد دامنه است. »
تعریف دیگری که از دامنه می‌توانیم داشته باشیم مربوط به آقای Eric Evans نویسنده کتاب Domain-Driven Design: Tackling Complexity in the Heart of Software است: « محدوده‌ای که کاربر برای برنامه اعمال می‌کند.»

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

آشنایی با انواع دامنه

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

به جز موارد خاص، مثل تولید یک ابزار فنی یا فریم ورک برای توسعه نرم‌افزار، معمولا مسائل صرفا با دانش‌ فنی قابل حل نیستند. بدون دانش دقیق از حوزه یک کسب و کار، تولید نرم‌افزاری کارا، قابل استفاده و پیشتاز برای آن کار غیر ممکن است. بنابراین بدون در نظر گرفتن اندازه یک پروژه، شناخت دقیق حوزه کسب و کار برای همه ارکان درگیر در حوزه پروژه امری ضروری است.

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

برای دقیق‌تر معلوم شدن این موارد بیایید با هم مثالی را در نظر بگیریم. در شرکت داتین از من خواسته شده نرم‌افزاری توسعه دهم که تمام عملکرد یک مشتری را در یک نگاه برای مدیران رده بالا میسر کنم. برای انجام این کار من نیاز به دانش در زمینه انبار داده‌دارم، باید بتوانم با داده‌های حجیم کار کنم. باید بستری برای جستجو و انتقال این داده‌های حجیم فراهم کنم. باید دانش خوبی در زمینه UI,UX داشته باشم که داده‌های به دست آمده را به خوبی، در فضایی کم و جذاب و قابل فهم نمایش دهم و …

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

پس ما هنگام کار برای تولید یک نرم‌افزار در دو دامنه فنی و کسب و کار قرار می‌گیریم و باید دانش خود را در هر دو زمینه قوی کنیم. هنر یک توسعه‌دهنده ایجاد توازن بین این دو دامنه فنی و کاری هنگام حل صورت مسئله است. هر دو دامنه به یک اندازه برای موفقیت یک پروژه و یک کسب و کار حیاتی است.

آشنایی با کارشناس دامنه

کارشناس دامنه یا Domain Expert کسی است که دانش دقیق و اختصاصی یک کسب و کار را دارد و به ما برای پیاده‌سازی پروژه و حل صورت مسئله کمک می‌کند. برای هر پروژه‌ای حداقل داشتن یک کارشناس حیاتی است و به طور کلی باید برای همه سوالاتی که حین توسعه نرم‌افزار پیش می‌آید پاسخی داشته باشد، البته ممکن است کاری به طور مشترک توسط چند نفر انجام شود و دانش آن کار بین این افراد پخش شده باشد. اگر فردی با این توانایی در تیم پروژه وجود نداشته باشد باید یک یا چند نفر قبل از شروع کار، اقدام به یادگیری حوزه اختصاصی کار کنند و بعد در حین توسعه نرم‌افزار نقش کارشناس دامنه را ایفا کنند.

تفاوتی نمی‌کند که کارشناس دامنه داشته باشیم یا اعضای تیم تلاش کنند دانش دامنه‌ای را کسب کنند، به هر حال ممکن است مسئله ای ناشناخته باقی مانده باشد و تا زمانی که شروع به کار می‌کنیم به آن مسئله فکری نشده باشد. برای همین مهم است که برای به دست آوردن‌دانش و شناخت دقیق مسئله زمان صرف کنیم.

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

زیر دامنه چیست؟

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

۱- دامنه اصلی یا Core Domain:

محدوده اصلی دانش و مسئله‌ای که با آن سر و کار داریم و هدف اصلی پروژه است را Core Domain یا همان دامنه اصلی می‌نامیم. باید تلاش کنیم که هرچه زودتر این دامنه را شناسایی کنیم و بیشترین تلاش و هزینه را برای انجام این قسمت از پروژه قرار دهیم. کلید اصلی موفقیت یک پروژه، موفیت در Core Domain است. معمولا رقابت کسب و کارهای مختلف در حوزه Core Domain بوده و در صورت عدم موفقیت در این قسمت، کسب و کار و در ادامه آن پروژه نا‌موفق خواهند بود. ممکن است شرایطی وجود داشته باشد که یک پروژه صرفا از یک دامنه اصلی و بدون هیچ دامنه جانبی تشکیل شده باشد، البته معمولا در این شرایط همچین دامنه‌هایی برای ادامه کار، با چندین کار و دامنه دیگر شروع به همکاری می‌کنند.

۲- دامنه عمومی یا Generic Domain:

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

۳- دامنه‌ پشتیبان یا Supporting Domain:

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

مثال

بیایید با هم کسب و کاری مانند پشنهاد رستوران و تهیه غذای اینترنتی را بررسی کنیم و ببینیم تا چه حد می‌توانیم دامنه و زیر دامنه‌های آن را شناسایی کنیم.
در این کسب و کار باید رستوران‌هایی وجود داشته باشند و به کاربر رستوران‌ها نمایش داده شود و بتواند غذای مورد علاقه خود را از طریق رستوران‌های موجود در سامانه تهیه کرده و غذا برای مشتریان پیک شود. در طول فرایند سفارش و آماده سازی و ارسال غذا باید کاربر از وقایع سیستم مطلع شود. و در نهایت بعد از دریافت غذا باید مشتری بتواند نظر خود را در مورد غذایی که انتخاب کرده است بیان کند.

دامنه و زیردامنه‌های شناسایی شده

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

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

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

بعد از اینکه رستوران غذا را آماده کرد باید پیک غذا را در کمترین زمان ممکن از رستوران تحویل گرفته و به مشتری برساند. کار سامانه ما راضی کردن کاربر به ثبت سفارش است. اما بدون ارسال صحیح غذا برای مشتریان کل فرایند کاری ما ناقص خواهد بود. پس باید فرایند‌هایی جهت ارسال غذا داشته باشیم. این قسمت پشتیبان کسب و کار ما است و بخش اصلی آن نیست. ولی به هر حال وجود آن ضروری است. نکته جالب در مورد این قسمت این است که ممکن است برای انجام این فرایند با کسب و کار دیگری تعامل کنیم که این دامنه اتفاقا دامنه اصلی آن‌ها باشد. یا بعدها بیاییم و کسب و کاری جدی در این زمنیه راه اندازی کنیم و این دامنه تبدیل به دامنه اصلی شود. اما در حال حاضر برای ما یک دامنه پشتیبان محسوب می‌شود.

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

امیدوارم تا اینجای کار با مثال‌هایی که دیدیم تعاریفی واضح شده باشد. پس توضیح راجع به سایر بخش‌های برنامه را ادامه نداده و یافتن دلیل تصمیمات را به خواننده واگذار می‌کنم.

تشخیص زیردامنه‌ها

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

جمع بندی

در قسمت اول از این مجموعه به تعریف اولیه در مورد دامنه و انواع دامنه‌های موجود در یک نرم‌افزار پرداختیم و دانستیم که شناسایی دامنه و زیر دامنه امری نسبی است و به مرور با کسب دانش بیشتر در مورد کسب و کار ممکن است محدوده‌هایی که شناخته‌ایم تغییر کند.
مثال آورده شده در مطلب کاملا انتزاعی بوده و صحت و قطعیت نداشته و صرفا جهت روشن شدن تعاریف آورده شده است.