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.