Domain-Driven Design (DDD) este o abordare a dezvoltării software care se concentrează pe înțelegerea și modelarea domeniului problemei în care funcționează un sistem software. Subliniază importanța colaborării strânse cu experții din domeniu pentru a dezvolta o înțelegere profundă a complexităților și complexităților domeniului. DDD oferă un set de principii, modele și practici pentru a ajuta dezvoltatorii să captureze și să exprime în mod eficient conceptele de domeniu în design-urile software.

panda și numpy

Subiecte importante pentru designul bazat pe domeniu (DDD)

• Ce este Domain-Driven Design (DDD)?
• Importanța cunoașterii domeniului
• Proiectare strategică în domeniul design-driven (DDD)
• Modele de proiectare tactică în proiectare bazată pe domenii (DDD)
• Beneficiile designului bazat pe domeniu (DDD)
• Provocările designului bazat pe domenii (DDD)
• Cazuri de utilizare ale designului bazat pe domenii (DDD)
• Exemplu real de proiectare bazată pe domenii (DDD)

Ce este Domain-Driven Design (DDD)?

Domeniu

Se referă la domeniul de subiect sau la spațiul cu probleme pentru care este construit sistemul software. Acesta cuprinde conceptele, regulile și procesele din lumea reală pe care software-ul este destinat să le modeleze sau să le suporte. De exemplu, într-o aplicație bancară, domeniul include concepte precum conturi, tranzacții, clienți și reglementări legate de operațiunile bancare.

Condus

Driven implică faptul că proiectarea sistemului software este ghidată sau influențată de caracteristicile și cerințele domeniului. Cu alte cuvinte, deciziile de proiectare se bazează pe o înțelegere profundă a domeniului, mai degrabă decât să fie conduse doar de considerente tehnice sau detalii de implementare.

Proiecta

Designul se referă la procesul de creare a unui plan sau plan pentru sistemul software. Aceasta include decizii cu privire la modul în care va fi structurat sistemul, modul în care diferitele componente vor interacționa și modul în care sistemul își va îndeplini funcţional și nefuncțional cerințe. În contextul Domain-Driven Design, accentul se pune pe proiectarea software-ului într-un mod care să reflecte cu acuratețe structura și comportamentul domeniului.

Domain-Driven Design este un concept introdus de un programator Eric Evans în 2004 în cartea sa Design bazat pe domeniu: abordarea complexității în inima software-ului

Importanța cunoașterii domeniului

Să presupunem că am proiectat software folosind toate cele mai noi tehnologii și infrastructură, iar arhitectura noastră de proiectare software este uimitoare, dar atunci când lansăm acest software pe piață, utilizatorul final este cel care decide dacă sistemul nostru este excelent sau nu. De asemenea, dacă sistemul nu rezolvă nevoile afacerii, atunci nu este de folos nimănui. Indiferent cât de frumos arată sau cât de bine ar fi arhitectura infrastructura sa.

Conform Eric Evans , Când dezvoltăm software, accentul nostru nu ar trebui să se concentreze în primul rând pe tehnologie, ci ar trebui să se concentreze în primul rând pe afaceri. Tine minte,

Nu este treaba clientului să știe ce își dorește – Steve Jobs

Proiectare strategică în domeniul design-driven (DDD)

Designul strategic în proiectarea bazată pe domenii (DDD) se concentrează pe definirea arhitecturii și structurii generale a unui sistem software într-un mod care se aliniază cu domeniul problemei. Se adresează preocupărilor la nivel înalt, cum ar fi modul de organizare a conceptelor de domeniu, modul de împărțire a sistemului în părți gestionabile și modul de stabilire a granițelor clare între diferitele componente.

Să vedem câteva concepte cheie din Designul strategic în Designul bazat pe domenii (DDD)

munca la calculator

1. Contexte delimitate

• Un context delimitat reprezintă o zonă specifică din domeniul general al problemei în care un anumit model sau limbaj se aplică în mod consecvent.
• Părți diferite ale unui sistem pot avea semnificații diferite pentru aceiași termeni, iar un context delimitat definește granițele explicite în care acești termeni au semnificații specifice.
• Acest lucru permite echipelor să dezvolte modele care sunt adaptate unor contexte specifice fără a introduce confuzii sau inconsecvențe.
• Contextele delimitate ajută la gestionarea complexității prin defalcarea unui domeniu mare și complex în părți mai mici și mai ușor de gestionat.

