Ce am înțeles despre domain-driven design

DDD 101

Cu cât este mai mare proiectul, cu atât este mai greu să îl întreții. O modalitate de a ajuta în acest sens este împărțirea aplicației în domenii mai mici, în funcție de regulile lor de afaceri, cunoscute sub numele de domenii.

În principiu, un domeniu este o zonă de cunoștințe, fie publică, cum ar fi regulile șahului, fie privată, cum ar fi regulile de afaceri ale unei organizații nonprofit .

Un domeniu complex este posibil să folosească cunoștințe din alte domenii. De exemplu, o organizație nonprofit care predă șah online va avea cunoștințe despre șah, despre predarea prin intermediul platformelor online și, chiar dacă nu sunteți taxat ca elev, despre finanțele sale.

Care subdomeniu al domeniului este cunoscut în DDD ca fiind contexte delimitate, fiecare are propriul său model al lumii construit cu unități specializate de cod, cunoscute sub numele de blocuri de construcție. Aici mă voi concentra asupra entităților și a obiectelor-valoare, ambele pot fi referite ca obiecte.

Entitățile sunt obiecte menite să fie unice în cadrul domeniului. Acest lucru se realizează prin utilizarea uneia sau mai multor proprietăți pentru a identifica o anumită entitate. De exemplu, doi utilizatori care folosesc același nume într-un sistem vor avea întotdeauna e-mailuri diferite, deoarece e-mailurile nu pot fi repetate – de cele mai multe ori, entitățile se diferențiază printr-un id și, uneori, printr-o combinație de proprietăți.

Obiectele-valoare, pe de altă parte, nu au o identitate, astfel încât doar proprietățile lor pot fi folosite pentru a face distincția între două instanțe. Să luăm de exemplu doi pioni (jetoane de șah), ei arată la fel dacă provin din același set de joc și au aceeași culoare, deci nu contează dacă îi schimbați. În DDD, obiectele-valoare sunt imuabile, astfel încât este mai ușor să raționăm cu ele.

Integritatea datelor

Un context delimitat nu-și expune toate obiectele pentru a garanta integritatea datelor sale. În schimb, el expune unele rădăcini agregate ca un fel de interfață publică pentru el însuși.

Un agregat nu este nimic mai mult decât o entitate care este compusă din alte obiecte. Pentru a fi mai precis, un agregat este un grup de obiecte asociate pe care le tratăm ca pe o unitate atunci când modificăm datele.

În termeni practici, agregatele vor lua forma structurii de date cunoscută sub numele de arbore. Și din acest motiv, toate agregatele au o rădăcină.

Unicul membru al unui agregat la care se pot referi alte obiecte este rădăcina sa și, prin urmare, aceasta este cea pe care o expunem. Acest lucru este făcut astfel pentru că împiedică alte obiecte să modifice datele într-un mod pe care agregatul nu îl poate controla.

Important de precizat că un context delimitat poate folosi mai multe agregate chiar și atunci când rădăcina lor nu este expusă direct lumii exterioare.

Afacerea cu mai multe contexte delimitate

Dar lucrurile pot deveni mai complicate, nu-i așa? Fiecare context delimitat primește un model ușor diferit al acelorași obiecte, având proprietăți și comportamente diferite. Astfel, un utilizator într-un context de joc poate avea o proprietate pentru a gestiona scorul său, care într-un context financiar este irelevantă și, prin urmare, nu există.

Și asta nu este tot. De asemenea, este posibil ca un concept de domeniu, reprezentat ca o entitate într-un context delimitat, să fie reprezentat ca un obiect-valoare în altul, sau pur și simplu să fie complet omis.

De exemplu, în timp ce contextul de predare cere ca profesorii să fie reprezentați ca entități, astfel încât să poată fi atribuiți studenților prin ID-urile lor, contextul financiar preferă să vadă „profesor” ca o valoare pentru proprietatea de poziție a entității angajat.

Câteva dintre celelalte elemente constitutive ale DDD sunt serviciile, depozitele, fabricile și evenimentele. Voi încerca să le descriu pe scurt.

Serviciile sunt capabilități ale unui domeniu care nu se potrivesc în mod natural entităților și nici valorilor obiectelor. Atenție, sunt servicii de domeniu, nu servicii de aplicație sau de infrastructură.

Repozitoriile sunt punți către unitățile de stocare – bună ziua CRUD!.

Fabriciile sunt metode de creare a obiectelor de domeniu astfel încât acestea să nu aibă niciodată valori invalide. Această parte este cea care m-a făcut să încep să mă gândesc la testele axate pe produs.

Evenimentele sunt obiecte care reprezintă ceva ce s-a întâmplat în domeniu – experții săi se preocupă de ele. Oportunități excelente pentru a crea o aplicație bazată pe evenimente.

Deși nu-mi amintesc ca Evans să fi afirmat acest lucru, contextele delimitate sunt o oportunitate frumoasă de a vă împărți codul în microservicii, unde fiecare serviciu este un context de sine stătător. Primul pas ar putea fi o despărțire „virtuală” în care fiecare context este pus într-un modul diferit pe aceeași aplicație, iar apoi, dacă detectați că sunt cu adevărat izolate, mutați-le în module diferite.

Un limbaj care să le domine pe toate

Unul dintre primele lucruri pe care oamenii le învață atunci când studiază DDD este că sistemul lor ar trebui să fie descris de un limbaj omniprezent. Adică, ar trebui să scriem codul folosind aceleași verbe (pentru metode sau servicii) și substantive (pentru obiecte) pe care experții din domeniu le folosesc atunci când vorbesc cu noi.

Scrierea codului în acest fel are avantajul de a reduce decalajul de comunicare dintre dezvoltatori și experți atunci când vorbesc, dar este o simplificare exagerată a vieții reale, așa că eu personal o folosesc ca o linie directoare, dar nu ca o soluție finală.

Am păstrat-o pentru final pentru că, pentru mine, cel mai important lucru despre DDD nu se citește de obicei, deoarece se află în partea „complexă” a cărții.

Recent am aflat că însuși autorul a spus că ordinea în care prezintă lucrurile în carte nu este optimă, iar ceea ce am descris aici este mai aproape de ceea ce ar fi fost ideal 😍. Am auzit asta la un podcast care făcea referire la acesta

.