Biznes loqikasının mürəkkəb olduğu və funksionallıqların tez-tez dəyişdiyi layihələrdə tətbiq edilir.
Sadə domenə malik, yalnız CRUD əməliyyatlarından ibarət və ya 20-30 use case-i olan kiçik tətbiqlərdə DDD istifadə etmək adətən lazım deyil.
Əsas aspektlər
- Mərkəzləşdirilmiş biznes loqikası: DDD-nin əsas ideyası birbaşa biznes domeninə fokuslanmaqdır. Proqram təminatının əsas məqsədi biznes problemlərini həll etmək olmalıdır.
- Öyrənmək, müzakirə etmək və biznes dəyəri qazandırmaq: Proqramçılar və biznes ekspertləri arasındakı davamlı ünsiyyət loqikanın düzgün başa düşülməsinə kömək edir. Sistem müzakirə olunarkən hər kəs eyni dildən - Ümumi Dildən (Ubiquitous Language) istifadə edir.
- Dizayn koddur, kod isə dizayndır: Biznes strukturu koda əks olunmalı və kod biznes dizaynını tam təmsil etməlidir.
- Məsuliyyətlərin ayrılması: DDD domen loqikasını Tətbiq, İnfrastruktur və UI loqikasından ayırmağı təşviq edir. Çox vaxt Təmiz Memarlıq və ya Soğan Memarlığı ilə birlikdə tətbiq olunur.
- Strateji və taktiki dizayn: DDD həm yüksək səviyyəli strateji dizaynı, həm də kod səviyyəsindəki taktiki dizaynı bir araya gətirir.
1. Strateji Dizayn
DDD-də Strateji Dizayn domeni idarə oluna bilən kiçik hissələrə bölməyə kömək edən yüksək səviyyəli dizayna fokuslanır.
Subdomain (Alt Domen)
Biznes konsepsiyasıdır və Problem məkanında istifadə olunur. Onlayn kitab satışı platformasında Kataloq, Sifarişlər, Faturalandırma və İstifadəçi İdarəetməsi alt domenlərə nümunədir.
Subdomenin 3 növü
- Core Subdomain: Biznesin ən vacib və onu unikal edən hissəsidir.
- Supporting Subdomain: Unikal deyil, lakin əsas biznesi tamamlayır.
- Generic Subdomain: Standart loqikadır; autentifikasiya, loqlama, ödəniş şlüzləri kimi.
Ubiquitous Language (Ümumi Dil)
Proqramçı komandası və biznes nümayəndələri arasında ortaq terminologiyadır. "Book", "Order", "Customer" kimi terminlər razılaşdırılır və yalnız aid olduğu Bounded Context daxilində keçərlidir.
Bounded Context (Məhdud Kontext)
Domen modellərini müstəqil təyin edib tətbiq edə biləcəyimiz Həll məkanıdır. Eyni termin fərqli kontekstlərdə fərqli mənalar daşıya bilər - Billing-dəki "Account" ilə UserManagement-dakı "Account" fərqlidir.
Context Map (Kontext Xəritəsi)
Fərqli Bounded Context-lərin bir-biri ilə necə inteqrasiya olunduğunu göstərən yüksək səviyyəli xəritədir.
Shared Kernel (Ortaq Nüvə)
İki və ya daha çox Bounded Context arasında paylaşılan ümumi domen modelləri toplusudur. Dəyişikliklər koordinasiya tələb edir.
2. Taktiki Dizayn
DDD-də Taktiki Dizayn kod səviyyəsindəki strukturlara fokuslanır. Bu patternlər adətən bir Bounded Context daxilində tətbiq olunur.
Entity
Unikal identifikator (ID) ilə təyin olunan və zaman keçdikcə vəziyyəti dəyişsə belə şəxsiyyətini qoruyan obyektlərdir. Məsələn: Order, Customer.
Value Object
Kimliyi yox, dəyəri ilə tanınan dəyişməz obyektlərdir. Məsələn: Address, Money, Email.
Aggregate & Root
Bir-biri ilə əlaqəli entity və value object-lərin məntiqi qrupudur. Xarici dünya yalnız Aggregate Root vasitəsilə daxil olur; bu, biznes qaydalarının pozulmamasını təmin edir.
Repository
Aggregate-lərin saxlanması və əldə edilməsi üçün abstraksiya təbəqəsidir. Domen kodu verilənlər bazası detallarından asılı olmamalıdır.
Domain Service
Tək bir entity və ya value object-ə aid olmayan, lakin domenə məxsus biznes əməliyyatlarını həyata keçirən servisdir.
Application Service
Use case-ləri koordinasiya edir, transaction idarə edir və domen obyektlərini orchestrate edir; biznes qaydalarını özündə saxlamır.
Domain Event
Domen daxilində baş vermiş və digər hissələrin reaksiya verməsi lazım olan hadisədir. Məsələn: OrderPlaced, PaymentCompleted.
Factory
Mürəkkəb aggregate və entity-lərin yaradılması məntiqini mərkəzləşdirir və biznes invariantlarının pozulmamasını təmin edir.
Solution Space vs Problem Space
Problem space (Problem məkanı): Biznesin real ehtiyaclarını, hədəflərini və çətinliklərini müəyyən edir. Burada Subdomain, biznes prosesləri və domen ekspertləri ilə aparılan müzakirələr dayanır. Bu mərhələdə "nə" həll edilməli sualına cavab axtarılır.
Solution space (Həll məkanı): Arxitekturanı, texnologiyanı və problemin kod tərəfində necə həll olunacağını müəyyənləşdirir. Bounded Context, mikroservislər, layihə qovluq strukturu və infrastruktur qərarları bu məkana aiddir. Burada "necə" həll edilməli sualına cavab verilir.
Uğurlu DDD tətbiqi bu iki məkan arasında davamlı rabitə tələb edir: biznes dili (Problem space) kod strukturuna (Solution space) dəqiq əks olunmalıdır.
