Proiectare bazată pe domeniu

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare

Proiectarea bazată pe domeniu ( DDD ) este o abordare de dezvoltare software care rezolvă probleme complexe conectând implementarea la un model în evoluție. [1] Premisele domeniului sunt următoarele:

  • Puneți accentul principal al proiectului pe domeniile entităților și logica acestora.
  • Bazează proiectarea pe entități de domeniu.
  • Inițiați o colaborare creativă între tehnicieni și experți din domeniu pentru a defini iterativ un model conceptual care poate fi aplicat problemelor particulare ale cazului.

Termenul a fost introdus de Eric Evans în cartea cu același titlu. [2]

Definiții fundamentale

Domeniu
Un context de cunoaștere ( ontologie ), influență sau activitate. Zona în care utilizatorul lucrează cu software-ul este domeniul software-ului.
Șablon
Un sistem de abstractizare care descrie aspecte specifice ale domeniului și care poate fi utilizat pentru rezolvarea problemelor legate de definirea domeniului.
Limbaj omniprezent
Un set de termeni construiți în jurul modelului de domeniu utilizat de echipă pentru a aborda și contextualiza problemele care trebuie rezolvate în timpul implementării.
Context
Mediul în care un anumit termen capătă un anumit sens.

Strategii de proiectare bazate pe domenii

Modelele și relațiile dintre ele, în proiectarea software-ului bazat pe domeniu

În mod ideal, este de preferat să aveți un singur model unificat. Deși acesta este un scop nobil, în realitate trebuie să ne luptăm cu mai multe modele care coexistă. este util să integrezi această presupunere și să lucrezi cu ea.

Strategiile în proiectare sunt o serie de principii care vizează menținerea integrității modelului și care conduc la dezvoltarea modelului de dominație și interacțiune între diferitele modele.

Contextul ca delimitat și definit

În proiectele mari, multe modele trebuie să interacționeze între ele. Adesea, atunci când codul care funcționează pe diferite modele trebuie integrat, munca devine dificilă, provocând apariția unor erori și îngreunând înțelegerea și întreținerea proiectului. Comunicarea dintre membrii echipei devine confuză; devine deci neclar în ce context este aplicat un model.

Cea mai bună soluție este de a defini în mod explicit contextul la care se aplică un model; în plus, este util să clarificați limitele la nivelul organizației echipei, să clarificați în ce puncte ale aplicației este utilizat un model și mai ales să vărsați aceste ipoteze în implementare. Mai presus de toate, este esențial să păstrăm modelul coerent în limitele stabilite, nefiind influențat și confuz de ecosistemul din jurul său.

Integrare continuă

Când mai mulți oameni lucrează în același context definit, există o puternică tendință de a fragmenta modelul. Cu cât echipa este mai mare, cu atât problema este mai mare, chiar și o echipă de trei sau patru persoane poate întâmpina probleme. Mai mult, fragmentarea excesivă a contextului duce la probleme de integrare și coerență a informațiilor.

Cea mai bună soluție este de a stabili un proces frecvent de combinare a codului cu un pas de testare. În acest fel, se exercită o partajare constantă a concepției modelului, care poate evolua liber cu contribuțiile fiecărui dezvoltator.

Harta contextuală

Un singur context delimitat duce la o serie de probleme în absența unei viziuni globale. Contextul altor modele poate fi încă vag și incomplet.

Este posibil ca dezvoltatorii din alte echipe să nu fie conștienți de domeniul în care funcționează contextul, astfel încât schimbarea unui context devine complicată în fața unor limite nedefinite. Când interconectările dintre contexte sunt necesare, se întâmplă uneori să se întemeieze limitele.

Soluția este definirea fiecărui model care există în proiect și definirea limitelor acestuia. Aceasta include modele implicite de subproiecte non-orientate spre obiecte. Găsiți numele fiecărui context delimitat și faceți-l parte din limbajul specific domeniului. Descrieți punctele de contact dintre modele, explicând traducerile necesare în comunicare și evidențiind schimbul de informații.

Construirea bazelor DDD

