Design -ul bazat pe domeniu (mai rar proiectare pe domeniu , DDD) este un set de principii și scheme care vizează crearea unor sisteme optime de obiecte. Se rezumă la crearea abstracțiilor software numite modele de domenii . Aceste modele includ logica de afaceri care stabilește o legătură între condițiile reale ale zonei de aplicare a produsului și cod.
Domain-Driven Design nu este o tehnologie sau o metodologie specifică. DDD este un set de reguli care vă permit să luați deciziile corecte de proiectare. Această abordare vă permite să accelerați semnificativ procesul de proiectare a software-ului într-un domeniu necunoscut.
Abordarea DDD este utilă în special în situațiile în care dezvoltatorul nu este un expert în domeniul produsului dezvoltat. De exemplu: un programator nu poate cunoaște toate domeniile în care software-ul trebuie creat , dar cu o reprezentare corectă a structurii, printr-o abordare orientată pe domeniu, poate proiecta cu ușurință o aplicație pe baza punctelor cheie și a cunoștințelor zonei de lucru .
Acest termen a fost introdus pentru prima dată de E. Evans în cartea sa cu același nume „Domain-Driven Design” [1] .
În mod ideal, atunci când proiectați, doriți să aveți un singur model care să descrie pe deplin întreaga arie de subiect, dar în realitate, pentru a simplifica procesul de dezvoltare a produsului, domeniul este prezentat ca o combinație a mai multor modele interdependente.
O diagramă de arhitectură a aplicației este o descriere a unuia sau mai multor modele de domeniu și a relațiilor dintre ele.
Utilizarea mai multor modele la diferite niveluri ale proiectului . Această abordare este folosită pentru a reduce diferitele relații dintre modele, ceea ce elimină complexitatea și complexitatea codului . Uneori nu este clar în ce context ar trebui utilizat modelul.
Soluție: Definiți exact contextul în care este utilizat modelul. Determinați limitele utilizării acestui model și caracteristicile acestuia.
Atunci când un număr mare de oameni lucrează la un proiect, există tendința de a împărți modelul în câteva fragmente mai mici. Cu cât sunt mai mulți oameni, cu atât este mai semnificativă această problemă. În cele din urmă, integritatea proiectului este pierdută.
Soluție: combinarea constantă a bucăților de cod de la diferiți dezvoltatori și verificarea funcționalității prin testare . Acest lucru permite tuturor dezvoltatorilor să rămână într-un singur concept mare.
Atunci când lucrează la mai multe modele separate într-un grup mare, diferiți membri ai echipei pot să nu cunoască entitățile altor modele, ceea ce complică procesul general de asamblare a produsului final.
Soluție: în timpul fazei de proiectare, definiți exact ce face fiecare model și cum se raportează la alte modele. În cele din urmă, ar trebui să ajungeți cu o hartă a relațiilor model.
Atunci când proiectați pe baza unei abordări orientate pe domeniu, sunt utilizate următoarele concepte:
Majoritatea sistemelor pentru întreprinderi folosesc domenii de responsabilitate pe scară largă. În DDD, acest cel mai înalt nivel de organizare se numește context mărginit. De exemplu, sistemul de facturare al unei mari companii de telecomunicații poate avea următoarele elemente cheie:
Toate elementele de mai sus trebuie incluse într-un singur sistem neîntrerupt. La proiectare, sistemul de notificare și sistemul de securitate ies în evidență ca lucruri complet diferite. Sistemele în care implementarea nu reușește să separe și să izoleze contextele delimitate dobândesc adesea un stil arhitectural care este numit în mod adecvat „ Big Mudball ” în 1999 de Brian Foot și Joseph Yoder. [2]
Esența designului specific domeniului este definirea specifică a contextelor și restrângerea modelării în cadrul acestora.
Cel mai simplu mod de a exprima entitățile este sub formă de substantive : oameni, locuri, produse etc. Entitățile au atât o personalitate, cât și un ciclu de viață. În timpul proiectării, ar trebui să vă gândiți la entități ca unități de comportament, mai degrabă decât unități de date. Cel mai adesea, o operațiune pe care încercați să o adăugați la model trebuie să fie primită de o entitate, sau o nouă entitate începe să fie creată sau preluată. În codul mai slab cuplat , puteți găsi o mulțime de clase de utilitate sau de control care verifică entitățile din exterior.
Un obiect de valoare este o proprietate care este importantă în domeniul pe care îl modelați. Ele, spre deosebire de entități, nu au denumire; ele descriu pur și simplu entități concrete care au deja desemnări. Utilitatea obiectelor de valoare este că ele descriu proprietățile entităților într-un mod mult mai elegant și mai intenționat. Merită întotdeauna să ne amintim că valoarea unui obiect nu se schimbă niciodată pe parcursul execuției întregului cod de program . Odată creat, nu se pot face modificări.
Un agregat este o entitate specială care este accesată direct de consumatori. Utilizarea agregatelor vă permite să evitați conectarea excesivă a obiectelor care compun modelul. Acest lucru evită confuzia și simplifică structura, deoarece nu permite crearea de sisteme strâns cuplate.
Uneori există operațiuni sau procese într-un domeniu care nu au nicio desemnare sau ciclu de viață. Serviciile de domeniu oferă un instrument pentru modelarea acestor concepte. Sunt apatride și foarte cuplate, oferind adesea o singură metodă publică și uneori o suprasolicitare pentru operațiunile stabilite. Dacă într-un comportament sunt incluse mai multe dependențe și nu există nicio modalitate de a găsi un loc potrivit în entitate pentru a găzdui acel comportament, atunci este utilizat un serviciu. Deși termenul „serviciu” în sine este supraîncărcat cu diverse semnificații în lumea dezvoltării, dar în acest subiect, înseamnă o clasă mică care nu reprezintă o anumită persoană, loc sau lucru în aplicația proiectată, ci include un fel de procese . Utilizarea serviciilor vă permite să introduceți o arhitectură cu mai multe straturi , precum și să integrați mai multe modele, ceea ce introduce dependență de infrastructură. [3]
Deși în concept, proiectarea orientată pe domeniu nu ar trebui să se limiteze la nicio reprezentări, dar în practică sunt folosite punctele forte ale programării orientate pe obiecte . Aceasta este utilizarea moștenirii , încapsulării , reprezentării ca metode și clase. Trebuie amintit că abordarea specifică domeniului poate fi aplicată nu numai limbajelor OOP, cum ar fi Java , C# sau C++ , ci și limbajelor funcționale precum F# , Erlang . Deosebit de utile sunt limbile care acceptă crearea și utilizarea propriilor limbi specifice domeniului , cum ar fi Scala (vezi și LOP ).
| Dezvoltare de software | |
|---|---|
| Proces | |
Concepte de nivel înalt | |
| Directii |
|
| Metodologii de dezvoltare | |
| Modele |
|
Cifre notabile |
|