Does anyone actually build Rich Domain Models in real world DDD projects anymore
Hi everyone,
I’ve been working on a few different .NET projects lately that all claim to be using Domain-Driven Design, but I'm starting to notice a huge gap between the textbook theory and what we actually ship. Honestly, in my experience, a true "Rich Domain Model" is basically a myth. Whenever I look at our codebases, the entities are essentially just anemic property bags with public setters.
Instead of encapsulating behavior inside the domain, all the actual business logic, state changes, and orchestrations just live in the Application layer, usually shoved into command handlers. Even validation is completely outsourced. We just rely heavily on FluentValidation in Application before anything even gets a chance to touch the domain. And when it comes to Value Objects, we almost never build robust, encapsulated types. Most of the time, something that probably should be a Value Object just gets turned into a standard C# enum or left as a primitive .
It feels like the only parts of DDD we actually adopt are the structural concepts. We do split things into Bounded Contexts, we identify Aggregate Roots and Entities, and we strictly follow the rule of having one repository per AR to fetch the parent and its children as a single unit. But beyond that structural organization, the domain itself is completely hollow.
I really want to know what DDD looks like in the trenches for the rest of you. Is this combination of anemic models, application handlers, and FluentValidation basically the unspoken reality of .NET enterprise apps? If you are actually out there successfully enforcing invariants and behavior inside rich domain models, how do you manage complex validations or rules that cross multiple aggregates without turning your domain into a messy dependency nightmare? I'd love to hear how much of the DDD textbook actually makes it into your production codebases.