Ludo Programming

Într-un proiect bine structurat, separarea între ReadModel și DomainModel este un pas esențial pentru a menține claritatea, performanța și respectarea principiilor SOLID. Deși este o etapă opțională, ea devine foarte utilă odată ce aplicația crește în complexitate.

🎯 Ce înseamnă această separare?

• DomainModel-ul conține logica de business, regulile, entitățile agregate și constrângerile care guvernează domeniul aplicației.

• ReadModel-ul (sau DTO pentru citire) este o proiecție simplificată, optimizată pentru interfața utilizator și cererile de tip query.

📌 Exemplu concret

Să presupunem că ai o entitate Post în domeniu:

public class Post

{

    public Guid Id { get; private set; }

    public string Title { get; private set; }

    public string Content { get; private set; }

    public DateTime CreatedAt { get; private set; }

    // Logica de business: validări, actualizări, publicare, etc.

}

Pe de altă parte, în zona de citire, poți avea un model dedicat interfeței:

public class PostReadDto

{

    public Guid Id { get; set; }

    public string Title { get; set; }

    public string Excerpt { get; set; } // primele 100 caractere

    public string FormattedDate { get; set; } // ex: "30 iulie 2025"

}

🧠 Beneficiile separării

• Performanță – DTO-urile pot evita mapări inutile și pot conține doar ce e necesar.

• Claritate arhitecturală – Modelul de domeniu rămâne curat, fără proprietăți legate de UI.

• Independență – Poți ajusta UI-ul fără să afectezi logica de business.

• Testabilitate – Poți scrie teste unitare pe DomainModel fără a te lovi de formatarea datelor pentru UI.

🔄 Flux tipic cu separare

Query → MediatR → Handler → Repo → Proiecție (ReadModel/DTO) → UI

📌 Recomandări

• În handlerul de query, folosește Select cu proiecție directă spre DTO (evitând AutoMapper dacă nu ai nevoie de mapări complexe).

• Returnează ReadModel doar pentru citire – evită să expui structura din DomainModel public.

✅ Concluzie

Separarea clară între ReadModel și DomainModel te ajută să dezvolți aplicații robuste, bine organizate și ușor de întreținut. Este o investiție arhitecturală care își arată valoarea pe termen lung, mai ales în aplicațiile enterprise.