در روش طراحی دامنه رانه [1]، هنگام طراحی مدل دامنه [2] موجودیت هایی رو به رو خواهیم شد که دارای شناسه هستند. به عبارت دیگر در طول زمان می بایست به یک موجودیت دسترسی پیدا کرد و این ویژگی دوم آنهاست که وجود شناسه نیز برای پاسخ گویی به آن است. به عبارت دیگر این موجودیت ها دارای شناسه هستند تا بتوان در زمان های مختلف مورد دسترسی قرار گیرند. برای مدل کردن این موجودیت ها از الگویی به نام entity استفاده می شود.

به منظور پیاده سازی این الگو و اختصاص شناسه به entity ها، سه راهکار وجود دارد. راهکار اول اختصاص شناسه های موجود در دامنه مساله [3] به entity هاست. برای این کار باید دقت کرد که اولا این شناسه ها واقعا شناسه هستند (مانند شناسه ملی برای انسان ها و یا کد شابک برای کتاب ها) و ثانیا در طول زمان تغییر نمی کنند.

 راهکار دوم استفاده از شناسه های تولید شده در دامنه پاسخ [4] است. برای انجام این کار نیز سه روش وجود دارد؛ استفاده از اعداد شمارشی، استفاده از guid و یا استفاده از رشته [5] هایی که از ترکیب ویژگی های entity به وجود می آیند. استفاده از اعداد شمارشی نیازمند استفاده از راهکاری جهت دخیره سازی حالت است تا در صورتی که فرآیند [6] در حال اجرا با مشکل مواجه شد، این حالت از بین نرود. 

راهکار سوم واگذاری مسئولیت تولید شناسه به پایگاه داده است. مشکل اصلی این راهکار این است که اختصاص شناسه به entity ها مستلزم یک تراکنش [7] با پایگاه داده خواهد بود و این بدان معناست که یک تراکنش کسب و کار ممکن است در بیش از یک تراکنش سیستم انجام شود. برای غلبه بر این مشکل از روشی به نام hi-low استفاده می شود. در این روش برای هر نوع entity شناسه ها به صورت بازه های مشخص (مثلا صد تایی) از پایگاه داده دریافت می شود و شماره آخرین شناسه دریافتی در پایگاه داده ذخیره می شود.

نکته ای که در طراحی entity ها نباید از آن غافل شد، توجه به اصل [8] SRP است. با توجه به اینکه entity ها وظیفه مدیریت شناسه را به عهده دارند در مواردی که با value object ای در ارتباط هستند، می بایست رفتارها [9] به value object انتساب داده شوند.  



[1] - Domain driven design
[2] - Domain model
[3] - Problem domain
[4] - Solution domain
[5] - String
[6] - Process
[7] - Transaction 
[8] - Single Responsibility Principle 
[9] - Behavior