طراحی دامنه-محور

**طراحی دامنه-محور** یا **DDD**  یک رویکرد رایج در طراحی نرم‌افزار است که تمرکز اصلی آن، مدل کردن نرم‌افزاری است که دامنه نرم‌افزار با دانش دریافتی از متخصصان آن دامنه، مطابقت داشته باشد.

در این رویکرد طراحی، ساختار و زبان کد نرم‌افزار (نام کلاس‌ها، نام متدها، نام متغیرهای کلاس) باید با دامنه کسب و کار مطابق داشته باشد. به عنوان مثال اگر قرار است نرم‌افزاری جهت پردازش درخواست های وام پیاده‌سازی شود، این نرم‌افزار باید شامل کلاسی با عنوان مشتری (Customers) و متدی با عناوینی همچون پذیرش درخواست (AcceptOffer) و انصراف (Withdraw) باشد.

مهندسان نرم‌افزار، با پیاده‌سازی برنامه به روش طراحی دامنه-محور، اهداف زیر را دنبال می‌کنند:
* گذاشتن بیشترین تمرکز بر روی دامنه اصلی (Core Domain) و منطق دامنه؛
* پایه‌گذاری طرح‌های پیچیده بر اساس مدل دامنه؛
* آغاز یک همکاللری خلاقانه بین متخصصان فنی و متخصصان دامنه برای اصلاح مکرر یک مدل مفهومی که قرار است، مسائل یک دامنه خاص را حل کند.

منتقدان طراحی دامنه-محور بر این عقیده هستند که در این رویکرد، معمولاً توسعه دهندگان مجبور هستند، تا حد زیادی از انزوا و کپسوله سازی را اجرا کنند تا یک مدل را به عنوان ساختاری خالص و مفید حفظ کنند. در حالی که طراحی دامنه-محور، مزایایی همچون قابلیت نگهداری بالا را دارد، توصیه مایکروسافت این است که تنها برای دامنه‌های پیچیده‌ای که در آن‌ها، استفاده از مدل باعث افزایش درک مشترک از دامنه می‌شود، از این رویکرد استفاده شود.

اصطلاح طراحی دامنه-محور توسط اریک ایوانز در کتاب خود با همین عنوان که در سال ۲۰۰۳ منتشر شد، ابداع شده‌است.

## '''DDD در Django'''

### راهنمای سبک اعمال Domain-Driven Design ([[طراحی دامنه-محور]]) در Django ([[جنگو (چارچوب نرم‌افزاری)]])

#### پیشینه Domain-Driven Design
DDD یک رویکرد توسعه نرم افزار است که تمرکز اصلی آن بر روی مدل سازی دقیق دامنه (Domain) کسب وکار است. اریک اوانز در کتاب خود به نام

"Domain-Driven Design: Tackling Complexity in the Heart of Software"

این مفاهیم را معرفی کرد.

#### مفاهیم کلیدی DDD از دیدگاه فاولر:
**الف) Domain Model**

مدل دامنه نمایش انتزاعی از دانش و فعالیت های مربوط به یک حوزه خاص کسب وکار است. این مدل باید:

- مفاهیم و روابط کلیدی حوزه را منعکس کند.

- به زبان کسب وکار (نه زبان فنی) بیان شود.

- به صورت اشیاء و عملیات پیاده سازی شود.

در این راهنمای سبک، مدل دامنه به جای اینکه فقط در مدلهای Django قرار گیرد، در لایه های خاص خود سازماندهی میشود.

**ب)** **Ubiquitous Language (زبان همه جا حاضر)**

یک زبان مشترک بین توسعه دهندگان و متخصصان حوزه که در تمام مراحل توسعه استفاده میشود. این زبان باید:

- در کد، اسناد و گفتگوها یکسان باشد.

- از اصطلاحات فنی غیرضروری پرهیز کند.

- مفاهیم حوزه را دقیقاً همانطور که متخصصان حوزه می فهمند بیان کند.

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

استفاده از اصطلاحات کسب وکار در نام گذاری:

مثال:  ()Order.is_eligible_for_discount به جای ()Order.check_discount .

**ج) Multiple Canonical models**

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

در این راهنمای سبک، این مفهوم با تقسیم سیستم به حوزه های مستقل (Bounded Contexts) پیاده سازی میشود.

مثال: مدل User در حوزه orders ممکن است با مدل User در حوزه payments متفاوت باشد.

**د)  Bounded Context (حوزه محدود)**

مرز مشخصی که در آن یک مدل دامنه خاص معنا پیدا میکند و تعاریف دقیق دارد. ویژگی های کلیدی:

- هر حوزه محدود مسئولیت های مشخصی دارد.

- مدل های مختلف می توانند در حوزه های محدود مختلف تعاریف متفاوتی داشته باشند.

- ارتباط بین حوزه ها باید به دقت مدیریت شود.

در این راهنمای سبک، هر حوزه محدود به عنوان یک اپلیکیشن Django جداگانه پیاده سازی میشود.

**اصول کلیدی در پیاده سازی:**

1. جداسازی حوزه ها: هر حوزه کسب وکار (مانند سفارشات، محصولات) باید در ماژول خود قرار گیرد و وابستگی حداقلی به دیگر حوزه ها داشته باشد.

2. تمرکز بر : Domain Logic منطق کسب وکار باید در سرویس ها و مدل های دامنه قرار گیرد، نه در ویوها یا کنترلرها.

3. استفاده از الگویRepository  : برای جداسازی لایه دسترسی به داده از لایه منطق کسب وکار.

4. تعریف واضح مرزها: ارتباط بین حوزه ها باید از طریق واسط های تعریف شده و واضح انجام شود.

5. تست پذیری: با جداسازی مناسب لایه ها، نوشتن تست های واحد آسان تر میشود.

**توضیح مدلسازی معماری با نمودار های UML :**

1. اینترفیس ها: شامل کنترلرهای API و ویوهای وب که به عنوان نقطه ورود سیستم عمل میکنند.

2. سرویس های حوزه: حاوی منطق کسب وکار و از طریق واسط های تعریف شده با لایه های دیگر ارتباط برقرار میکنند.

3. Repositoryها : مسئول دسترسی به داده ها و جداسازی لایه ذخیره سازی از منطق کسب وکار.

4. مدل ها: نمایش مفاهیم حوزه با استفاده از Ubiquitous Language.

5. هسته مشترک ( Shared Kernel  ) : شامل قابلیت های مشترک بین چندین حوزه.

**مزایای این معماری:**

1. قابلیت نگهداری: تغییر در یک حوزه تأثیر کمی بر حوزه های دیگر دارد.

2. قابلیت تست: هر جزء را میتوان به صورت مستقل تست کرد.

3. انعطاف پذیری: میتوان تکنولوژی های مختلف را برای حوزه های مختلف انتخاب کرد.

4. مقیاس پذیری: هر حوزه را می توان به صورت مستقل مقیاس داد.

5. شفافیت: ساختار کد منعکس کننده ساختار کسب وکار است.

**نتیجه گیری**

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

## جستارهای وابسته
* بازنمود دانش
* هستی‌شناسی (علم اطلاعات)
* شبکه معنایی
* معناشناسی

## منابع
* 
رده:معماری نرم‌افزار
رده:طراحی نرم‌افزار
رده:فلسفه‌های توسعه نرم‌افزار