مفهوم DDD یا Domain-Driven Design در سال 2003 توسط Eric Evans مطرح شد. این رویکرد به طراحی نرمافزار بر اساس دامنه (Domain) و نیازهای کسبوکار تمرکز دارد. DDD به دو بخش اصلی تقسیم میشود: Strategic Design و Tactical Design. در این بخش، به بررسی مفاهیم پایهای DDD و چگونگی غلبه بر پیچیدگی در نرمافزار میپردازیم.
غلبه بر پیچیدگی در قلب نرمافزار
عنوان کتاب اریک ایوانز، "Tackling Complexity in the Heart of Software"، به خوبی هدف DDD را نشان میدهد. در این کتاب، مفهوم Complexity (پیچیدگی) به عنوان یکی از چالشهای اصلی در توسعه نرمافزار مطرح میشود.
پیچیدگی چیست؟
پیچیدگی به معنای وجود المانهای زیاد و روابط پیچیده بین آنهاست. برای مثال، بازی شطرنج به دلیل تعداد مهرهها، قوانین حرکت و استراتژیهای مختلف، یک سیستم پیچیده محسوب میشود. در نرمافزار نیز، پروژههایی مانند سیستمهای تدارکات یا حسابداری به دلیل وجود قوانین و فرآیندهای پیچیده، ذاتاً پیچیده هستند.
تفاوت بین پروژههای ساده و پیچیده
Domain
به محدودهای از دانش یا فعالیت گفته میشود که نرمافزار برای آن طراحی میشود. برای مثال، حسابداری، انبارداری، تدارکات و خزانهداری نمونههایی از دامنهها هستند.
Domain Model
نمایش نرمافزاری از دامنه واقعی است. این مدل شامل کلاسها، روابط و قوانینی است که نیازمندیهای کسبوکار را پوشش میدهد. هدف اصلی در DDD، ایجاد یک مدل دقیق و منحصر به فرد است که به خوبی نیازهای دامنه را بازتاب دهد.
Ubiquitous Language
یکی از عوامل اصلی پیچیدگی در نرمافزار، تفاوت در زبان و مفاهیم بین Domain Experts (متخصصین دامنه) و تیم توسعه است. برای کاهش این پیچیدگی، DDD مفهوم زبان فراگیر را معرفی میکند.
زبان فراگیر، زبانی است که در تمامی بخشهای پروژه از جمله کسبوکار، مستندات، تستها، مدلها و کد به صورت یکسان استفاده میشود. این زبان باعث میشود که همه اعضای تیم (چه متخصصین دامنه و چه توسعهدهندگان) از مفاهیم یکسانی استفاده کنند و ارتباطات بهطور واضح و بدون ابهام انجام شود.
Perspective
یکی دیگر از عوامل پیچیدگی، تفاوت در زاویه نگاه افراد مختلف به یک موضوع است. برای مثال، در یک سازمان، واحدهای مختلف مانند انبار، پخش و مالی ممکن است به یک کالا از زوایای متفاوتی نگاه کنند:
این تفاوتها میتواند باعث ایجاد پیچیدگی در مدلسازی و طراحی نرمافزار شود.
به طور کلی، DDD به دو بخش Strategic Design و Tactical Design تقسیم می شود.
در strategic design تمرکز بر روی تقسیم مسائل بزرگ به مسائل کوچکتر است. برای مثال در مساله تدارکات، می توانیم آن را به بخش های تامین، پخش، کنترل موجودی، انبار و بخش های مختلفی تقسیم کنیم.
در tactical design، وارد جزئیات هر یک از زیردامنهها میشویم و به طراحی مدلها و اجزای داخلی آنها میپردازیم. برای مثال، در زیردامنه کنترل موجودی، مفاهیمی مانند Check-In, Check-Out و Stock مطرح میشوند.
Subdomain
یک دامنه معمولاً از چندین زیردامنه تشکیل شده است. برای مثال، در یک سیستم تدارکات، زیردامنههایی مانند تامین، انبار، پخش و کنترل موجودی وجود دارند.
بنابراین strategic design بر روی شناسایی حوزه های مختلف، ارزش گذاری strategic بر روی بخش ها و ایجاد تیم برای توسعه پروژه ها تمرکز می کند. بخشی که business value بالایی دارد را مشخصا به تیم ضعیف نمی دهیم.
در تصویر زیر یک مثال از یک فروشگاه اینترنتی را ملاحظه می کنید.
در این فروشگاه قسمت های تامین، انبار، ارسال، اطلاع رسانی، فروش و بخش مختلف دیگری را مشاهده می کنید.
انواع Subdomain
Core Domain
زیردامنهای که بیشترین ارزش کسبوکاری را دارد و موفقیت در آن باعث موفقیت کل سیستم میشود. برای مثال، در یک سیستم تاکسی اینترنتی، بخش اصلی (Core Domain) مربوط به مدیریت سفرها و رانندگان است.
Supporting Domain
زیردامنههایی که برای عملکرد Core Domain ضروری هستند، اما به خودی خود ارزش اصلی را ایجاد نمیکنند. برای مثال، مدیریت انبار در یک سیستم فروش.
Generic Domain
زیردامنههایی که نیازهای عمومی را پوشش میدهند و میتوانند از خارج خریداری شوند. برای مثال، سیستم اطلاعرسانی در یک سامانه فروش.
جمعبندی
مفهوم DDD یک رویکرد برای غلبه بر پیچیدگی در پروژههای نرمافزاری است.
در بخشهای بعدی، به بررسی بیشتر مفاهیم DDD و نحوه پیادهسازی آن در پروژههای واقعی خواهیم پرداخت.
