Domain-Driven Design în era AI: de ce contextele delimitate contează mai mult acum

Acum un deceniu, Domain-Driven Design părea exagerat pentru majoritatea echipelor de inginerie. Pattern-urile — agregate, value objects, bounded contexts, ubiquitous language — rezolvau probleme reale, dar doar pentru echipe suficient de mari și complexe încât să simtă durerea de a le face greșit. Pentru toți ceilalți, DDD arăta ca ceremonie enterprise importată de la companii care aveau trei niveluri de comitete de revizuire a arhitecturii.

În 2026, cu LLM-uri scriind procente semnificative din codul de producție, calculul s-a inversat. DDD nu mai este un lux de enterprise. Este cel mai ieftin mod de a împiedica codebase-urile asistate de AI să se prăbușească sub propria greutate.

Modelul este granița prompt-ului

Când îi ceri lui Claude sau Cursor să "adauge un flux de refund la modulul de comenzi", modelul are nevoie să știe exact ce este o Order, ce este un Refund, ce tranziții de stare sunt valide și ce alte module sunt interesate. Dacă baza ta de cod are un model de domeniu clar — Order, OrderLine, Refund, RefundReason ca tipuri bine numite cu invarianți expliciți — modelul are o hartă. Știe ce să atingă și ce să lase în pace.

Dacă baza ta de cod are un tabel data cu treizeci de coloane și logică de business împrăștiată prin controllere, servicii și "utils", modelul nu are nimic. Va ghici. Uneori ghicitura este corectă. Alteori, fluxul de refund ajunge să apeleze webhook-ul greșit pentru că două funcții au avut nume similare.

Bounded context-ul nu este doar o subtilitate arhitecturală. Este unitatea naturală la care un LLM poate raționa fără să se învârtă.

Agregatele ca suprafețe de tool pentru agenți

Aceeași schimbare apare în fluxurile agentice. Când îi dai unui agent LLM un set de tool-uri — createOrder, applyRefund, cancelShipment — ceea ce faci de fapt este să expui operațiuni pe agregate root către model.

Tool-urile care se mapează curat pe agregate sunt ușor de folosit corect de către model. Au un singur punct de intrare, intrări clare, post-condiții clare, iar agregatul impune propriii invarianți. Agentul nu poate lăsa accidental comanda într-o stare inconsistentă pentru că agregatul nu îi va permite.

Tool-urile care nu se mapează pe agregate — tool-uri generice de stil updateRecord sau runQuery — sunt locul unde agenții deraiază. Prea multă libertate, niciun invariant impus, iar modelul trebuie să reconstruiască regulile de business din prompt-uri. Aceasta este sursa majorității poveștilor cu "agentul a șters un tabel".

Dacă construiești un sistem agentic în 2026, proiectează-ți tool-urile ca operațiuni pe agregate mai întâi. Tool-uri generice de manipulare a datelor vin mai târziu, în spatele unor garduri, dacă vin.

Ubiquitous language oprește problema lucrului-greșit

Cea mai puțin tehnică idee din DDD este cea mai valoroasă în era AI. Ubiquitous language înseamnă că același termen — Customer, Subscription, Plan — are același sens în conversație, în spec, în sistemul de tipuri și în baza de date. Fără tabelul users vs API-ul customer vs "client" în email-ul product manager-ului.

Motivul pentru care contează mai mult acum: LLM-urile nu semnalează inconsistențele așa cum ar putea-o face revizorii umani. Dacă baza ta de cod îi numește users în unele locuri și customers în altele, iar specul tău folosește "client", modelul va alege una din cele trei aproape la întâmplare și va produce încrezător o implementare funcțională-dar-greșită. Bug-ul nu este într-o singură linie. Este în confuzia conceptuală.

Investiția a două zile în redenumirea totul la un singur termen — și adăugarea unui glosar la nivelul superior al repo-ului — se amortizează data viitoare când livrezi o funcționalitate. Am văzut asta direct pe mai multe proiecte: același agent, pe aceeași bază de cod, cu același model, livrează cod măsurabil mai bun după o curățare a numelor.

