📌Domain Driven Design : A Model Expressed in Software
در تصور معمول ما، یک شخص دارای هویتی است که از تولد تا مرگ و حتی فراتر از آن امتداد می‌یابد. ویژگی‌های فیزیکی آن شخص تغییر می‌کنند و در نهایت از بین می‌روند. نام ممکن است تغییر کند. روابط مالی به وجود می‌آیند و از بین می‌روند. حتی یک ویژگی هم در انسان وجود ندارد که تغییرناپذیر باشد؛ با این حال، هویت باقی می‌ماند. آیا من همان فردی هستم که در پنج‌سالگی بودم؟ این نوع پرسش متافیزیکی در جستجوی مدل‌های دامنه (domain models) مؤثر اهمیت دارد.
با بیانی کمی متفاوت: آیا کاربرِ اپلیکیشن اهمیتی می‌دهد که من همان فردی هستم که در پنج‌سالگی بودم؟
دو واریز (deposit) با مبلغ یکسان، به یک حساب یکسان، در یک روز یکسان، همچنان دو transaction متمایز محسوب می‌شوند.بنابراین دارای هویت هستند و یک ENTITY به شمار می‌آیند.
از سوی دیگر، attribute مبلغ این دو transaction احتمالاً instanceهایی از یک Object از نوع money هستند. این مقادیر هیچ هویتی ندارند، زیرا تمایز میان آن‌ها هیچ سودمندی‌ای ندارد.
در واقع، ممکن است دو Object دارای هویت یکسان باشند، بدون آنکه attributeهای یکسانی داشته باشند یا حتی الزاماً از یک class یکسان باشند.
در واقع، ممکن است یک چیز واحد در دنیای واقعی در یک domain model به‌صورت یک ENTITY نمایش داده شود یا اصلاً چنین نباشد.
برای مثال، یک application جهت رزرو صندلی در یک استادیوم ممکن است صندلی‌ها (seat) و شرکت‌کنندگان (attendee) را به‌عنوان ENTITY در نظر بگیرد.
در حالت assigned seating که روی هر بلیت شماره صندلی درج شده است، صندلی یک ENTITY محسوب می‌شود. شناسه (identifier) آن شماره صندلی است که در محدوده‌ی استادیوم یکتا (unique) است.
صندلی ممکن است attributeهای دیگری نیز داشته باشد، مانند:
• موقعیت مکانی
• داشتن یا نداشتن دیدِ مسدود
• قیمت
اما تنها شماره صندلی یا ترکیب یکتای ردیف (row) و موقعیت (position) برای شناسایی و تمایز صندلی‌ها استفاده می‌شود.
از سوی دیگر، اگر رویداد از نوع general admission باشد به این معنا که دارندگان بلیت در هر صندلی خالی که پیدا کنند می‌نشینند نیازی به تمایز میان صندلی‌های منفرد وجود ندارد.
در این حالت، تنها تعداد کل صندلی‌ها اهمیت دارد. با اینکه شماره صندلی‌ها همچنان به‌صورت فیزیکی روی صندلی‌ها حک شده‌اند، هیچ نیازی نیست که software آن‌ها را ردیابی کند.
در واقع، اگر مدل شماره صندلی خاصی را به بلیت‌ها نسبت دهد، این یک خطای مدلسازی خواهد بود؛ زیرا در یک رویداد با general admission چنین محدودیتی وجود ندارد.
در چنین شرایطی، صندلی‌ها دیگر ENTITY نیستند و هیچ identifierای نیز موردنیاز نخواهد بود.
🔖هشتگ‌ها :
#DDD #DomainModel
#Entity