That’s why I believe DDD is both model-driven design and domain-driven modeling. Just model-driven design isn’t enough, the model has to be created from the domain.

There are indeed implicit patterns that go along with DDD. DDD is a pattern of patterns. If you remove the patterns, there’s not much left but the ideology.

I have built Rails apps and EF apps. I’ve applied the maturity that lives in me that has grown from DDD practice to those projects. I promise that my capabilities for applying DDD were drastically reduced by the technological constraints.

DDD isn’t just patterns, and it isn’t just ideas. It’s both, and when you de-emphasize one aspect, the other aspect suffers commensurately. If all you’re left with is the modeling and analysis ideas form DDD, you’re left with the stuff predates DDD and that DDD imported. At that point, it’s not clear that what you’ve got left is DDD at all – at least not very meaningfully.

We might be in aggrement though because if its just that the architecture is not using repositories then absolutely that might still be DDD…I just wouldn’t call *any* model/UL driven effort DDD.

If I look at a Rails app, which uses Active Record, doesn’t use Repositories, but still uses Domain Model, then yes, I would say it uses DDD. The other patterns are there to make the model to code paradigm easy.

I just don’t think DDD is a term reserved for a specific set of patterns.

The main thing I’m really curious about here is the gradations of DDD. How hard and far do you have to push to unify that language before you can call an app DDD?

Using your previous example of asking questions of the developers and the domain experts, would you consider something 90% DDD if only a few things were not ubiquitous and inconsistent?

I’ve always had a hard time not looking at DDD as an all or nothing equation, and every time I see that it’s not it only brings up more questions and the question of what makes up DDD.

“We can use the Active Record pattern and follow DDD. We can use the Entity Framework or LINQ to SQL and follow DDD. We can use hand-rolled ADO.NET, constrained to a 5-year-old legacy application, and follow DDD”

In this list I wouldn’t disagree with these, but on top of that in real life would you use the term DDD if we did not apply any of the design patterns?

I have a follow-up to this one on picking the right DDD tools. My point is that you _can_ use other tools. You could still apply DDD principles building an MS Access application, if that’s the technology you needed to use.