Entity — Domain-Driven Designda vaqt davomida identifikatori saqlanib qoladigan va holati o‘zgarishi mumkin bo‘lgan domen obyektidir. Entityning muhim xususiyati atributlarining aynan tengligi emas, uning kim ekanidir. Ismi yoki manzili o‘zgargan mijoz o‘sha identifikator bilan bir xil mijoz bo‘lib qoladi.
Identifikator
Entity identifikatori biznes tomonidan berilgan tabiiy kalit yoki tizim yaratgan sun’iy qiymat bo‘lishi mumkin. Pasport raqami kabi tabiiy identifikator real ma’noga ega, lekin o‘zgarishi, qayta ishlatilishi yoki maxfiy bo‘lishi mumkin. UUID yoki ketma-ket son odatda texnik jihatdan barqaror, ammo domen foydalanuvchisi uchun ma’nosiz.
Identifikator entity yaratilganda yoki persistence bosqichida beriladi. Taqsimlangan tizimda serverga yozishdan oldin UUID yaratish obyektni xabar va bog‘lanishlarda oldindan tanishga imkon beradi. Database sequence esa ixcham, lekin markaziy bazaga murojaatni talab qiladi. Tanlov butun tizimdagi uniqueness va lifecycle talabiga mos keladi.
Tenglik tushunchasi
Ikki entityning barcha maydonlari bir xil bo‘lsa ham identifikatorlari boshqa bo‘lsa, ular alohida obyektlardir. Aksincha, bir entityning maydonlari yangilanganda uning tengligi yo‘qolmaydi. Koddagi equality va hash hisoblash shu semantikani aks ettirishi kerak, ayniqsa entity collection yoki cache kaliti sifatida ishlatilsa.
Identifikatori hali berilmagan transient entitylarni taqqoslash ehtiyotkorlikni talab qiladi. Ularni barcha null ID sabab teng deb hisoblash xato. ORMning proxy obyektlari va tur merosi ham class bo‘yicha equality tekshiruvini murakkablashtirishi mumkin.
Holat va xatti-harakat
Entity faqat getter va setterlardan iborat ma’lumot qutisi bo‘lishi shart emas. U o‘z invariantlarini saqlaydigan domen metodlariga ega bo‘ladi. Order.confirm amali holatni tekshiradi, tasdiqlash vaqtini belgilaydi va zarur domain eventni yaratishi mumkin. Tashqi kod status maydonini ixtiyoriy o‘zgartirsa, noto‘g‘ri holatga o‘tish xavfi paydo bo‘ladi.
Invariant entityning o‘zida yoki u kiradigan aggregate root orqali himoyalanadi. Bir amal bir nechta entityni muvofiqlashtirsa, transaction chegarasi aggregate asosida belgilanadi. Har bir bog‘langan obyektni bitta ulkan graph sifatida yuklash masshtablash va consistency muammosini keltiradi.
Persistence bilan bog‘lanish
Entity ko‘pincha database yozuvi sifatida saqlanadi, lekin domen tushunchasi jadvalga teng emas. Bitta entity bir necha jadvalda saqlanishi yoki eventlardan qayta tiklanishi mumkin. ORM mapping persistence tafsilotini yengillashtiradi, ammo lazy loading, lifecycle callback va public setterlar domen modelini buzmasligi kerak.
Repository aggregate rootlarni identifikator bo‘yicha topish va saqlash interfeysini beradi. Query uchun alohida read model ishlatilsa, har hisobotni entity graph orqali qurish talab qilinmaydi. Entity biznes amallarini, projection esa o‘qish ehtiyojini ifodalaydi.
Entity va Value Object
Value Object identifikatori bilan emas, qiymatlari bilan aniqlanadi va odatda immutable bo‘ladi. Money(100, UZS) boshqa ayni qiymatdagi Moneyga teng. Customer esa bir xil ism va telefonli boshqa Customer bilan teng emas. Entity ichidagi manzil, pul yoki sana oralig‘i value object sifatida model qilinishi mumkin.
Har database jadvaliga entity yaratish shart emas. Texnik join jadvali, audit yozuvi yoki vaqtinchalik DTO domen identitetiga ega bo‘lmasligi mumkin. Entity tanlovi obyektning biznes lifecyclei va “shu obyekt aynan o‘shami” savoliga ehtiyoj borligiga asoslanadi.
Bog‘liq tushunchalar
Domain-Driven Design, Value Object, Aggregate, Identity, Repository, Domain event, Invariant