2. Maparea contextului

• Maparea contextului este procesul de definire a relațiilor și interacțiunilor dintre diferite Contexte delimitate.
• Ea presupune identificarea zonelor de suprapunere sau integrare între contexte și stabilirea unor canale de comunicare și acorduri între acestea.
• Maparea contextului ajută la asigurarea faptului că diferite părți ale sistemului pot colabora eficient, menținând totuși granițele clare între ele.
• Există diverse modele și tehnici pentru maparea contextului, cum ar fi Parteneriatul, Kernelul partajat și Clientul-Furnizor.

3. Modele strategice

• Modelele strategice sunt linii directoare sau principii generale pentru organizarea arhitecturii unui sistem software într-un mod care să se alinieze domeniului problemei.
• Aceste modele ajută la abordarea provocărilor comune în proiectarea sistemelor complexe și oferă abordări dovedite pentru structurarea eficientă a sistemului.
• Exemple de modele strategice includ agregate, evenimente de domeniu și stratul anti-corupție.
• Aceste modele oferă soluții la problemele recurente în proiectarea bazată pe domenii și ajută la asigurarea faptului că arhitectura sistemului reflectă cu acuratețe conceptele de domeniu subiacente.

4. Kernel partajat

• Kernelul partajat este un model strategic care implică identificarea zonelor comune între diferite contexte limitate și stabilirea unui subset comun al modelului de domeniu care este utilizat de mai multe contexte.
• Acest subset partajat, sau nucleu, ajută la facilitarea colaborării și integrării între contexte, permițând în același timp fiecărui context să-și mențină propriul model distinct.
• Kernel-ul partajat ar trebui utilizat în mod judicios, deoarece introduce dependențe între contexte și poate duce la cuplare dacă nu este gestionat cu atenție.

5. Stratul anti-corupție (ACL)

• Stratul anticorupție este un alt model strategic care ajută la protejarea unui sistem de influența sistemelor externe sau vechi care utilizează modele sau limbaje diferite.
• Un ACL acționează ca un strat de traducere între sistemul extern și modelul de domeniu de bază, transformând datele și mesajele după cum este necesar pentru a asigura compatibilitatea.
• Acest lucru permite modelului domeniului de bază să rămână pur și concentrat pe domeniul problemei, integrându-se în același timp cu sistemele externe după cum este necesar.

6. Limbajul omniprezent

Limbajul omniprezent se referă la un vocabular sau un limbaj comun care este utilizat în mod consecvent și universal de către toți părțile interesate implicate în dezvoltarea unui sistem software. Acest limbaj constă din termeni, expresii și concepte care reprezintă cu exactitate cunoștințele și conceptele domeniului.

Unele dintre principiile cheie ale limbajului omniprezent sunt:

• Înțelegere împărtășită : Scopul principal al Ubiquitous Language este de a stabili o înțelegere comună a domeniului problemei între toți membrii echipei de dezvoltare, inclusiv dezvoltatori, experți în domeniu, analiști de afaceri și părți interesate. Folosind un limbaj comun, toți cei implicați pot comunica mai eficient și pot transmite mai precis conceptele și cerințele domeniului.
• Consecvență și claritate : Ubiquitous Language promovează coerența și claritatea în comunicare prin utilizarea terminologiei precise și lipsite de ambiguitate. Fiecare termen sau expresie din limbă ar trebui să aibă un sens clar și convenit,
• Alinierea la conceptele de afaceri : Limbajul folosit în DDD ar trebui să se alinieze îndeaproape cu terminologia și conceptele utilizate în domeniul afacerilor. Ar trebui să reflecte modul în care experții din domeniu gândesc și vorbesc despre domeniul problemei, asigurându-se că software-ul reprezintă cu acuratețe concepte și procese din lumea reală.
• Natura evolutivă : Limbajul omniprezent nu este static, ci evoluează în timp pe măsură ce echipa obține o înțelegere mai profundă a domeniului și pe măsură ce cerințele se schimbă. Ar trebui să se adapteze pentru a reflecta noi perspective, descoperiri sau schimbări în prioritățile de afaceri, asigurându-se că limbajul rămâne relevant și actualizat pe tot parcursul procesului de dezvoltare.

