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

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

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

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

الف) 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 مانند نمودارهای کامپوننت( به درک بهتر روابط بین اجزا و طراحی دقیق تر معماری کمک میکند.