آموزش طراحی دامنه محور Domain Driven Design و ریفکتور کردن یک Anemic Domain Model

آموزش طراحی دامنه محور Domain Driven Design و ریفکتور کردن یک Anemic Domain Model یکی دیگر از آموزش های گروه آموزشی پرووید می باشد که در این قسمت آن را به شما معرفی می کنیم. این بسته ی آموزشی نیز یکی از دوره های آموزشی دیگر که در حوزه ی فارسی سازی آموزش های انگلیسی تنظیم شده است می باشد. عنوان این بسته ی آموزشی آموزش Domain Driven Design و ریفکتور کردن یک Anemic Domain Model است که با نام اصلی Refactoring from Anemic Domain Model Towards a Rich One از شرکت Pluralsight منتشر شده است.

Domain Driven Design چیست؟

طراحی دامنه محور یا همان Domain Driven Design در واقع درک نیازهای واقعی کسب و کار مشتری است. ما باید درباره دامنه های مختلف مانند بانکداری، مخابرات، زنجیره تامین، مراقبت های بهداشتی و... دانش داشته باشیم. بنابراین در اینجا دامنه به معنی دانش کسب و کار درباره صنعت خاص است. به طور مشابه طراحی دامنه محور تمرکز بیشتری نسبت به نیازهای کسب و کار دارد نه به تکنولوژی. برای شروع نوشتن یک سیستم، باید بدانیم که مشتری چه چیزی را مد نظر دارد، در حین فاز اولیه هیچگاه درباره برنامه نویسی و معماری آن فکر نمیکنید. هدف اصلی شما درک تمام شرایط کسب و کار مشتری و چگونگی مدل دامنه مورد نیاز او است.

بنابراین چیزی که ما به دنبال آن هستیم بحث با مشتری درباره نیازهای کسب و کار او است. Domain Driven Design صرفا بر اساس این فرضیات برای ترسیم کردن نیازهای کسب و کار در مدل دامنه است. طراحی دامنه محور همه چیز درباره چگونگی طراحی مدل دامنه شماست. به این معنا که هر کلاس دامنه باید یک رابطه مستقیم با  آنچه که در دامنه کسب و کار است داشته باشد.

Anemic Domain Model چیست؟

در Domain Driven Design واژه ی Anemic Domain Model به Domain Model ی گفته می‌ شود که در آن Domain Object ها حاوی مقدار ناچیزی Business Logic باشند. Business Logic ی که شامل Validation، Business Rule و موارد دیگر می باشد. این واژه اولین بار توسط آقای Martin Fowler عنوان شد که این روش را یک ضد الگو (Anti-pattern) می دانست. بر اساس حرف آقای Martin Fowler "مشکل اصلی این نوع طراحی و این ضد الگو این است که دقیقاً متضاد ایده ی اصلی طراحی شی گرا است، که بر اساس آن Object ها باید حاوی Data و Behavior باشند." آقای Martin Fowler بر این باور است که Anemic Domain Model یک سبک از طراحی Procedural است.

چیزی که متضاد با طراحی شی گرا است. در یک Anemic Domain Model کلاس‌ های جداگانه‌ ای برای در بر داشتن Business Logic پیاده سازی شده اند که State مربوط به Domain Object ها را تغییر می دهند. آقای Martin Fowler نام این کلاس های جداگانه را Transaction Script گذاشته است. دقت کنید که این نوع طراحی در برنامه های جاوا معمول و مرسوم است. در برنامه های دات نت و در معماری برنامه های Three-Layered Services Application نیز استفاده می شوند. در این نوع معماری از برنامه های دات نت به اینگونه کلاس های جداگانه Business Entity می گوییم.

انتقال منطق کسب‌وکار از سرویس‌ها به Domain Class ها

در یک Anemic Domain Model، کلاس‌های دامنه معمولاً داده‌ها را نگه می‌دارند، در حالی که بخش قابل‌توجهی از منطق کسب‌وکار در سرویس‌های بیرونی قرار می‌گیرد. آموزش Refactoring from Anemic Domain Model Towards a Rich One با بررسی چنین مدلی آغاز می‌شود و سپس نشان می‌دهد چگونه می‌توان مسئولیت‌های مرتبط را به خود کلاس‌های دامنه منتقل کرد. نمونه‌هایی مانند Refactoring کلاس Customer و انتقال منطق به Promote Customer کمک می‌کنند این تغییر را در قالب کد بررسی کنید. هدف، سازمان‌دهی رفتاری است که به داده‌های یک شیء مربوط می‌شود، به‌جای پراکنده ماندن آن در چند سرویس.

در جریان این بازطراحی، Encapsulation اهمیت ویژه‌ای دارد؛ زیرا کلاس باید بتواند تغییر وضعیت خود را از مسیرهایی کنترل‌شده انجام دهد. برای مثال، اگر تغییر Status مشتری تابع قواعد مشخصی باشد، قرار دادن منطق Promote Customer در مدل دامنه می‌تواند محل اجرای این قواعد را روشن‌تر کند. آموزش همچنین معایب کد موجود و یک حفره امنیتی را بررسی می‌کند تا نشان دهد ضعف در طراحی فقط مسئله زیبایی یا خوانایی نیست و ممکن است بر صحت رفتار برنامه نیز اثر بگذارد. این رویکرد برای توسعه‌دهندگانی کاربرد دارد که می‌خواهند مدل‌های داده‌محور را به مدل‌هایی با رفتار و مسئولیت‌های مشخص‌تر تبدیل کنند.

استفاده از Value Object برای مدل‌سازی دقیق‌تر قواعد دامنه

یکی از مراحل مهم در این آموزش، استفاده از Value Object ها به‌عنوان اجزای تشکیل‌دهنده Domain Model است. برخلاف Entity که هویت آن در مدل اهمیت دارد، Value Object معمولاً بر مقدار و ویژگی‌هایش تکیه می‌کند. این تفاوت در نمونه‌ای مانند Dollars قابل‌مشاهده است؛ به‌جای نمایش مبلغ با یک مقدار خام، می‌توان نوعی ساخت که مفهوم مبلغ و قواعد مرتبط با آن را در خود نگه دارد. چنین مدلی به خوانایی کد کمک می‌کند و باعث می‌شود مفاهیم دامنه به شکل دقیق‌تری در ساختار برنامه بازتاب پیدا کنند.

آموزش همچنین به Decouple کردن Domain Model از Data Contract ها می‌پردازد تا مدل کسب‌وکار به قالب‌هایی که برای انتقال یا تبادل داده استفاده می‌شوند وابستگی مستقیم نداشته باشد. جمع کردن Validation Rule ها در یک مکان واحد نیز کمک می‌کند قواعد مرتبط با اعتبارسنجی در نقاط پراکنده و ناسازگار تکرار نشوند. در کنار این موارد، بازطراحی Customer، Constructor و Status نشان می‌دهد که چگونه تغییرات کوچک در ساختار کلاس می‌توانند مرزهای مدل را روشن‌تر کنند. مباحث سازمان‌دهی Application Services Layer و Best Practice های Domain Modeling نیز مکمل این مسیر هستند و به تفکیک مسئولیت‌های مدل دامنه از هماهنگی عملیات کاربردی کمک می‌کنند.