Modele de proiectare tactică în proiectare bazată pe domenii (DDD)

În Domain-Driven Design (DDD), modelele de proiectare tactică sunt strategii sau tehnici specifice utilizate pentru a structura și organiza modelul de domeniu în cadrul unui sistem software. Aceste modele îi ajută pe dezvoltatori să captureze în mod eficient complexitatea domeniului, promovând totodată mentenabilitatea, flexibilitatea și scalabilitatea.

Să vedem câteva dintre modelele cheie de design tactic în DDD:

1. Entitate

O entitate este un obiect de domeniu care are o identitate și un ciclu de viață distinct. Entitățile sunt caracterizate prin identificatorii lor unici și starea mutabilă. Acestea încapsulează comportamentul și datele legate de un concept specific din domeniu.

De exemplu, într-o aplicație bancară, aBankAccount>entitatea poate avea proprietăți precum numărul de cont, soldul și proprietarul, împreună cu metode de depunere, retragere sau transfer de fonduri.

2. Obiect de valoare

Un obiect de valoare este un obiect de domeniu care reprezintă o valoare imuabilă din punct de vedere conceptual. Spre deosebire de entități, obiectele de valoare nu au o identitate distinctă și sunt de obicei folosite pentru a reprezenta atribute sau proprietăți ale entităților. Obiectele de valoare sunt comparabile cu egalitate pe baza proprietăților lor, mai degrabă decât a identității lor.

De exemplu, aMoney>obiectul valoare poate reprezenta o anumită cantitate de monedă, încapsulând proprietăți precum tipul monedei și suma.

3. Agregat

• Un agregat este un grup de obiecte de domeniu care sunt tratate ca o singură unitate în scopul coerenței datelor și integrității tranzacționale.
• Agregatele constau din una sau mai multe entități și obiecte de valoare, cu o entitate desemnată ca rădăcină agregată.
• Rădăcina agregatului servește ca punct de intrare pentru accesarea și modificarea stării interne a agregatului.
• Agregatele impun limitele de coerență în cadrul modelului de domeniu, asigurând că modificările la obiectele asociate sunt făcute atomic.

De exemplu, într-un sistem de comerț electronic, anOrder>agregatul poate consta din entități precumOrderItem>șiCustomer>, cuOrder>entitate care servește drept rădăcină agregată.

4. Depozitul

• Un depozit este un mecanism pentru abstracția accesului la date și a logicii de persistență din modelul de domeniu.
• Arhivele oferă o interfață standardizată pentru interogarea și stocarea obiectelor de domeniu, ascund detaliile despre modul în care datele sunt preluate sau stocate. Arhivele încapsulează logica pentru traducerea între obiectele de domeniu și mecanismele de stocare a datelor subiacente, cum ar fi baze de date sau servicii externe.
• Prin decuplarea modelului de domeniu de preocupările privind accesul la date, depozitele permit o mai mare flexibilitate și mentenanță.

De exemplu, aCustomerRepository>ar putea oferi metode de interogare și stocareCustomer>entitati.

5. Fabrică

• O fabrică este o model de creație folosit pentru a încapsula logica pentru crearea instanțelor de obiecte de domeniu complexe. Fabricile abstrac procesul de instanțiere a obiectelor, permițând clienților să creeze obiecte fără a fi nevoie să cunoască detaliile construcției lor.
• Fabricile sunt deosebit de utile pentru crearea de obiecte care necesită o logică complexă de inițializare sau implică mai mulți pași.

De exemplu, aProductFactory>ar putea fi responsabil pentru crearea instanțelor deProduct>entități cu configurații implicite.

6. Serviciu

• Un serviciu este un obiect de domeniu care reprezintă un comportament sau o operație care nu aparține în mod natural nici unei anumite entități sau obiect de valoare.
• Serviciile încapsulează logica domeniului care operează pe mai multe obiecte sau orchestrează interacțiunile dintre obiecte.
• Serviciile sunt de obicei apatride și se concentrează pe realizarea unor sarcini specifice sau aplicarea regulilor de domeniu.

