Aggregate — Domain-Driven Designda ma’lumot izchilligi chegarasi sifatida boshqariladigan entity va value objectlar guruhi. Uning tashqi kirish nuqtasi aggregate root deb ataladi. Tashqi kod ichki obyektlarni bevosita o‘zgartirmaydi; root metodlari invariantlarni tekshirib, butun guruhning yaroqli holatda qolishini ta’minlaydi.
Aggregate root
Root aggregate identifikatorini ifodalaydi va repository orqali yuklanadi. Masalan, Order root, OrderLine esa uning ichki entitysi bo‘lishi mumkin. Mahsulot qo‘shish Order.addLine orqali bajariladi; bu metod dublikat, maksimal miqdor yoki order holati kabi qoidalarni tekshiradi. Ichki linega repositorydan mustaqil murojaat qilish model chegarasini buzadi.
Boshqa aggregate ichki entityga to‘g‘ridan-to‘g‘ri obyekt havolasi saqlash o‘rniga root identifikatoriga murojaat qiladi. Bu graphning cheksiz kengayishini va bir transactionda ko‘p obyektni yuklashni kamaytiradi. Kerakli ma’lumot snapshot yoki value object sifatida ko‘chirilishi mumkin.
Invariant va transaction
Aggregate ichidagi invariant bitta biznes amali yakunida darhol bajarilishi kerak. Order total uning line summalariga teng bo‘lishi yoki tasdiqlangan orderga yangi line qo‘shilmasligi shunday qoidalardir. Odatda bitta transaction bitta aggregate instanceini o‘zgartiradi va optimistic concurrency orqali parallel yozishlardan himoyalanadi.
Bir amal bir nechta aggregatega ta’sir qilsa, ularning barchasini doim bitta katta transactionga birlashtirish aggregate chegarasini kattalashtiradi. Domain event, process manager yoki saga orqali keyingi o‘zgarishlar bajarilishi mumkin. Bunda kontekstlar yoki aggregate lar orasida eventual consistency qabul qilinadi va muvaffaqiyatsizlik uchun retry hamda kompensatsiya belgilanadi.
Chegarani tanlash
Aggregate birgalikda ekranda ko‘rinadigan barcha ma’lumot emas. Chegara qaysi invariant atomik saqlanishi kerakligiga asoslanadi. Juda katta aggregate ko‘p ma’lumot yuklaydi, parallel yangilash mojarolarini oshiradi va masshtablashni cheklaydi. Juda kichik aggregate esa muhim qoida uchun tashqi muvofiqlashtirishni ko‘paytirishi mumkin.
Savol odatda “qaysi obyektlar birga ishlatiladi” emas, “qaysi qoida bir transaction ichida buzilmasligi kerak” tarzida qo‘yiladi. Hisobot va qidiruv ehtiyoji read model orqali qondirilishi mumkin; ular write model aggregate chegarasini belgilamasligi lozim.
Lifecycle
Aggregate root factory yoki domen xizmati orqali yaroqli boshlang‘ich holatda yaratiladi. Ichki entitylar root amallari bilan qo‘shiladi va olib tashlanadi. Aggregate o‘chirilsa, ichki obyektlarning persistence lifecyclei ham odatda rootga bog‘liq. Tashqi aggregatega tegishli yozuv esa cascade bilan tasodifan o‘chirilmasligi kerak.
Event sourcing ishlatilganda aggregate o‘z tarixidagi eventlarni qayta qo‘llab holatni tiklaydi. Command invariantdan o‘tsa, yangi event chiqariladi. Snapshot ko‘p eventli aggregate tiklanishini tezlashtiradi, lekin event tarixining o‘rnini bosmaydi.
Repository va versiyalash
Repository aggregate rootni ID bo‘yicha oladi va yagona birlik sifatida saqlaydi. Ichki collectionni alohida repository orqali o‘zgartirish root nazoratini chetlab o‘tadi. ORM ishlatilsa, mapping aggregate chegarasiga mos cascade, ownership va transaction qoidalarini ifodalashi kerak.
Optimistic locking version raqami bilan amalga oshirilishi mumkin. Ikki so‘rov bir xil eski versiyani o‘qib, parallel saqlashga urinsa, bittasi conflict oladi. Ilova holatni qayta yuklaydi va biznes amalini qayta baholaydi; database yozuvini ko‘r-ko‘rona ustidan yozmaydi.
Testlash
Aggregate unit testi command yoki domen metodini chaqirib, yangi holat, invariant xatosi va chiqarilgan eventlarni tekshiradi. Database talab qilinmasa test tez ishlaydi. Repository mapping esa alohida integration testda saqlash va qayta yuklash bilan tasdiqlanadi.
Bog‘liq tushunchalar
Domain-Driven Design, Aggregate root, Entity, Value Object, Invariant, Repository, Domain event