În cartea Domain-Driven Design [3] , sunt introduse o serie de concepte și practici cheie, cum ar fi semnificația limbaj omniprezent, adică un limbaj unificat creat de experți în domeniu, care este folosit pentru a descrie cerințele sistemului, care se adaptează și la utilizarea de diverși actori precum utilizatori, producători și dezvoltatori. Cartea este puternic orientată pentru a descrie stratul de domeniu într-un sistem orientat obiect cu o arhitectură multistrat. În DDD, există artefacte pentru a exprima, crea și prelua modele de domeniu:

Entitate
Un obiect care nu este definit de atributele sale, ci mai degrabă de identitatea sa. De exemplu, majoritatea companiilor aeriene disting în mod unic fiecare loc pe fiecare zbor. Fiecare loc este o entitate în acest context. Cu toate acestea, Southwest Airlines, EasyJet și Ryanair nu fac distincție între toate locurile: toate locurile nu se disting între ele. În acest context, scaunul este de fapt un obiect valoric.
Obiect de valoare
Un obiect care are mai multe atribute, dar nu are identitate conceptuală. Obiectele de valoare trebuie tratate ca obiecte imuabile. De exemplu, atunci când oamenii schimbă facturi în dolari, sunt interesați doar de valoarea nominală a bancnotei, nu de identitatea individuală a facturilor schimbate. În acest context, bancnotele în dolari sunt reprezentate de obiecte valorice. Cu toate acestea, Rezerva Federală ar putea fi interesată de bancnota unică identificată prin numărul său de serie: în acest context, fiecare bancnotă este mai corect reprezentată de o entitate.
Agregat
O colecție de obiecte care sunt legate între ele de o entitate mamă, cunoscută altfel ca o rădăcină agregată. Rădăcina de agregare garantează consistența modificărilor făcute în cadrul agregatului prin interzicerea obiectelor externe de a păstra referințe la membrii săi interni. De exemplu, atunci când conduceți o mașină, nu trebuie să vă faceți griji cu privire la deplasarea roților înainte, la menținerea motorului aprins prin aprindere și combustibil etc.; pur și simplu conduceți mașina. În acest context, mașina este un agregat de alte câteva obiecte și servește ca o rădăcină agregată pentru toate celelalte sisteme.
Eveniment de domeniu
Un obiect de domeniu care definește un eveniment (ceva care se întâmplă). Un eveniment de domeniu este un eveniment de maximă importanță pentru experții din domeniu.
Serviciu
Când o operațiune nu aparține în mod logic niciunui obiect. Apoi, este posibilă implementarea acestor operațiuni în sectorul serviciilor.
Repertoriu
Metode pentru recuperarea obiectelor de domeniu delegate dintr-un obiect de depozit specializat, astfel încât implementarea stocării alternative este ușoară.
Fabrică
Metode de creare a obiectelor de domeniu care delegă crearea lor unui obiect pentru a facilita implementări alternative.

Dezavantaje

Pentru a păstra modelul ca o construcție pură și utilă a limbajului, echipa trebuie să implementeze de obicei izolarea cu mare grijă și să acorde atenție încapsulării în cadrul modelului de domeniu. În consecință, un sistem construit prin Domain Driven Design poate fi costisitor din punct de vedere al dezvoltării.

Prin urmare, un sistem bazat pe Domain Driven Design are un cost relativ ridicat. Proiectarea bazată pe domeniu oferă cu siguranță numeroase avantaje tehnice, cum ar fi mentenabilitatea, Microsoft recomandă totuși să o aplice numai domeniilor complexe în care modelul și procesele lingvistice oferă avantaje evidente în comunicarea informațiilor complexe și în formularea unei viziuni comune a domeniului.

Notă

  1. ^ Proiectare bazată pe domeniu . .
  2. ^ Eric Evans , Proiectare bazată pe domeniu: abordarea complexității în inima software-ului , Addison-Wesley, 2004, ISBN 978-0-321-12521-7 . Accesat la 12 august 2012 . .
  3. ^ Eric Evans, Proiectare bazată pe domeniu: abordarea complexității în inima software-ului , Addison-Wesley, 2004, ISBN 978-0-321-12521-7 . Accesat la 12 august 2012 . .

Elemente conexe

linkuri externe

Adus de la " https://it.wikipedia.org/w/index.php?title=Domain-driven_design&oldid=121074552 "