De exemplu, anOrderService>ar putea oferi metode pentru procesarea comenzilor, aplicarea reducerilor și calcularea costurilor de transport.

Beneficiile designului bazat pe domeniu (DDD)

• Înțelegere împărtășită :
  • Încurajează colaborarea între experți în domeniu, dezvoltatori și părțile interesate.
  • Încurajând o înțelegere comună a domeniului problemei prin limbajul omniprezent, echipele pot comunica mai eficient și se pot asigura că software-ul reflectă cu acuratețe nevoile și cerințele afacerii.
• Concentrați-vă pe domeniul principal :
  • Ajută echipele să identifice și să prioritizeze domeniul de bază al aplicației - zonele sistemului care oferă cea mai mare valoare afacerii. Concentrând eforturile de dezvoltare pe domeniul de bază, echipele pot oferi funcționalități care se adresează direct obiectivelor de afaceri și diferențiază software-ul de concurenți.
• Reziliență la schimbare :
  • Ea pune accent pe proiectarea sistemelor software care sunt rezistente la schimbare prin modelarea domeniului într-un mod care să reflecte complexitățile și incertitudinile inerente ale domeniului problemei.
  • Prin adoptarea schimbării ca parte naturală a dezvoltării software, echipele pot răspunde mai eficient la nevoile de afaceri în evoluție și condițiile pieței.
• Separarea clară a preocupărilor :
  • DDD încurajează o separare clară a preocupărilor între logica domeniului, preocupările legate de infrastructură și preocupările privind interfața cu utilizatorul. Izolând logica domeniului de detaliile tehnice și preocupările legate de infrastructură, echipele pot menține un model de domeniu curat și concentrat, care este independent de detaliile specifice de implementare sau de opțiunile tehnologice.
• Testabilitate îmbunătățită :
  • Promovează utilizarea obiectelor de domeniu cu limite și comportamente bine definite, facilitând scrierea de teste mai bune și concentrate care verifică corectitudinea logicii domeniului.
  • Prin proiectarea sistemelor software având în vedere testabilitatea, echipele se pot asigura că modificările la baza de cod sunt sigure și previzibile, reducând riscul introducerii regresiilor sau a efectelor secundare neintenționate.
• Suport pentru reguli de afaceri complexe :
  • Acesta oferă modele și tehnici pentru modelarea și implementarea regulilor de afaceri complexe și a fluxurilor de lucru în cadrul modelului de domeniu.
  • Reprezentând regulile de afaceri în mod explicit în modelul de domeniu, echipele se pot asigura că software-ul reflectă cu acuratețe complexitățile domeniului de afaceri și impune constrângerile și cerințele specifice domeniului.
• Alinierea la obiectivele de afaceri :
  • În cele din urmă, își propune să alinieze eforturile de dezvoltare software cu scopurile și obiectivele strategice ale afacerii. Concentrându-se pe înțelegerea și modelarea domeniului problemei, echipele pot furniza soluții software care sprijină direct obiectivele de afaceri, stimulează inovația și creează valoare pentru părțile interesate și utilizatorii finali.

Provocările designului bazat pe domenii (DDD)

• Complexitate :
  • DDD poate introduce complexitate, mai ales în domenii mari și complexe.
  • Modelarea cu acuratețe a unor domenii complexe de afaceri necesită o înțelegere profundă a domeniului și poate implica abordarea ambiguității și incertitudinii. Gestionarea eficientă a acestei complexități necesită o planificare atentă, colaborare și expertiză.
• Adopția de limbă omniprezentă :
  • Stabilirea și menținerea unui limbaj omniprezent - un vocabular comun care reprezintă cu exactitate conceptele de domeniu - poate fi o provocare. Este nevoie de colaborare între dezvoltatori și experți în domeniu pentru a identifica și a conveni asupra termenilor și semnificațiilor domeniului.
  • Atingerea consensului asupra limbajului omniprezent poate necesita depășirea barierelor de comunicare și reconcilierea diferențelor de terminologie și perspective.
• Alinierea contextului delimitat :
  • În domenii mari și complexe, diferite părți ale domeniului pot avea modele distincte și contexte mărginite. Alinierea acestor contexte delimitate și asigurarea coerenței între ele poate fi o provocare.
  • Necesită comunicare clară, colaborare și coordonare între echipele care lucrează pe diferite părți ale domeniului pentru a evita inconsecvențele și conflictele.
