طراحی مبتنی بر دامنه Domain Driven Design

مروری بر رویکرد طراحی مبتنی بر دامنه Domain Driven Design

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

• تمرکز اصلی پروژه بر روی دامنه مسئله و منطق حاکم بر دامنه
• مبنای طراحی مسائل پیچیده بر مدلی که از دامنه ساخته می شود
• برقراری یک تعامل پویا بین تیم تکنیکال و صاحبان کسب و کار Domain Experts  به صورت متداوم جهت درک کامل مدل مفهمومی که مسئله موجود در دامنه را مشخص می کند

دامنه Domain: حوزه دانش و یا فعالیت، حوزه عملی که کاربر از برنامه کاربردی جهت حل مسئله استفاده می کند دامنه نرم افزار نام دارد.

مدل Model: یک سیستم انتزاعی که به توصیف جنبه های منتخب دامنه می پردازد و می تواند برای حل مسائل مربوط به دامنه مورد استفاده قرار گیرد

زبان فراگیر Ubiquitous Language : زبان ساختار یافته مربوط به مدل دامنه و مورد استفاده توسط اعضای تیم توسعه و هم چنین صاحبات کسب و کار برای برقراری ارتباط بین همه فعالیت های تیم در تعامل با نرم افزار

صاحبان کسب و کار، کارشناسان کسب و کار Domain Experts : کارشناس دامنه شخصی است که دارای دانش و تخصص ویژه در یک حوزه خاص می باشد، یک حسابدار یک Domain Expert در دامنه حسابداری می باشد

دراین مجموعه مقالات از Domain Experts ها با عنوان صاحبان یا کارشناسان کسب و کار یاد می شود

لیست کتاب های تالیف شده در مورد طراحی با عمر ده ساله Domain Driven Design DDD

• Domain-driven-design-tackling-complexity-in-the-heart-of-software By Eric Evans
• Applying Domain Driven Design and Patterns By Jimmy Nilsson
• Implementing Domain Driven Design By Vaughn Vernon
• Professional Domain Driven Design Patterns By Scott Millett

این کتاب ها را می توانید از وب سایت دنیای کتاب الکترونیکی و زبان اصلی کامپیوتر دانلود کنید.

هم چنین برای پیگیری آخرین اخبار در توییتر می توانید هشتگ #DDDesign را جستجو کنید.

در این مجموعه مقاله در مورد مسائل زیر بحث خواهیم کرد:

• چرا Domain Driven Design برای ما مهم است؟
• رویکردی که Domain Driven Design ارایه می دهد چگونه است؟
• مدل کردن مسئله در نرم افزار
• کامپوننت های اصلی DDD
• مدیریت پیچیدگی های مسئله با استفاده از DDD
• توسعه برنامه با استفاده از DDD مبتنی بر درخواست مشتری

با اولین سوال شروع می کنیم:

چرا Domain Driven Design  برای ما مهم است؟

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

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

رویکرد Domain Driven Design بیشتر برای حل مسائل پیچیده کاربرد دارد، استفاده از DDD به نوبه خود از مسائل پیچیده به شمار می آید.

رویکردی که Domain Driven Design ارایه می دهد چگونه است؟

یکی از ابعاد مهم در پیاده سازی نرم افزار با رویکرد مبتنی بر دامنه DDD تعامل هر چه بیشتر با Domain Experts است.Domain Expert مشتریان یا اشخاص متخصص و آشنا به کسب و کار می باشد که بر مسئله درخواستی مشتری اشراف کامل دارند اما در حوزه تکنیکال و پیاده سازی نقشی ندارند. بعد دیگر مدل کردن مسئله به همراه جزییات و شکستن آن به زیرمجموعه های مجزا از هم دامنه است که هر کدام از این بخش ها Sub-Domain نامیده می شوند.

به عنوان مثال شرکت سازنده سفینه های که ماموریت رفتن به فضا را دارند فرض کنید:

زیر مجموعه های متصور و جدا از هم برای این دامنه به شرح زیر است

• فروش Sales
• خرید موارد مورد نیاز Purchase Material
• مدیریت کارمندان Manage Employees
• مهندسی Engineering
• حسابداری  Accounting
• بازاریابی  Marketing

با استفاده از DDD در واقع شما مسئله را با الگوریتم تقسیم و غلبه Divide and Conquer حل می کنید

رویکرد DDD مسائل را با دید تفکیک بخش های مهم و مستقل و الگوی Separation of Concerns Pattern مورد بررسی قرار داده و پیاده سازی هر کدام از زیر مجموعه های استخراج شده از مرحله قبل درقالب پیاده سازی Sub-Domain ها انجام می گیرد. این تفکیک ها بیشتر بر اساس کلیات مسئله یا همان دامنه صورت خواهد گرفت و جزییات پیاده سازی و مسائلی هم چون نحوه ذخیره سازی اطلاعات در بانک در این سطح نادیده گرفته می شوند.

مزایای رویکرد مبتنی بر دامنه Domain Driven Design

دراین بخش به مزایای استفاده از رویکرد مبتنی بر دامنه می پردازیم و شرح می دهیم که چه مزیتی به رویکرد های دیگر دارد:

• انعطاف پذیری

DDD طراح را راهنمایی می کند با شکستن صورت مسئله اصلی به بخش های کوچک تر و مستقل قابلیت توسعه بخش های مختلف برنامه کاربردی را به صورت موازی فرآهم آورد، با این فرآیند می توان به راحتی بخش های کوچک را بدون Side Effect روی بخش های دیگر تغییر و ارتقا داد

• دید مشتری/ چشم انداز شفاف مسئله

با این رویکرد توسعه برنامه کاربردی کاملا با نیاز های مشتری منطبق بوده و پاسخ های برنامه کاربردی بر اساس صورت مسئله های مشتری تولید خواند شد

• مدیریت و پیاده سازی مسائل پیچیده

DDD یک مسیر شفاف و سر راست برای حل مسئله های پیچیده ارایه می دهد

• سازمان دهی خوب و تست آسان

تفکیک و شکستن مسئله بزرگ به بخش های کوچک و مستقل یک سازمان مناسب برای برنامه کاربردی و تست آسان می باشد

• کسب و کار متمرکز در برنامه کاربردی

با پیاده سازی دانش مسئله در بخش هایی به نام Bounded Context ، هم چنین در صورتی که از رویکرد DDD به شکل کلان در طراحی استفاده نشود کماکان الگو ها و رویکرد ها در بخش های مختلف قابل به کارگیری و سود بردن از مزایای آن هست

مد نظر داشته باشید که DDD برای مسائل پیجیده مقرون به صرفه است و نه حتی برای حوزه هایی که بیشتر پیچیدگی تکنیکال در پیاده سازی دارند.

مشکلات یا معضلات رویکرد طراحی مبتنی بر دامنه Domain Driven Design

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

منحنی یادگیری رویکرد DDD جزو منحنی های باسطح High دسته بندی می شود، که به معنی دشواری یادگیری این رویکرد است، وجود اصول و قواعد جدید Principles، الگوهای جدید patterns، فرآیند های جدید تجزیه و تحلیل مسئله از عوامل اصلی پیچیدگی یادگیری این رویکرد توسعه نرم افزار است.

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

هم چنین دربخش قبل ذکر شد که این رویکرد برای دامنه هایی که پیچیدگی در پیاده سازی تکنیکی برنامه کاربردی است نیز کاربرد ندارد و تمرکز این رویکرد بر پیچیدگی موجود در دامنه کسب و کار است.

تشکیل تیمی که بر رویکرد DDD تسلط کافی داشته باشند یا متقاعد کردن آنها به یادگیری این رویکرد و هزینه و زمان مورد نیاز برای یادگیری و استفاده از این رویکرد جزو ریسک های استفاده از رویکرد Domain Driven Design می باشد.

جمع بندی در تصویر کلی

تصویری که در زیر می بینید از کتاب آقای Eric Evans با عنوان Navigation Map آورده شده و یک تصویر کلی از بخش های مختلف رویکرد DDD و هم چنین حوزه هایی که بایستی مورد توجه قرار گیرد به شما می دهد، در این تصویر نکات کاربردی و مهم نیز روی پیکان های نشان دهنده روند آورده شده، درک جزییات و فرآیند کلی این تصویر نیازمند شرح مفصلی است که در مقالات آتی ارایه خواهد شد.