جهت مشاهده‌ی چالش هفته‌ی قبل اینجا کلیک کنید.
پیش‌زمینه:
در این چالش، به دنیای واقعی یک سازمان که از DDD استفاده می‌کند، قدم می‌گذاریم. در یک گفت‌وگوی روزمره، پرسشی در مورد بهترین روش مدل‌سازی آدرس مشتری در یک سیستم سفارش‌گیری مطرح شده است. این سوال ساده، ما را به دنیای پیچیده و جذاب مدل‌سازی دامنه می‌برد.
چالش این هفته با چالش‌های قبلی متفاوت‌تر است! این سوال از دل یک گفتگوی روزمره در جمع بچه‌های تهران جاگ که هفته پیش به عنوان مهمان در جمع آنها بودم، مطرح شده است و نشان می‌دهد که حتی ساده‌ترین سوال‌ها می‌توانند به بحث‌های پیچیده و جذاب در دنیای DDD منجر شوند.
سناریو:
تصور کنید شما یک متخصص DDD در شرکت DDD-To-The-Rescue.Com هستید. شما در حال طراحی یک سیستم سفارش‌گیری هستید که مشتریان می‌توانند چندین آدرس مختلف برای ارسال سفارشات خود ثبت کنند و هر سفارش نیز می‌تواند شامل محصولات مختلفی باشد.
شما در حال مدل کردن مسئله آدرس‌های مشتری برای یک سفارش هستید. مشتری چندین می‌تواند آدرس‌های متفاوتی داشته باشد. همچنین در یک سفارش محصولات مختلفی وجود دارد. شما از الگوهای تکنیکالDDD برای پیاده‌سازی محصول استفاده می‌کنید.
بین شما و سایر افراد این بحث پیش می‌آید که آدرس را Value Object در نظر بگیریم یا Object. آدرس‌ها را چطور؟ با توجه به این سناریو آشنا به سوالات زیر پاسخ دهید.
صورت مسئله:
با توجه به سناریو بالا به سوالات زیر پاسخ دهید:
- آیا آدرس یک مشتری باید به عنوان یک Value Object (VO) یا Entity در نظر گرفته شود؟
- بهترین روش برای مدل‌سازی چندین آدرس برای یک مشتری چیست؟ از VO یا Entity استفاده کنیم؟
- تفاوت اساسی بین Value Object و Entity چیست و چرا این تفاوت در این سناریو مهم است؟
- آیا واقعا تفاوت بین این دو مفهوم آنقدرها که فکر می‌کنیم اساسی و ضروری است؟
- چگونه باید مشتری را مدل‌سازی کنیم؟
- تاثیر انتخاب مدل مناسب برای آدرس‌ها بر نحوه ذخیره‌سازی و بازیابی اطلاعات چیست؟
- چگونه باید آیتم‌های موجود در یک سفارش را مدل‌سازی کنیم؟
اهداف چالش:
- درک عمیق‌تر تفاوت بین Value Object و Entity
- تحلیل یک سناریوی واقعی و انتخاب بهترین مدل برای آدرس مشتری
- بررسی تأثیر تصمیمات مدل‌سازی بر طراحی پایگاه داده
- تقویت مهارت‌های مدل‌سازی دامنه در DDD
نکات کلیدی:
- Context is key: در انتخاب بین VO و Entity، زمینه مسئله بسیار مهم است.
- Behavior vs. state: VOها معمولاً بر اساس مقدارشان شناخته می‌شوند و رفتاری ندارند، در حالی که Entityها هویت منحصر به فردی دارند و می‌توانند تغییرات حالت را تجربه کنند.
- Persistence: نحوه ذخیره‌سازی VOها و Entityها متفاوت است. VOها معمولاً به عنوان بخشی از یک Aggregate ذخیره می‌شوند، در حالی که Entityها می‌توانند به صورت جداگانه ذخیره شوند.