• Complexitatea tehnică :
  • Implementarea eficientă a principiilor și modelelor DDD poate necesita adoptarea de noi tehnologii, cadre și abordări arhitecturale. Integrarea DDD cu sistemele existente sau cu bazele de cod vechi poate fi complexă și poate necesita refactorizarea sau reproiectarea codului existent pentru a se alinia cu principiile DDD.
  • Provocările tehnice precum performanța, scalabilitatea și mentenabilitatea trebuie abordate cu atenție pentru a asigura succesul adoptării DDD.
• Rezistenta la schimbare :
  • Introducerea DDD poate întâmpina rezistență din partea membrilor echipei care sunt obișnuiți cu abordările tradiționale de dezvoltare sau care percep DDD ca fiind excesiv de complex sau nepractic.
  • Depășirea rezistenței la schimbare necesită o comunicare eficientă, educație și conducere pentru a demonstra beneficiile DDD și pentru a aborda preocupările și scepticismul.
• Suprainginerie :
  • Există riscul suprainginerării atunci când se aplică DDD, în care echipele se concentrează prea mult pe modelarea conceptelor complexe de domeniu și introducerea de abstracții sau complexitate inutile. Găsirea echilibrului corect între simplitate și expresivitate este crucială pentru a evita complicarea excesivă a designului și implementării.

Cazuri de utilizare ale designului bazat pe domenii (DDD)

• Finanțe și Bănci :
  • În sectorul financiar, DDD poate fi utilizat pentru a modela instrumente financiare complexe, tranzacții și cerințe de reglementare. Reprezentând cu acuratețe concepte de domeniu, cum ar fi conturi, tranzacții și portofolii, DDD ajută la asigurarea integrității și consecvenței sistemelor financiare. De asemenea, permite o mai bună gestionare a riscurilor, conformitate și raportare.
• Comerț electronic și retail :
  • Platformele de comerț electronic se ocupă adesea de concepte complexe de domeniu, cum ar fi cataloagele de produse, gestionarea stocurilor, prețurile și comenzile clienților. DDD poate ajuta la modelarea eficientă a acestor concepte, permițând caracteristici precum recomandări personalizate, prețuri dinamice și procesare simplificată a comenzilor.
• Sănătate și științe ale vieții :
  • În domeniul sănătății, DDD poate fi utilizat pentru a modela înregistrările pacienților, diagnosticele medicale, planurile de tratament și fluxurile de lucru din domeniul sănătății. Reprezentând cu acuratețe concepte de domeniu, cum ar fi datele demografice ale pacienților, istoriile medicale și protocoalele clinice, DDD permite dezvoltarea de sisteme robuste de evidență electronică a sănătății (EHR), platforme de imagistică medicală și aplicații de telemedicină.
• Asigurare :
  • Companiile de asigurări gestionează diverse produse, polițe, daune și procese de subscriere. DDD poate ajuta la modelarea acestor concepte complexe de domeniu, permițând caracteristici precum managementul politicilor, procesarea daunelor, evaluarea riscurilor și analiza actuarială.
• Administrare imobiliară și proprietăți :
  • Gestionarea proprietăților imobiliare și a proprietății implică gestionarea diverselor proprietăți, contracte de închiriere, chiriași, cereri de întreținere și tranzacții financiare. DDD poate ajuta la modelarea eficientă a acestor concepte de domeniu, permițând funcții precum listele de proprietăți, gestionarea închirierii, portalurile chiriașilor și urmărirea activelor.

Exemplu real de proiectare bazată pe domenii (DDD)

Declarație problemă

Să spunem că dezvoltăm o aplicație de transport numită RideX. Sistemul permite utilizatorilor să solicite curse, șoferilor să accepte cererile de călătorie și facilitează coordonarea curselor între utilizatori și șoferi.

java static

Limbaj omniprezent

