شما اینجا هستید: خانه / مقالات آموزشی / مقدمه ای بر Domain-Driven Design

مقدمه ای بر Domain-Driven Design

Domain Driven Design (به اختصار DDD) مبحثی است که در سال های اخیر به شدت مورد توجه جامعه ی نرم افزاری دنیا بوده و رویکرد بسیاری از شرکت های نرم افزاری را برای تحلیل و توسعه ی نرم افزارها به شدت مورد تاثیر قرار داده است. این مبحث اولین بار در سال ۲۰۰۳ توسط آقای Eric Evans در کتاب Domain-driven design مطرح گردید.

 

  • Domain-Driven Design چیست؟

DDD رویکردی برای تولید و توسعه ی نرم افزارهای بزرگ با فرآیندها و قوانین زیاد، پیچیده و در حال تغییر می باشد. اصطلاح Domain به حوزه و دامنه ی اصلی فعالیت نرم افزار اطلاق می شود که نرم افزار برای پیاده سازی آن توسعه می یابد. هسته ی اصلی DDD مجموعه ای از مفاهیم و تکنیک هاست که برای تحلیل Domain و ساخت یک مدل از روی آن (Domain Model) به کار برده می شود. تمرکز و توجه اصلی این رویکرد بر روی توسعه ی این مدل می باشد. تحلیل و طراحی Domain Model اختصاصا به منظور تولید نرم افزار در ابعاد Enterprise و با فرآیند های پیچیده و زیاد مناسب می باشد. Domain Model طراحی شده با جزئیات دقیق بوده و مفاهیم و قوانین (Business Rules) در آن پیاده سازی میشوند.

DDD بر زوایای دیگری از فرآیند توسعه ی نرم افزار نیز تاثیر گذار است. برای مثال تاکید زیادی در ارتباط دو طرفه ی تیم توسعه ی نرم افزار و کاربران متخصص Domain (برای مثال انبارداران در سیستم انبار) دارد. از آنجا که ممکن است در این ارتباط دو طرفه، تیم توسعه ی نرم افزار در فهمیدن برخی مفاهیم و مسائل دچار اشتباه و دوگانگی شوند لذا ایجاد زبان یکسان بین دو تیم (Ubiquitous Language) در مورد مفاهیم Domain امری الزامی است. DDD همچنین راهکارهایی برای تقسیم نرم افزار به بخش های جدا و مستقل (مفهوم Bounded Context) و همچنین ارتباط این بخش ها با یکدیگر ارائه میکند. این امر سبب می شود تا فرآیند توسعه ی نرم افزار به صورت موازی بین چند تیم انجام شده و همچنین معماران سیستم را قادر می سازد تا از معماری ها و تکنولوژی های مختلف در بخش های مختلف استفاده نمایند.

همانطور که مطرح شد، رویکرد Domain-Driven برای نرم افزارهای بزرگ و پیچیده مناسب می باشد. لذا استفاده از آن در پروژه های کوچک و ساده  و یا پروژه هایی که صرفا نیاز به ذخیره و خواندن اطلاعات دارند و Business خاصی ندارند، ممکن است تنها زمان و هزینه ی پروژه را افزایش داده و مزیتی خاصی به همراه نداشته باشد.

  •  مفهوم Domain Model

در اغلب پروژه های نرم افزاری، دغدغه ی اصلی تیم توسعه، طراحی دقیق و درست فرآیند ها و قوانین نرم افزار می باشد. زمان و هزینه ای که صرف تحلیل، پیاده سازی و تست فرآیندها و Business نرم افزار می شود بسیار بیشتر از زمان و هزینه ای است که صرف موارد فنی و زیر ساخت نرم افزاری می شود. تیم توسعه ی نرم افزار می تواند با تمرکز بر روی Domain و طراحی مدل (Domain Model) از روی آن و همچنین با رعایت مفاهیم و تکنیک های DDD از پیاده سازی درست این فرآیندها اطمینان پیدا می کنند.

Domain Model مدلی انتزاعی از دامنه ی فعالیت نرم افزار است که توسط تیم توسعه ی نرم افزار در قالب یک مدل شی گراء طراحی می شود. این مدل ممکن است در طول زمان و با تغییر فرآیند ها تغییر یافته و تکمیل شود. Domain Model تنها یک ساختار داده ای نبوده و مجموعه ای از داده ها، رفتارها و قوانین (Business Rule) می باشد. از آنجا که مهم ترین چیز در طراحی Domain Model اطمینان از صحت فرآیند ها و Business نرم افزار می باشد، لذا هنگام طراحی از پرداختن به دغدغه ها و نکات فنی زیر ساختی و دیتابیسی خودداری می شود (مفهوم Persistence Ignorance).

اکثر مباحث مطرح شده در DDD در راستای تحلیل و توسعه ی Domain Model می باشد که در قالب مفاهیمی مانند Entity، Aggregates، Value Object و … پیاده سازی می شود. در مطالب بعدی به بررسی این مفاهیم و تکنیک ها خواهیم پرداخت.

درباره هادی احمدی

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

13 نظر

  1. سلام
    با تشکر از مقاله بسیار کاربردی تون. ممنون میشم اگه امکان داره لینک دانلود کتاب Domain-Driven Design: Tackling Complexity in the Heart of Software رو بگین ؟

  2. با سلام خدمت شما
    مقاله شما بسیار عالی بود مچکرم
    فقط اگر امکان دارد راجب مبحث business نرم افزار که در مقاله گفتید توضیحات بیشتری می خواستم. در کل منظور از business نرم افزار چیست؟

    • هادی احمدی

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

  3. سلام، بسیار عالی…دقیق و شفاف

  4. سلام .
    از مطلب خوبتون ممنونم.
    DDD یک معماری محسوب میشه ؟

  5. با سلام
    الگو های ساده تر از ddd برای تولید نرم افزار هم وجود دارن اگه هست میشه اسمی از این الگو ها هم ببرید.؟
    اگر بخایم یه تاریخچه ای از این الگو ها رو مطالعه کنیم می تونید راهنمای کنید از کجا باید شروع کنیم؟؟؟

    • هادی احمدی

      سلام سجاد جان

      اگر منظورتون الگوهای پیاده سازی Domain Layer می باشد، میتونید کتاب زیر رو مطالعه بفرمایید :

      Patterns, Principles, and Practices of Domain-Driven Design
      Chapter 5 – Domain Model Implementation Patterns

      که به بررسی الگوهایی مثل Transaction Script و غیره پرداخته است.

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

    • هادی احمدی

      سلام محمد جان

      پیشنهاد میکنم بعد از مطالعه ی کتاب ها و بررسی دقیق مثال ها پیاده سازی آنها، یک Problem Domain از دنیای واقعی را انتخاب کنید و شروع به مدل کردن آن کنید.

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

نظر بدهید

آدرس ایمیلتان منتشر نمیشودگزینه های الزامی ستاره دار شده اند *

*

شما می‌توانید از این دستورات HTML استفاده کنید: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

رفتن به بالا