الگوی طراحی دامنه محور چیست؟
یک رویکرد طراحی نرم‌افزار برای توسعه نرم‌افزار است که بر روی مدلسازی نرم‌افزار برای انطباق با یک دامنه بر اساس ورودی از کارشناسان دامنه و توسعه برنامه‌نویسی یک مدل دامنه تمرکز دارد، از اصول و ایده‌های تحلیل شی‌گرا استفاده می‌کند و درکی غنی از فرایندها و قوانین مربوط به یک دامنه دارد. توسط اریک ایوانز در سال 2003 در کتابش منتشر شد و این رویکرد را توسط فهرستی از الگوها توصیف می‌کند. در آن زمان این ایده بیشتر توسط مجموعه‌ای از پزشکان گسترش یافت که کتاب‌های مختلف دیگر و دوره‌های آموزشی را توسعه دادند.
طراحی داده محور سیستمی با انتزاع بالا است که جنبه‌های انتخابی یک دامنه را توصیف می‌کند و برای حل مشکلات مربوط به دامنه مورد استفاده قرار می‌گیرد. ساختار و زبان کد نرم‌افزار مانند نام کلاس‌ها، نام متدها، متغیرهای کلاس و ... باید با دامنه کسب و کار منطبق شوند. DDD پیاده‌سازی را به یک مدل در حل تکامل متصل می‌کند. این رویکرد به ویژه برای دامنه‌های پیچیده مناسب است که دارای منطق بی‌نظم هستند و نیاز به سازماندهی دارند و سیستم‌های نرم‌افزاری باید مبتنی بر مدل دامنه توسعه یافته خوب باشند. DDD تاکید دارد که توسعه این مدل‌ها در نرم‌افزار انجام شوند برخلاف رویکردهای قبلی که روی کاغذ انجام می‌شدند. همچنین تکامل این مدل‌ها در طول عمر محصول نرم‌افزاری انجام شوند برخلاف روش‌های قبلی که از قبل انجام می‌شد.
مدل دامنه محور دارای فوایدی مانند قابلیت نگهداری است. مایکروسافت فقط برای دامنه‌های پیچیده آن را توصیه می‌کند که سبب فوایدی در فرمول‌بندی درک روشنی از دامنه می‌گردد. منظور از دامنه در طول توسعه برنامه حوزه دانش و فعالیتی است که منطق برنامه حول آن می‌چرخد. در این مدل معماری، لایه دامنه یا منطق دامنه یکی از لایه‌های مشترک در یک معماری چند لایه شی‌گرا است و به عنوان منطق کسب و کار است. منطق کسب و کار یک برنامه به قوانین سطح بالاتر برای نحوه تعامل اشیا کسب و کار با یکدیگر و اصلاح داده مدلسازی شده اشاره دارد.
انواع مدل‌ها
طراحی دامنه محور چندین نوع مدل را تشخیص می‌دهد. مثلا یک موجودیت با ویژگی‌های آن شناخته نمی‌شود و با هویت آن شناسایی می‌شود. مثلا هر صندلی هواپیما در هر پرواز دارای شماره منحصر به فردی است که با آن شناسایی می‌شود. ولی یک شی دارای ویژگی‌هایی است و تغییر ناپذیر است ولی هویت در آن مفهومی ندارد. مثلا افراد فقط به اطلاعات روی یک کارت ویزیت توجه می‌کنند به جای آن که بین کارت‌های منحصر به فرد تمایز قائل شوند.
مدل‌ها می توانند رویدادها چیزی که اتفاق می‌افتد را نیز تعریف کنند. رویداد دامنه، رویدادی است که برای کارشناسان دامنه مهم است. مدل‌ها می‌توانند توسط یک موجودیت ریشه در کنار هم قرار بگیرند و به یکدیگر متصل شوند. اشیای خارج از این جمع، می توانند ارجاعاتی به ریشه داشته باشند ولی به هیچ یک از اشیای داخل این مجموعه نمی‌تواند ارجاع دهد. ریشه این مجموعه سازگاری تغییرات در مجموعه را بررسی می‌کند. مثلا رانندگان به هر کدام از چرخ‌های ماشین را به صورت جداگانه کنترل نمی‌کند و آن‌ها به راحتی رانندگی می‌کنند. در این زمینه ماشین مجموعه از چند شی دیگر مانند موتور، ترمز، چراغ‌های جلو و ... است.
اهداف طراحی دامنه محور
کار کردن با مدل‌ها
در طراحی دامنه محور یک شی ایجاد شده از یک شی اغلب از خود شی جدا می‌شود. مثلا یک repository یک شی با متدهایی برای بازیابی اشیای دامنه از یک مخزن داده مانند پایگاه داده است. همچنین یک کارخانه نیز یک شی با متدهایی برای ایجاد مستقیم اشیای دامنه است. زمانی که بخشی از عملکرد برنامه از نظر مفهومی به هیچ شی‌ای وابستگی ندارد، معمولا به عنوان یک سرویس در نظر گرفته می‌شود.
تعدادی از اصطلاحات رایج در طراحی دامنه محور
طراحی دامنه محور دارای تعدادی از مفاهیم سطح بالا است که برای ایجاد و اصلاح مدل‌های دامنه می‌تواند در ارتباط و ترکیب با یکدیگر مورد استفاده قرا گیرند. در ادامه تعدادی از این مفاهیم بررسی می‌گردند.
منطق دامنه: منطق دامنه هدف مدلسازی و منطق کسب و کار است. در این جا قوانین کسب و کار مواردی مانند ایجاد، ذخیره‌سازی و اصلاح داده را مشخص می‌کند.
مدل دامنه: مدل داده شامل ایده‌ها، دانش‌ها، داده‌ها، معیارها و اهدافی مربوط راه حل مسئله مورد نظر است. شامل همه قوانین و الگوها برای مقابله با منطق کسب و کار پیچیده است و برای برآوردن نیازهای کسب و کار مفید است.
زیردامنه: یک دامنه شامل چندین زیردامنه است مه به بخش‌های مختلف منطق تجاری اشاره دارد. مانند یک فروشگاه آنلاین که کاتالوگ، موجودی و تحویل یک محصول به عنوان زیردامنه‌های آن هستند.
الگوهای طراحی: الگوهای طراحی در مورد استفاده مجدد از کد هستند. بدون توجه به پیچیدگی مسئله، قبل از برنامه‌نویسی شی‌گرا از الگویی برای حل مسئله استفاده شده است. تقسیم مسئله به چندین بخش سبب حل آن می‌گردد.
موجودیت: شی‌ای که توسط یک thread محکم و پیوسته مشخص شناسایی می‌شود، برخلاف اشیای سنتی که توسط ویژگی‌هایشان شناسایی می‌شوند.
شی ارزش (Value Object): یک شی تغییر ناپذیر و غیر قابل تغییر است که دارای ویژگی‌ها و صفاتی است ولی شناسه و هویت متمایز ندارد.
رویداد دامنه: شی‌ای که برای ثبت یک رویداد گسسته مربوط به فعالیت مدل در یک سیستم استفاده می‌شود. در حالی که همه رویدادها در سیستم می‌توانند ردیابی شوند. یک رویداد دامنه فقط برای رویدادهایی ایجاد می‌شوند که برای کارشناسان دامنه مهم هستند.
کاردینالیتی انجمن‌ها: هر چه کاردینالیتی انجمن‌ها بین کلاس‌ها بیشتر باشد، پیچیدگی ساختار بیشتر می‌شود. با افزودن موارد واجد شرایط می‌توان کاردینالیتی را کاهش داد. همچنین انجمن‌های دو جهته نیز می‌تواند پیچیدگی را افزایش دهد.
تجمیع (Aggregate): خوشه‌ای از موجودیت‌ها و اشیای ارزش با مرزهای مشخص در اطراف گروه است. به جای آن که هر موجودیت یا شی ارزش همه عملیات را خودش انجام دهد، به جمعی از بخش‌ها یک ریشه متراکم واحد اختصاص داده می‌شود. در این صورت اشیای خارجی به هر موجودیت یا شی ارزش در مجموعه دسترسی مستقیم ندارند و فقط می‌توانند به ریشه مجموعه دسترسی داشته باشند که از آن برای ارسال دستورات به گروه استفاده می‌شود. این کار با بسیاری از عملیات کدگذاری واقعی که در الگوهای طراحی پوشش داده می‌شوند، مرتبط است. ریشه به صورت سراسری شناسایی می‌شود در حالی که بقیه به صورت محلی شناسایی می‌شوند. ریشه بررسی می‌کند که همه نامتغیرها ارضا می‌شوند یا خیر. تابع حذف هر موجودیت‌ها را در مجموعه حذف می‌کند. زمانی که یک شی تغییر می‌کند باید همه نامتغیرها ارضا شوند.
سرویس: یک سرویس یک عمل یا شکلی از منطق کسب و کار است که به طور طبیعی با قلمرو اشیا سازگار نیست. اگر تعدادی از عملکردها وجود داشته باشند اما به یک موجودیت یا شی ارزش مرتبط نباشد، احتمالا یک سرویس است. سرویس دامنه یک لایه اضافی شامل منطق دامنه است که بخشی از مدل دامنه است. در عین حال سرویس برنامه، لایه دیگری است که شامل منطق برنامه نیست که برای هماهنگ کردن فعالیت‌های دامنه در بالای مدل دامنه قرار دارد.
مخازن دامنه: با مخازن مربوط به کنترل نسخه متفاوت است. مخزن DDD سرویسی است که از یک رابط سراسری برای دسترسی به همه موجودیت‌ها و اشیای ارزش که در یک مجموعه متراکم خاص هستند، استفاده می‌کند و مجموعه‌ای از موجودیت‌های کسب و کار است. متدهایی برای ایجاد، اصلاح و تشخیص اشیا در مجموعه را فراهم می‌کند و زیرساخت داده را آسان می‌کند و نگرانی های زیرساختی را کاهش می‌دهد. از سرویس مخزن برای ایجاد کوئری‌های داده استفاده می‌شود. هدف مخازن حذف قابلیت‌های کوئری داده داخل منطق کسب و کار مدل‌های شی است.
کارخانه‌ها: DDD استفاده از یک کارخانه را پیشنهاد می‌دهد که منطق ایجاد اشیا و aggregateهای پیچیده را کپسوله‌بندی می‌کند و تضمین می‌کند که client اطلاعی از عملکرد درونی دستکاری اشیا ندارد.
محتوا: تنظیماتی در یک کلمه یا جمله که معنای آن را تعیین می‌کند. جملات مربوط به یک مدل را می‌توان فقط در یک محتوا (زمینه) درک کرد.
زبان فراگیر: بخش اصلی این ایده است. زبانی است که در اطراف مدل دامنه ساختار یافته است، تمام اصطلاحات حول مدل دامنه در سیستم نرم‌افزاری ایجاد و تعبیه می‌شوند و توسط همه اعضای تیم برای اتصال تمام اعضای تیم به نرم‌افزار استفاده می‌شود. یک متدلوژی است که به زبانی اشاره دارد که کارشناسان دامنه و توسعه‌دهندگان از آن استفاده می‌کنند
محتوای محدود: توصیف یک مرز (معمولا یک زیر سیستم یا کار یک تیم خاص) که در یک مدل خاص تعریف شده و قابل اجراست. یک الگوی مرکزی در طراحی دامنه محور است که شامل پیچیدگی برنامه است و مدل‌ها و تیم‌های بزرگ را مدیریت می‌کند. در این قسمت پیاده‌سازی کد بعد از تعریف دامنه و زیردامنه انجام می‌شود. یک موجودیت در محتواهای مختلف می‌تواند نام‌های متفاوتی داشته باشد. زمانی که یک زیر مدل در یک محتوای محدود تغییر می‌کند، کل سیستم نیازی به تغییر ندارد. به همین دلیل توسعه‌دهندگان از وفق‌دهندگان مختلف بین محتواها استفاده می‌کنند.
نقشه‌های محتوا: نقشه‌ها (نگاشت‌ها) محتوا یک فرایند طراحی است و جایی است که نقاط برخورد و تغییرات بین زمینه‌های محدود به صراحت ترسیم و نگاشت می‌شوند. روی نقشه‌برداری از چشم‌انداز موجود تمرکز می‌کند و بعدا از تغییرات واقعی جلوگیری می‌کند. از ادغام پیوسته در یک محتوای محدود برای نرم کردن انشعاباتی که از درک‌های متفاوت ناشی می‌شوند، استفاده می‌شود. ادغام مکرر کد، خودکارسازی تست و به کارگیری زبان فراگیر قطعه قطعه شدن در محتوای محدود را به سرعت برجسته می‌کند.
مزایای طراحی دامنه محور
تسهیل ارتباط: با تاکید زودهنگام بر سازماندهی و ایجاد یک زبان مشترک و فراگیر مربوط به مدل دامنه پروژه، تیم‌ها ارتباط در کل چرخه عمر توسعه را آسان‌تر پیدا می کنند. طراحی دامنه محور هنگام بحث در مورد جنبه‌های برنامه به اصطلاحات تخصصی فنی کمتری نیاز دارد، زیرا زبان فراگیر که در ابتدا ایجاد شد، اصطلاحات فنی ساده‌تری را برای جنبه‌های فنی‌تر تعریف می‌کند.
بهبود انعطاف‌پذیری: به دلیل آن که طراحی دامنه محور به شدت مبتنی بر مفاهیم تحلیل و طراحی شی‌گرا است. تقریبا همه چیز در مدل دامنه مبتنی بر یک شی است. بنابراین کاملا ماژولار و کپسوله شده است که سبب می‌شود اجزای مختلف یا کل سیستم به صورت منظم و مستمر بهبود یابد و تغییر کند.
تاکید روی رابط دامنه: به دلیل آن که طراحی دامنه محور تمرینی از ایجاد مفاهیم دامنه و آن چه را که کارشناسان دامنه در پروژه توصیه می‌کنند هست، برنامه‌هایی را تولید می‌کند که برای نمایش دامنه مورد نظر مناسب است برخلاف برنامه‌هایی که در درجه اول روی UI/UX تاکید دارند. در حالی که یک تعادل روشن مورد نیاز است. تمرکز بر دامنه یعنی روش DDD می‌تواند محصولی را تولید کند که به خوبی مورد توجه مخاطبان مربوط به دامنه قرار گیرد.
معایب طراحی دامنه محور
نیاز به تخصص دامنه قوی: با وجود افراد متخصص و خلاق در تیم توسعه، اگر حداقل یک متخصص دامنه در تیم وجود نداشته باشد که جزئیات و داخل و بیرون حوزه مورد نظر برای اعمال روی برنامه را بشناسد، در این صورت طراحی دامنه محور ممکن است به ادغام یک یا چند عضو از تیمی دیگر بیرون از تیم مورد نظر نیاز داشته باشد که می‌توانند به عنوان متخصصان دامنه در طول چرخه توسعه عمل کنند.
تشویق به تمرینهای تکراری: تمرینهای DDD به طور قوی متکی به تمرین‌هایی با تکرار ثابت و ادغام مداوم برای ایجاد پروژه‌ای انعطاف‌پذیر هست که می‌تواند در صورت لزوم خود را تنظیم کند. برخی از سازمان‌ها ممکن است با این روش مشکل داشته باشند. به ویژه اگر تجربه‌های قبلی آن‌ها تا حد زیادی به مدل‌های توسعه با انعطاف‌پذیری کم مانند مدل آبشاری مربوط باشد.
نامناسب برای پروژه‌های خیلی فنی: اگر چه DDD برای برنامه‌هایی با پیچیدگی زیاد که منطق کسب و کار نسبتا پیچیده است، مناسب است ولی برای برنامه‌هایی با پیچیدگی دامنه حاشیه‌ای و کم و پیچیدگی فنی زیاد مناسب نیست. اگر چه DDD به شدت بر روی نیاز به کارشناسان دامنه و اهمیت آن‌ها برای تولید زبان فراگیر مناسب و سپس مدل دامنه‌ای که پروژه بر اساس آن ایجاد شده است، تاکید می کند پروژه‌ای که از نظر فنی به شدت پیچیده است، ممکن است برای متخصصان دامنه از نظر درک چالش برانگیز باشد و مشکلاتی را ایجاد کند که ممکن است نیازمندی‌ها یا محدودیت‌های فنی کاملا توسط اعضای تیم درک نشده باشند.
«این مطلب، بخشی از تمرینهای درس معماری نرم‌افزار در دانشگاه شهیدبهشتی است»
منابع و مراجع:
