I think it’s really hard to present a definitive definition for Domain Driven Design. In my opinion, Domain Driven Design can be seen as a philosophy for developing applications based on specific domains and their logic where an ubiquitous language use is probably one of its most important features. If you’ve read Eric Evan’s book, then you’d probably agree that Eric hasn’t really introduced (or invented) anything new. On the other hand, you’ll surely noticed that his book (which is responsible for introducing DDD concepts to many!) presents several good design practices, techniques and principles which you can apply to solve problems associated with complex domains. So, in a way, you can see DDD as something that has grouped several known principles for domain modeling.
Now, do pay attention to the term complex! Yes, DDD really shines when you have complex (or complicated) domains. If you don’t have a complicated or complex domain, then probably you won’t be gaining much from DDD. Why? well, because the truth is that you’ll end up paying a penalty for using DDD (it’s really great for expressing relations between domain objects, but not so good for building objects that should be directly consumed by data bound applications). Don’t get me wrong: I do love DDD and I think it has helped me a lot in solving some complex problems. Following its recommendations has led me to deliver some pretty good models that express what’s going on in the “real” world.
However,it might be too much for several applications. Whenever you have a “data” bound application,you’ll probably end up hurting yourself if you try to apply all the principles advocated by Eric in his book. In theses cases, what you should do is follow what is now know as “DDD-lite”. But what is “DDD-lite”? Well, you can think of it as subset of good OO techniques which you can reuse in your projects without going all the “DDD way”. I’ve found this post which talks about several principles that lead to “DDD-lite” and I do agree with the author in most of the topics he presents.
For instance, in my projects (even in those where I don’t go full DDD), I’ll always use concepts like repositories, factories and services. These concepts aren’t enough for saying that you’re using DDD but they sure are reusable across different projects and will improve the final product. So, is DDD for you? The truth is that you’re the only one that can answer this question, but don’t forget that the subset of principles now know as “DDD-lite” can (and should!) be applied to all good OO projects.