I say that DDD sounds nice in principle, and in blog posts, and in books, but I have yet to see that magical fairy land be implemented in the real world.
Aggregates (and drawing their boundaries), especially when combined with domain models backed by an ORM must be one the more impractical programming concepts that I've met in my life.
P.S. I also don't trust programmers who write (enterprise) books for a living.
Well, I for one, have used it successfully four times (and no failures yet!).
From my experience, if I focus on the domain, and play around with it for a while, I will start to see a structure behind it (different from a relational structure). And, I've found that if I structure it correctly, the aggregates sort of just fall out.
I agree with you to be wary of book authors' ideas. However, the paradigm that Eric Evans documented was truly useful to me. But, I also think that the book he wrote on the topic was a hard trod, overly abstract, and didn't make much sense at first. I mean, it sort of made sense in theory. But, it wasn't until I tried it out on particular projects that I saw its usefulness.
I wouldn't recommend trying it out on a brand new project. But, instead, take an existing project, fork it, and try to apply it. At least you'll get a better understanding if it can and will work for you, or not.
DDD helps me to not go insane. But, on the other hand, I've had to listen to quite a few complaints from my team, who usually want to see something more procedural.
It's neither obsolete, nor antiquated. People in this thread seem to conflate DDD and OOP which is understandable given that 90% of DDD resources target the typical enterprise Java/C# setting.
The truth is, DDD consists of two parts: tactical patterns, such as Entity, Value Object or Aggregate Root and strategic design patterns such as Ubiquituos Language, Bounded Context or Context Maps. Tactical patterns are much easier to understand and apply, but most of the benefits claimed by DDD are provided by the application of strategic design.
Sadly, most people starting with DDD focus on the tactical patterns and technology, then get demotivated when the benefits do not appear.
I agree completely. As someone who has been studying DDD for myself I concur that the strategic design is where I struggle and where DDD really shines. I still can't quite understand bounded contexts.
From my recent experience on a real project DDD inspires very rigid thinking sometimes on the boundary of being religious (e.g. the quest for pure Values and Aggregates eclipsing the problem domain understanding).
And for a regular "aggregate" entity I would never prefer a JSON storage to a data mapper with SQL (as long as you have an option to use SQL). You should have a reason for JSON and such, otherwise it's just NoSQL hype.
Hard to describe it in one sentence. Just look at the various DDD resources. It's difficult to put together the meaning of the numerous concepts introduced (and often just renamed) by Evans. The core idea is - just like in OOP - to pack data and most business logic into domain or entity objects. IMO, a questionable approach.
DDD was adopted by the C#/.NET community, which is why you might find many of the resources sparse and relatively irrelevant if you're not on the .NET stack.
However, recent projects are largely based on a lot of the DDD theory. In fact, most "big data" tools and its ecosystem are just DDD implementations. Examples: kafka, storm, amazon's kinesis, impala, amazon's lambda, and so and so forth are all just implementations of DDD.
The recently marketed "Lamda Architecture"[1] is another implementation of DDD.
> DDD was adopted by the C#/.NET community, which is why you might find many of the resources sparse and relatively irrelevant if you're not on the .NET stack.
