I heard about Domain Driven Development from a developer in the area. He talked it up like it was just about the silver bullet to changing requirements.
I read the wiki. Still not too clear. What is "3D" in practical terms? Is it really that amazing that now UML class diagramming is just obsolete?
Well, first of all, I don't think that the Wikipedia article you refer to is very good, mostly because it references a bunch of things that are only ancillary to Domain Driven Design and does little to enlighten anyone about the practice.
But, as someone who has taken Domain Driven Design to heart (which usually goes by DDD, rather than 3D, for what it's worth), I always felt the fundamentals of DDD are obvious, if you read so much as the first chapter of Eric Evans' book. But it is a set of patterns and practices, so it's not that easy to give a 3 sentence summary of what it is and what the advantages are without going into some detail. Which details resonate with any one person might be very different, too; it's probable that 10 years ago I wouldn't have seen the point at all, myself.
DDD is not a silver bullet. When done sensibly, it's about taking a craftsman-like approach to building software, and recognizing the need to reduce the cognitive friction between development teams and the businesses they are building software for. One of the most important practices is to have a layer in which the domain vocabulary used by the software team and the business team matches as closely as possible. You build this layer iteratively as you come to understand the business problem that you are trying to solve. When business logic is sensibly encoded in this layer, isolated from all the convoluted dependencies that enterprise applications typically have by factoring interactions with those systems out to interfaces, the language used in the actual domain layer eventually becomes fairly concise, obvious, and readable. When you review your model with the business, they will often correct you, and you gradually refactor to a deeper understanding of the domain.
Considering the shape that I've seen most enterprise software in, in practice, DDD may sound like a silver bullet, because most enterprise software has such poor separation of concerns that it's nearly untestable, and the software team lives in great fear of change because they have no idea what the side effects of ostensibly even trivial code changes might be, whereas a properly factored domain layer will be independently testable and verifiable. But actually, DDD acknowledges that systems rarely exist in isolation. DDD includes coping patterns for legacy systems (Anti-corruption layer, bounded contexts, to name a couple).
If you practice object-oriented design, including the discipline of loose coupling, and you practice unit testing fairly religiously, and you mercilessly refactor code, and you work with domain experts while building your system, essentially you'll end up with a result that's basically what advocates of domain driven design are talking about.
There are a few specific patterns described in Evans's book that apply mostly to enterprise software development, and some that are fairly universal principles, but essentially, DDD is a pragmatic approach to software development that can, over time, reduce the buildup of technical debt, and make your customers happier because you are able to speak the same language with each other, and deliver better-working solutions because of the advantages of understanding each other better.
A high-level description could be -
Model your classes to mirror the data structures and behaviour of your problem domain.
This allows you to map changes in your problem domain directly to changes in your code, so it should be more easy to update as your problem domain evolves.
DISCLAIMER: I've added this answer after this question has been marked as duplicate. I disagree, but here we are. :-)
Domain-Driven Design aims to design software in high-value/high complexity domains.
This turns into a different approach for building enterprise software: there's too much learning involved, and the most important consequence is that you won't get to the right solution at first shot.
Or the combination of both.
Both ways you'll need good software foundations for frequently rewrite software. That's the reason why the book stressed on a given set of patterns around the Domain Model pattern: they were the most reasonable combination in 2004.
However, OOP and the tactical pattern are not the most important thing. Technical mastery is necessary in order to build great software in an evolutionary way. But it's only one ingredient of the recipe. The others?