Value objects sunt cum ai încredere în codul generat de AI

Value objects — tipuri mici, imutabile, care învelesc primitive cu validare — sunt obositoare de scris manual. Sunt triviale de scris cu un LLM și se transformă în siguranță la runtime în momentul în care agentul greșește.

Email, MoneyAmount, OrderStatus, PhoneNumber — fiecare o mică clasă sau tip cu validare la construcție. Codul generat de LLM care urmează nu mai poate trece un string acolo unde se așteaptă un Email. Invariantul este impus la graniță, nu în interiorul fiecărei funcții.

Aceasta este cea mai plictisitoare recomandare posibilă în 2026 și totodată una dintre cele mai utile. Douăzeci de value objects, scrise de agentul tău într-o după-amiază, elimină o categorie întreagă de bug-uri la care codul generat de LLM este deosebit de predispus: să transmită încrezător primitiva greșită în forma corectă.

Bounded contexts ca structură de repository

Definiția originală DDD a unui bounded context este "o graniță în care un model particular este definit și aplicabil". Într-o bază de cod din 2026, această graniță ar trebui să fie vizibilă în structura de directoare. Un folder per bounded context. Referințele cross-context trec prin interfețe explicite (evenimente, anti-corruption layers sau contracte API tipate) — niciodată prin importuri directe.

De ce contează asta pentru lucrul asistat de AI: ferestrele de context sunt încă finite, chiar și cu cei 200K de tokeni pe care îi are la dispoziție Claude Opus 4.7. Un agent care lucrează în contextul billing ar trebui să poată încărca doar contextul de billing și să aibă tot ce-i trebuie. Dacă billing importă din orders, customers, notifications, analytics și auth, modelul încarcă jumătate din codebase pentru a face o modificare de o linie.

Arhitecturile cu vertical slice / feature-folders (despre care am scris separat) sunt în esență bounded context-uri DDD sub un alt nume, optimizate pentru cazul în care fiecare "context" este mic.

Ce nu repară DDD

DDD nu este o soluție magică, iar 2026 nu a făcut-o așa. Este încă posibil să aplici DDD greșit, să construiești modelul de domeniu greșit și să produci o bază de cod care este conceptual curată și operațional inutilă. Modurile comune de eșec încă se aplică:

• Modele de domeniu anemice — entități care sunt doar saci de getteri și setteri cu toată logica în servicii. Mai rău cu LLM-urile, pentru că imită pattern-ul agresiv.
• Suprapuneri — modelarea fiecărui detaliu de business ca tip de primă clasă când un struct ar fi suficient. Te costă în indirecție fără să cumperi invarianți.
• Împărțirea prematură a contextelor — trasarea liniilor de bounded context prea devreme, când încă nu știi unde se desparte natural domeniul.

Sfatul în 2026 este același cu cel din 2016: începe cu cel mai simplu model care surprinde invarianții care contează cu adevărat și extrage bounded context-urile când simți cusăturile.

Ce s-a schimbat

DDD a fost o taxă în 2016. În 2026, când costul marginal al scrierii codului s-a prăbușit și costul marginal al înțelegerii codului este cel care domină, DDD se amortizează mai repede. Fiecare agregat bine numit este un prompt pe care modelul nu trebuie să-l ghicească. Fiecare value object este un bug pe care modelul nu îl poate livra. Fiecare bounded context este o bucată de cod care încape într-o fereastră de context.

Schimbarea nu este despre DDD devenind mai corect. Economia s-a schimbat. Scrierea modelului este mai ieftină acum; modelul în sine este mai valoros ca niciodată.

Dacă ai amânat DDD pe teoria că este prea greu pentru echipa ta, acesta este anul să revii asupra ei. Munca s-a mutat de la scrierea codului la proiectarea domeniului. Alege-ți bounded context-urile, denumește-le cu grijă și lasă agentul să umple restul.