DDD — murakkab dasturiy tizimni biznes sohasi modeli asosida loyihalash yondashuvi. To‘liq nomi Domain-Driven Design. DDD kod, arxitektura va jamoa tilini real biznesdagi tushunchalar, qoidalar va jarayonlar bilan moslashtirishga intiladi.
DDD barcha loyihalar uchun majburiy framework emas. U ayniqsa qoidalari murakkab, terminlari ko‘p va uzoq muddat rivojlanadigan tizimlarda foydali.
Domain
Domain — software xizmat qiladigan faoliyat sohasi.
Masalan:
- bank;
- logistika;
- sug‘urta;
- e-commerce;
- ta’lim;
- kadastr;
- ishga yollash.
Domainni tushunmasdan faqat texnik model yaratish muhim biznes qoidalarini yo‘qotishi mumkin.
Domain expert
Biznes jarayonini chuqur biladigan mutaxassis.
U developerga:
- termin;
- qoida;
- istisno;
- jarayon;
- maqsad;
- risk
ni tushuntiradi.
Developer va ekspert muntazam hamkorlik qilib modelni aniqlashtiradi.
Ubiquitous language
Jamoa bir xil termin va ma’nolardan foydalanadi.
Agar biznes “bron” desa, kodda ham Reservation yoki kelishilgan shu ma’nodagi nom ishlatiladi.
Bir termin turli contextda boshqa ma’no bersa ular ajratiladi.
Til meeting, hujjat, test va kodda bir xil bo‘ladi.
Model
Domain model real dunyoning barcha detallarini ko‘chirmaydi.
U software uchun muhim tushuncha va qoidalarni ifodalaydi.
Model doimiy ravishda o‘zgaradi.
Yangi bilim kod va terminology’ni refactor qilishga olib keladi.
Subdomain
Katta domain kichik qismlarga bo‘linadi.
Turlari:
Core subdomain biznesning asosiy raqobat ustunligini beradi.
Generic qism tayyor service yoki standard yechim bilan bajarilishi mumkin.
Bounded Context
Model va ubiquitous language aniq chegara ichida izchil ishlaydi.
Bir xil “User” so‘zi identity contextda account, billing contextda customer, delivery contextda recipient ma’nosiga ega bo‘lishi mumkin.
Ularni bitta ulkan universal modelga majburan birlashtirish chalkashlik yaratadi.
Context Map
Bounded contextlar orasidagi relationshipni ko‘rsatadi.
Masalan:
- upstream;
- downstream;
- shared kernel;
- customer-supplier;
- conformist;
- anti-corruption layer;
- published language.
Bu integration va ownershipni tushuntiradi.
Entity
Identity’si vaqt davomida saqlanadigan domain object.
Masalan:
- Order;
- Customer;
- Contract;
- Parcel.
Entity fieldlari o‘zgarishi mumkin, ammo identity bir xil qoladi.
Equality ko‘pincha IDga bog‘liq.
Value Object
Identity emas, qiymati bilan aniqlanadigan immutable object.
Misollar:
- Money;
- Address;
- DateRange;
- Coordinates;
- EmailAddress.
Value object validation va behaviorni o‘zida saqlaydi.
Primitive obsessionni kamaytiradi.
Aggregate
Birgalikda consistency boundary hosil qiladigan entity va value objectlar guruhi.
Tashqi kod aggregate root orqali murojaat qiladi.
Bitta transaction ichida aggregate invariantlari saqlanadi.
Aggregate juda katta bo‘lsa lock va performance muammosi paydo bo‘ladi.
Aggregate Root
Aggregate’ning tashqi kirish nuqtasi.
Masalan, Order root bo‘lib, OrderItem ichki entity bo‘lishi mumkin.
Tashqi service itemni bevosita o‘zgartirmaydi:
order.add_item(product, quantity)
Shunda invariant markazda saqlanadi.
Invariant
Aggregate har doim saqlashi kerak bo‘lgan biznes shart.
Masalan:
- quantity musbat;
- paid orderga item qo‘shilmaydi;
- balance limitdan oshmaydi;
- period start enddan oldin.
Invariant domain method ichida enforced qilinadi.
Domain Service
Bir nechta entityga tegishli, ammo tabiiy ravishda bittasiga joylashmaydigan domain operation.
Domain service business tilida nomlanadi.
U application orchestration yoki infrastructure service bilan aralashtirilmaydi.
Stateless bo‘lishi keng tarqalgan.
Application Service
Use-case oqimini boshqaradi:
Biznes qoidalarini o‘ziga yig‘ib olmasligi kerak.
U transaction va permission orchestration qilishi mumkin.
Repository
Aggregate collectioniga o‘xshash interface.
Masalan:
orders.get(id)
orders.save(order)
Domain layer database SQL yoki ORM detallarini bilmaydi.
Repository har table uchun emas, aggregate boundary bo‘yicha yaratiladi.
Domain Event
Domain ichida sodir bo‘lgan muhim fakt:
- OrderPlaced;
- PaymentReceived;
- UserVerified;
- SubscriptionExpired.
Event o‘tgan zamonda nomlanadi.
Boshqa component reaction qiladi.
Event delivery va transaction consistency alohida hal qilinadi.
Anti-Corruption Layer
Tashqi yoki legacy modelni ichki domain modelga bevosita kiritmaslik uchun adapter va translator qatlam yaratiladi.
Masalan, external ERP status kodlari domain enumga map qilinadi.
Bu ichki modelni boshqa tizim terminlaridan himoya qiladi.
Strategic va tactical DDD
Strategic DDD:
- subdomain;
- bounded context;
- context map;
- team boundary.
Tactical DDD:
- entity;
- value object;
- aggregate;
- repository;
- domain service;
- event.
Tactical patternlarni bounded context tushunchasisiz mexanik ishlatish yetarli emas.
DDD va microservice
Bounded context microservice chegarasi uchun yaxshi nomzod bo‘lishi mumkin.
Ammo har context albatta alohida deploy qilinishi shart emas.
Modular monolith ichida ham DDD qo‘llanadi.
Noto‘g‘ri bo‘lingan microservice distributed monolith yaratadi.
DDD va database
Domain model table structure’ning aynan nusxasi emas.
ORM mapping entity va persistence model orasida ishlaydi.
Har relationni lazy-load qilish domain behaviorini noaniq qiladi.
Aggregate kerakli data bilan birga yuklanadi.
Factory
Murakkab entity yoki aggregate’ni valid holatda yaratish uchun factory ishlatiladi. Constructor ichida ko‘p technical parameter bo‘lsa factory domain tilidagi method beradi:
Order.place(customer, items)
Factory invariantni yaratish paytidayoq saqlaydi.
Specification
Qayta ishlatiladigan business predicate specification object sifatida ifodalanishi mumkin. Masalan, EligibleForDiscount. U filtering, validation yoki policy’da ishlatiladi. Har oddiy if uchun specification yaratish ortiqcha abstraction.
CQRS bilan aloqa
Ba’zi DDD tizimlarda write domain model va read model ajratiladi. Bu CQRSga yaqin. DDD CQRSni majburiy qilmaydi; oddiy CRUD contextda bitta model yetarli bo‘lishi mumkin.
Bog‘liq tushunchalar
Domain-Driven Design, Domain, Ubiquitous language, Bounded Context, Entity, Value Object, Aggregate, Repository, Domain Event, Anti-Corruption Layer, Subdomain