1. مقدمه:
شاید بهترین روش برای شروع این بخش استفاده از تعریف آقای Eric Evans برای مدل دامنه است. ایشان مدل دامنه را اینگونه تعریف می‌کنند:
فرمی از دانش که به صورت آگاهانه و انتخابی ساده شده است.
مدل دامنه یا همان Domain Model مجموعه‌ای انتزاعی از دانش برای حل مشکلی است که با آن سر و کار داریم. کلمه مدل در دنیای برنامه‌نویسی کاربرد‌های فراوانی دارد و این کاربرد زیاد کمی تعریف مدل دامنه را مشکل می‌کند. برای مثال چندین الگوی مختلف مثل MVVM و MVC داریم که در آنها کلمه مدل به معانی مختلفی استفاده شده است این کاربرد‌ها باعث ایجاد پیش‌زمینه‌ای در ذهن همه گشته است. در برخی تعاریف کدهای برنامه را مدل دامنه در نظر می‌گیرند که باید بگویم مدل دامنه کدهای ما نیست. دانش ساختار‌یافته در حوزه دامنه‌ای که با آن سر و کار داریم و آن دانش پایه و اساس نرم‌افزار و سایر مصنوعات پروژه ما را تشکیل می‌دهدمدل دامنه ماست. لزوما هنگام پیاده سازی ما کل این مدل را پیاده سازی نمی‌کنیم و ممکن است بخشی از این مدل را پیاده کنیم. به جز اینکه کلمه مدل در دنیای نرم‌افزار زیاد استفاده می‌شود، در حوزه Domain Driven Design نیز از این کلمه استفاده‌های زیادی می‌شود و بعضا جا به جا هم استفاده می‌شود. برای حذف مشکلات و جلوگیری از اشتباه اینجا به تعریف سه کلمه خاص می‌پردازیم.
2. ساختار و اجزا:
پیش از اینکه به بررسی ساختار و اجزا مدل دامنه بپردازیم، می‌خواهم در مورد دو رویکرد در مدلسازی با شما صحبت کنم.
در رویکرد اول بیشترین اهمیت را داده‌های برنامه دارد و هنگام تلاش برای شناخت مسئله تلاش می‌کنیم داده‌های برنامه را شناسایی کنیم. به همین علت هنگام شناخت مسئله نام‌هایی را که می‌شنویم برای ما اهمیت زیادی دارند.
در رویکرد دوم این عملکرد است که برای ما اهمیت ویژه دارد و تلاش می‌کنیم بفهمیم چه کارهایی در سیستم انجام می‌شود و چه وقایعی رخ می‌دهد. به همین علت در فرایند شناخت مسئله بیشترین توجه‌خود را به افعال و وقایع معطوف می‌کنیم.
مدل دامنه مجموعه‌ای از انتزاعات است که برای آن از هر دو رویکرد استفاده می‌کنیم و داده‌ها و عملکرد‌های سیستم را در بر می‌گیرد البته ذکر این نکته خالی از لطف نیست که تفکر دوم نقش ویژه تری در فرایند‌های ما دارد. دقت کنید که قرار نیست در مدل دامنه عینا دنیای واقعی را پیاده کنیم، بلکه باید انتزاعی ساده شده از دنیای واقعی را ایجاد کنیم که بهترین عملکرد را برای ما به ارمغان بیاورد.
مدل دامنه ممکن است دچار دو آفت مهم شود. آفت اول در هم تنیده شدن مدل دامنه با مفاهیم و مشکلات فنی است. دومین آفت درگیری بیش از حد با مفاهیم کسب و کار است به طوری که به جز کارشناسان کسب و کار هیچ فرد دیگری توانایی درک آن را نداشته باشد. هر فردی که در فرایند انجام پروژه همکاری می‌کند باید توانایی درک مدل دامنه را داشته باشد. تنها با داشتن همچین مدلی است که می‌توانیم اطمینان حاصل کنیم راهکار نرم‌افزاری ما صحیح و مناسب خواهد بود.
2.1. مدل دامنه و دانش تخصصی:
همیشه باید این نکته را مد نظر قرار دهیم که درک کارشناسان کسب و کار از دامنه، همان مدل دامنه ما نیست. در بخش قبل در مورد کارشناس مسئله و اینکه تخصص او در دامنه برای ما منبع شناخت مسئله است صحبت کردیم. این منبع حقیقت بودن کارشناسان کسب و کار باعث می‌شود که آنها افراد مهمی در فرایند ساخت مدل انتزاعی کاربردی باشند. جایگاه کارشناسان کسب و کار و دانشی که دارند بسیار ویژه است و اغلب با گفتگو این دانش را به سایرین منتقل می‌کنند. آنها دانش خود را بدون کم و کاست و بعضا با تجربه‌های شخصی بیان می‌کنند و با توجه به شرایط باید گفته‌های ایشان پیش از استفاده پردازش و فیلتر شده و سپس در فضای مسئله مورد استفاده قرار گیرد. با توجه به اینکه در فرایند مدل سازی ما دانشی که کارشناسان کسب و کار بدست می‌آوریم را پردازش، فیلتر و ساده‌سازی می‌کنیم، ممکن است مدل ما با دانش فعلی آنها مطابقت نداشته باشد و توجه به این نکته که این مدل باید مورد پذیرش کارشناسان کسب و کار واقع شود، حیاتی است.
2.2. قابل لمس بودن:
در ابتدا درک این واقعیت که مدل دامنه مجموعه‌ای انتزاعی از دانش است، ممکن است کمی سخت باشد. درک هر موضوعی بدون داشتن معادل قابل لمس ذهنی از آن بسیار مشکل است. به همین دلیل است که بعضا انتزاعات دانش، با مصنوعات حاصل از آن اشتباه گرفته می شود، چون این مصنوعات قابل درک و لمس است. بسیاری از مستندات، تصاویر و نمودارها بعضا به عنوان مدل دامنه در نظر گرفته می‌شوند، در صورتیکه اینطور نیست و آنها صرفا راهی برای برقراری ارتباط هستند. هنگامی که به بیان دانشی در موضوعی می‌پردازیم، هرچقدر هم جزئیات و پیچ و خم‌های آن را بیان کنیم، احتمالا گفته ما باز هم نسبت به واقعیت آن موضوع ساده‌سازی شده است. به هر حال ما برداشت و دانش خود را در قالب‌هایی به نمایش در می‌آوریم و هرچقدر تلاش کنیم این نمایش جزئیات را در بر بگیرد و کامل باشد، باز هم این نمایش ما برداشتی سطحی و غیرقابل تغییر از دانش ما در لحظه تولید آن نمایش است. از آنجایی که دانش ما و انتزاعات آن در طول زمان امکان تغییر دارد، اگر قالب‌های نمایشی ما امکان تغییر نداشته باشند و بیش از حد ایستا باشند، خطر کهنگی و بیات شدن آنها را تهدید می‌کند.
2.3. مثالی برای درک بهتر:
برای اینکه موضوع انتزاعی بودن دانش و تفاوتش با مصنوعات دانش دقیق‌تر بیان شود، مثالی را با هم بررسی می‌کنیم. فرض کنید در یک بانک، نیاز به انجام پروژه‌ای احساس می‌شود. نیرو‌های فعال در بانک جلساتی را با مهندسین IT بانک برگزار می‌کنند تا نیاز‌های خود را به آنها منتقل کنند. بعد و در طول برگزاری یک تا N جلسه، مهندسین IT اقدام به مستند سازی نیازمندی‌ها در قالب‌های متفاوتی می‌کنند که البته این مستندات مدل دامنه نیست، بلکه مدل دامنه به صورت کاملا تکاملی در تعاملات مهندسین IT و کارشناسان بانک ظهور پیدا می‌کند و این مستندات تنها مصنوعات حاصل از آن مدل دامنه است. حال مهندسین IT با یک شرکت تولید نرم‌افزار شروع به تعامل می‌کنند. آنها تلاش می‌کنند تا انتزاع دانشی که به دست آورده‌اند را به کمک مستنداتی که تولید کرده‌اند و با تعامل به مهندسین نرم‌افزار منتقل کنند. نکته حائز اهمیت در این تعاملات این است که لزوما انتزاعات دانش ایجاد شده منطبق بر یکدیگر نیستند و ممکن است تفاوتی‌هایی با هم داشته باشند.
3. آشنایی با Ubiquitous Language:
یکی از مهمترین جنبه‌های مدل دامنه، زبانی است که از آن برای توصیف مدل دامنه استفاده می‌کنیم.حال بیایید بررسی کنیم Ubiquitous Language که از این به بعد برای سادگی به آن UL می‌گوییم چیست. UL یک سیستم زبانی مبتنی بر مدل است که در حوزه دامنه دقت و صحت بالایی دارد و برای برقراری ارتباط و انتقال دانش در آن حوزه مورد استفاده قرار می‌گیرد. معنای لغوی Ubiquitous همه جا حاضر یا همه‌جایی است که در اینجا منظور ما در استفاده از این کلمه همه فراگیری و همه جایی بودن آن نیست. بلکه هدف از استفاده از این کلمه القا این نکته است که این زبان در همه جنبه‌های مرتبط با مدل دامنه جاری قابل قبول و مورد استفاده است. این همه‌گیری شامل تمام مصنوعات ما نیز می‌شود. به کمک UL ارتباطات و بیانات ما سر و شکلی خاص می‌گیرد. UL پایه و اساس زبانی برای همه مصنوعات ما را ایجاد می‌کند. هنگامی که به صورت دائمی و در همه جنبه‌ها از این زبان استفاده می‌کنیم، دانش ما رفته رفته عمیق‌تر می‌شود و جنبه‌های جدید از دامنه برای ما آشکار می‌شود. استفاده همه اعضای و شرکت کنندگان در حوزه حل مسئله از این زبان در همه ارتباطات و تمامی مصنوعات برای هرچه غنی‌تر شدن آن و بهتر شدن دانش مسئله و جلوگیری از اشتباهات ضروری است.
3.1. نکاتی پیرامون Ubiquitous Language:
به طور کلی با توجه به سادگی و فراگیری زبان انگلیسی بخصوص در حوزه پروژه‌های نرم‌افزاری، معمولا از این واژه‌ها در آن استفاده می‌شود. البته در صورتی که کلمه فارسی یا مخفف خاصی به صورت تخصصی و گسترده پذیرفته شده و استفاده می‌شود، شاید جایگزینی آن با معادل انگیسی کار درستی نبود و بهتر است از همان کلمه به صورت دقیق استفاده کنیم و در جاهایی که استفاده از آن ممکن است غیر ممکن یا غیر اصولی باشد مثل سورس کد از معادل فینگیلیش استفاده شود. هنگام تشکیل UL نباید فقط روی اسم‌ها و فعال‌ها تمرکز کنیم. بلکه هر جز زبانی که در کسب و کار مورد استفاده قرار می‌گیر مثل قید، صفت، اسم صفت و ... نیز برای ما اهمیت دارد.
با توجه به اینکه UL به صورت روزمره و همه جا استفاده می‌شود موردی که در بعضی موارد مغفول واقع می‌شود، مستند سازی آن است. گستردگی و اهمیت ویژه‌ای که UL دارد، این نیاز را ایجاد می‌کند که آن را در قالبی ساده و همه فهم مستند کنیم. با این مستند سازی و اشتراک گذاری آن بین همه اعضا می‌توانیم از صحت استفاده از آن تا حدودی مطمئن شویم. دستاوردی دیگری که این مستند سازی ایجاد می‌کند، زمانی آشکار می‌شود که عضو جدیدی به تیم می‌پیوندد. در این شرایط به جایی این که هفته ها و ماه‌ها صبر کنیم تا این عضو با زبان دامنه ما آشنا شود، می‌توانیم مستند خود را با او به اشتراک گذاشته و اطمینان حاصل کنیم در مدت کوتاهی درک خوبی از کلماتی که در جای جای پروژه استفاده می‌کنیم به دست می‌آورد.
در کنار این مزایا باید به یک چالش مهم دقت کنیم و آن به روز نگهداشتن این مستند است. معمولا اضافه کردن کلمه جدید به این مستند زیاد سخت نیست. کار ما جایی گره می‌خورده که به مرور زمان و با شناخت بیشتر در مورد مسئله، تعریف ما از کلمات تغییر می‌کند و چون قبلا این کلمات در مستنند ثبت و ضبط شده اند به روز رسانی آنها در دستور کار قرار نمی‌گیرد که این ایراد می‌تواند به مرور زمان چالش‌های فراوانی را ایجاد کند.
مستند سازی UL کار پیچیده‌ای نیست و نیاز به ابزار خاصی نیز ندارد. دقت کنید که صرفا قرار است واژه‌نامه ای برای کسب و کار ایجاد کنیم. برای این کار می‌توانیم به سادگی از فایل‌های اکسل استفاده کنیم. نرم‌افزار‌های مستند‌سازی و ویکی نیز بعضا امکانات خوبی در این زمینه ارائه می‌دهند که می‌توانیم به کمک آنها واژه‌نامه خود را ایجاد و به سادگی جستجو و ویرایش و ... کنیم.
پیش از این در مورد استفاده دقیق از کلمات کسب و کار سخن گفته شد. گفتیم حتی اگر کلمه‌ی تخصصی فارسی در کسب و کار رواج دارد دقیقا از همان واژه استفاده کنیم و جاهایی که فارسی نویسی ممکن نیست هم از معادل فینگیلیش آن استفاده کنیم نه ترجمه انگلیسی آن. دلیل این کار چیست؟ در صورت استفاده از کلمات معادل، در تعاملات خودت نیاز ترجمه پیدا می‌کنیم. برای مثال وقتی با افراد تعامل می‌کنیم از واژه مرسوم فارسی استفاده می‌کنیم و در سورس کد باید دائما مواظب این ماجرا باشیم که کلمه انگلیسی x به جای کلمه فارسی y در نظر گرفته شده است. این نیاز به ترجمه هزینه‌بر خواهد بود و احتمال اشتباه را بالا خواهد برد. در ضمن افرادی که صرفا در یک جنبه از پروژه درگیر هستند مثل برنامه‌نویس ها ممکن است فقط با واژه انگلیسی آشنا شوند و اصلا معادل فارسی که هدف کسب و کار است به گوش آنها نرسد، در این شرایط به مرور زمان توانایی برقراری ارتباط با افراد کسب و کار را از دست می‌دهند و در صورت برقراری ارتباط نیز احتمال خطا و کج فهمی وجود دارد. این کج فهمی‌ها ممکن است به مرور باعث ایجاد چندین مدل دامنه شود. با یکی نگهداشتن UL و استفاده درست از آن جلوی ایجاد چندین مدل‌دامنه را می‌گیریم.
به عنوان آخرین نکته در این قسمت توجه شما را به اشتراکات زبانی دنیای کسب و کار با دنیای فنی جلب می‌کنم. یکی از چالش‌های اساسی که ممکن است با آن مواجه شویم این است که یکی از کلمات تخصصی حوزه فنی در حوزه کسب و کار نیز معنای خاصی داشته باشد. مثلا فرض کنید برای سامانه آموزشی در حال تولید نرم‌افزار هستیم. کلمه کلاس در حوزه آموزشگاهی معنایی خاص دارد و در برنامه‌نویسی شی‌گرا نیز معنا و کاربرد ویژه دارد. در چنین شرایطی هنگام استفاده از این کلمات باید دقیقا به زمینه‌ای که در آن صحبت می‌کنیم دقت کنیم و زمینه گفتگوی خود را شفاف بیان کنیم.
4. ارائه نمایش‌های مدل:
برای ارائه مدل دامنه روشهای مختلفی وجود دارد که هریک مزایا و معایب خاص خود را دارد.
زبانی که استفاده می‌کنیم بسیار مهم است، اما صرفا ارائه مدل دامنه به صورت متنی قرار نیست اتفاق بیو‌فتد. ارائه متنی به کمک UL یکی از روشهای مرسوم نمایش مدل است. استفاده از این روش بسیار ساده است و نیاز به ابزار خاصی ندارد. در کنار این سادگی یکی از معایبی که این روش دارد این است که ممکن است بیش از حد به جزئیات در متن‌ها پرداخته شود.
یکی دیگر از روشهای ارائه استفاده از تصاویر و نمودارها است. ماهیت تصاویر و نمودارها این است که جزئیات کمی دارند و مشکلی که در روشهای متنی در مورد جزئیات وجود دارد را ندارند. سرعت دریافت اطلاعات در این روش بسیار بالا است. مشکل این روش این است که در صورت نیاز به ارائه جزئیات، سربار زیادی را باید تحمل کنیم.
ارائه به کمک کدهای آزمایشی و سریع یا ایجاد پروتوتایپ نیز یکی دیگر از روشهای ارائه است. استفاده از این روش با توجه به ملموس بودن آن برای همه اعضای پروژه و دیدن نتیجه واقعی بسیار جذاب است. چالشی که در این روش ممکن است با آن مواجه شویم این است که فراموش کنیم این یک روش ارائه مدل است، نه پیاده سازی نهایی آن. یا اینکه با توجه به هزینه‌ای که در این روش ایجاد می‌شود ممکن است تلاش کنیم کدهای آزمایشی را در پیاده سازی نهایی استفاده کنیم که این کاری ممکن است کیفیت پیاده‌سازی را تحت تاثیر قرار دهد.
4.1. نکات تکمیلی در ارائه مدل:
روشهای زیادی برای ارائه وجود دارد که در حال حاضر سه تا از روشهای معمول را بررسی کردیم. هر کدام از این روش‌ها مزایا، معایب و ویژگی‌های اختصاصی خود را داشتند. یک ویژگی مشترک و مهم بین تمامی این روش‌ها وجود دارد و آن موقتی و غیر‌نهایی بودن آنها است. توجه کنید که از این روش‌ها صرفا جهت قابل لمس کردن مدل دامنه استفاده می‌کنیم دانش خود را در آن زمینه ارائه می‌دهیم و هیچ کدام پیاده سازی و دستاورد نهایی ما نیستند.
نکته دیگری که باید به آن توجه کنیم این است که این روش‌ها هیچ کدام تنها روش مورد استفاده ما نیستند و جایگزین یکدیگر نمی‌شوند، بلکه هر یک از این روش‌ها هدفی خاص را دنبال می‌کند و در همکاری با یکدیگر کمک می‌کنند که تا مدل دامنه را کامل‌تر و بهتر درک کنیم.
5. مدلسازی دامنه یا Domain Modeling:
فرایند و فعالیت‌هایی که برای ایجاد مدل دامنه از دل دانش‌های غیرساخت یافته در حوزه کسب و کار انجام می‌دهیم را مدلسازی دامنه یا Domain Modeling می‌نامیم. در اغلب موارد ایجاد مدل انتزاعی دقیق و صحیح و کامل در یک مرحله غیرقابل دست یافتن است. به دست آوردن دانش عمیق در دامنه و شناخت کامل فضای مسئله تنها با گذشت زمان و کسب تجربه اتفاق می‌افتد. هرچه بینش و دانش ما از مسئله بیشتر می شود مدل ما نیز کامل تر می‌شود. بنابراین توجه کنید که مدل دامنه به حدکمال نمی‌رسد و با هر روز افزوده شدن دانش ما نسبت به مسئله این مدل نیز کامل‌تر می‌شود.
هرچند این روش را با استفاده از متدهای سنتی مثل روش آبشاری ممکن است بتوانیم استفاده کنیم، اما این تکامل دائم دانش و بینش و همسان‌سازی مصنوعات مختلف با این بینش‌های تکامل پذیر، استفاده از این روش را به گزینه‌ای مناسب جهت همزمانی استفاده با روشهای چابک بدل می‌کند.
5.1. تحول دانش و مدلسازی دامنه:
فرایند تحول دانش به انتزاع مناسب ممکن است به روشهای گوناگونی اتفاق انجام شود. به مثالی که قبلا ارائه شد دقت کنید. هنگامی که پرسنل بانک نیازها و شرایط کسب و کار خود را ارائه می‌کنند، نیرو‌های IT ممکن است اقدام به کشیدن نمودارد و تصاویر و برقراری ارتباط بین این نمودار ها بکنند. ایجاد این مصنوعات دو دستاورد خواهد داشت، از یک سو ایجاد این نمودارها یک راه پردازش اطلاعات و ایجاد مدل است و از سوی دیگر یک ابزار ارتباطی است که مفاهیم انتزاعی را شرکت کنندگان با هم به اشتراک می‌گذارند. حتی ممکن است پرسنل بانک نیز در فرایند تولید و اصلاح این نمودارها به صورت فعال همکاری کنند. به همین دلیل فرایند درک دانش و بررسی اطلاعات پردازش نشده خودش نیز بخشی از مدلسازی دامنه است.
5.2. ابتدا تا انتهای کار:
در ابتدای راه معمولا جلسات رسمی بین اعضای پروژه برگزار می‌شود که شرکت همه اعضای و همکاری اعضای کسب و کار و تیم توسعه برای این جلسات پیشنهاد می‌شود. در جلساتی که برگزار می‌شود افراد کسب و کار دانش خود را ارائه می‌کنند و توسعه‌دهنده افرادی هستند که از این دانش در پیاده سازی مدل دامنه استفاده می‌کنند. کارشناسان کسب و کار دانش خود را ارائه می‌کنند و در صورتی که پرسشی برای تیم ایجاد شود، همانجا سوال پرسیده شده و پاسخ دریافت می‌گردد. در نهایت دانش و بینش ایجاد می‌شود و حقایق کسب و کار آشکار می‌گردد. برای جلوگیری از فراموشی این دانش کسب شده و سادگی در تبادل نظر، مستنداتی در قالب‌های متن و نمودار و ... ایجاد می‌گردد. بعد از اولین جلسات و ایجاد مدل‌های اولیه، این جلسات به شکل‌های مختلفی به طور دائمی ادامه یافته و بر مبنای مدل موجود دانش تکامل پیدا می‌کند و مدل مبتنی بر دانش جدید تکمیل می‌شود و بر مبنای مدل جدید پیاده سازی انجام می‌شود و پیاده سازی مورد آزمون پذیرش قرار گرفته و این چرخه به طور دائم در حیات نرم‌افزار ادامه می‌یابد.
6. جمع بندی:
در این قسمت به بیان مدل‌دامنه و فرایند ایجاد آن که آن را Domain Modeling می‌گوییم پرداختیم. دیدیم که در ابتدای کار شروع به جمع آوری دانش در زمینه دامنه مورد بررسی می‌کنیم و این دانش‌ها ممکن است کاملا پراکنده و ساختار نیافته باشند. شناسایی دامنه و فضای مسئله و دانش در آن حوزه اجزایی را در اختیار ما قرار می‌دهند که برای ادامه کار به آنها نیاز داریم. ابتدا شروع به پردازش، دسته‌بندی و فیلتر کردن دانشی که به دست آوردیم می‌کنیم و این فرم ساده و انتزاعی که از مسئله به دست می‌آوریم مدل دامنه ما است. سپس سعی می‌کنیم به کمک روشهای مختلفی مثل رسم نمودار و ... این مدل انتزاعی را قابل لمس کنیم به طوری که همه اعضای تیم توانایی درک آن را داشته باشند و کارشناسان کسب و کار صحبت آن را تایید کنند. دستاورد مهمی که در این فرایند‌ها داریم UL نیز نباید فراموش شود.
پ.ن: سال نو میلادی مبارک.