1. Utilizator : Se referă la persoanele care solicită curse prin intermediul platformei RideX.
2. Conducător auto : Se referă la persoanele care oferă călătorii utilizatorilor prin intermediul platformei RideX.
3. Cerere de călătorie : Reprezintă solicitarea unui utilizator pentru o cursă, specificând detalii precum locația de preluare, destinația și preferințele de călătorie.
4. plimbare : reprezintă o singură instanță a unei călătorii, inclusiv detalii precum locațiile de preluare și predare, tarif și durata.
5. Starea călătoriei : Reprezintă starea curentă a unei călătorii, cum ar fi Solicitat, Acceptat, În curs sau Finalizat.

Contexte delimitate

1. Contextul managementului călătoriei : responsabil pentru gestionarea ciclului de viață al curselor, inclusiv solicitările de curse, atribuirea curselor către șoferi și actualizările stării curselor.
2. Context de gestionare a utilizatorilor : se ocupă de autentificarea, înregistrarea și caracteristicile specifice utilizatorului, cum ar fi istoricul curselor și metodele de plată.
3. Contextul managementului șoferului : Gestionează autentificarea șoferului, înregistrarea, starea disponibilității și caracteristicile specifice șoferului, cum ar fi câștigurile și evaluările.

Entități și obiecte de valoare

1. Entitate utilizator : reprezintă un utilizator înregistrat al platformei RideX, cu proprietăți precum ID de utilizator, e-mail, parolă și informații de plată.
2. Entitatea șofer : reprezintă un șofer înregistrat pe platforma RideX, cu proprietăți precum ID-ul șoferului, detaliile vehiculului și starea șoferului.
3. Entitatea de solicitare a călătoriei : reprezintă solicitarea unui utilizator pentru o cursă, inclusiv proprietăți precum ID-ul cererii, locația de preluare, destinația și preferințele de călătorie.
4. Ride Entitate : reprezintă o singură instanță a unei curse, inclusiv proprietăți precum ID-ul cursei, locațiile de preluare și predare, tarif și starea cursei.
5. Obiect de valoare locație : reprezintă o locație geografică, cu proprietăți precum latitudinea și longitudinea.

Agregate

1. Ride Agregat : Constă din Entitatea Ride ca rădăcină agregată, împreună cu entități conexe, cum ar fi entitățile Ride Request, User și Driver. Ride Aggregate încapsulează logica pentru gestionarea ciclului de viață al unei călătorii, inclusiv gestionarea solicitărilor de călătorie, atribuirea șoferilor și actualizarea stării călătoriei.

Repertoriu

1. Depozitul Ride : Oferă metode de interogare și stocare a entităților legate de curse, cum ar fi preluarea detaliilor cursei, actualizarea stării cursei și stocarea datelor referitoare la curse în baza de date.

Servicii

1. Serviciul de alocare de călătorie : responsabil pentru alocarea șoferilor disponibili pentru solicitările de călătorie pe baza unor factori precum disponibilitatea șoferului, apropierea de locația de preluare și preferințele utilizatorului.
2. Serviciul de plată : se ocupă de procesarea plăților pentru cursele finalizate, calculează tarifele, procesează plăți și actualizează informațiile de plată pentru utilizator și șofer.

Evenimente de domeniu

1. RideRequestedEvent : Reprezintă un eveniment declanșat atunci când un utilizator solicită o călătorie, care conține informații precum detaliile cererii de călătorie și ID-ul utilizatorului.
2. RideAcceptedEvent : reprezintă un eveniment declanșat atunci când un șofer acceptă o solicitare de călătorie, care conține informații precum ID-ul cursei, ID-ul șoferului și locația de preluare.

Exemplu de scenariu

1. Utilizator care solicită o călătorie : un utilizator solicită o cursă furnizând locația de preluare, destinația și preferințele de călătorie. RideX creează o nouă entitate de cerere de călătorie și declanșează un RideRequestedEvent.
2. Șofer care acceptă o călătorie : Un șofer acceptă o cerere de călătorie de la platforma RideX. RideX actualizează starea călătoriei la Accepted, atribuie șoferului cursei și declanșează un RideAcceptedEvent.
3. Călărie în curs : utilizatorul și șoferul coordonează călătoria, starea călătoriei trecând de la Acceptat la În curs odată ce șoferul ajunge la locul de preluare.
4. Finalizarea călătoriei : După ajungerea la destinație, starea călătoriei este actualizată la Finalizat. RideX calculează tariful, procesează plata și actualizează informațiile de plată pentru utilizator și șofer în consecință.