Bem, primeiro de tudo, não acho que o artigo da Wikipedia a que você se refere seja muito bom, principalmente porque faz referência a várias coisas que são apenas auxiliares ao Design Orientado a Domínio e pouco faz para esclarecer alguém sobre a prática.
Mas, como alguém que levou o Design Orientado a Domínio a sério (o que geralmente vale pelo DDD, e não pelo 3D, pelo que vale a pena), sempre achei que os fundamentos do DDD são óbvios, se você ler tanto quanto o primeiro capítulo de Eric Livro de Evans. Mas é um conjunto de padrões e práticas, portanto, não é tão fácil fornecer um resumo de três frases sobre o que é e quais são as vantagens sem entrar em detalhes. Quais detalhes ressoam com qualquer pessoa podem também ser muito diferentes; é provável que dez anos atrás eu não tivesse entendido nada disso.
DDD não é uma bala de prata. Quando feito de maneira sensata, trata-se de adotar uma abordagem artesanal para criar software e reconhecer a necessidade de reduzir o atrito cognitivo entre as equipes de desenvolvimento e as empresas para as quais estão construindo o software. Uma das práticas mais importantes é ter uma camada na qual o vocabulário de domínio usado pela equipe de software e pela equipe de negócios corresponda o mais próximo possível. Você constrói essa camada de forma iterativa ao entender o problema de negócios que está tentando resolver. Quando a lógica de negócios é sensivelmente codificada nessa camada, isolada de todas as dependências complicadas que os aplicativos corporativos normalmente têm ao fatorar interações com esses sistemas nas interfaces, a linguagem usada na camada de domínio real acaba se tornando bastante concisa, óbvia e legível.
Considerando a forma em que eu vi a maioria dos softwares corporativos, na prática, o DDD pode parecer uma bala de prata, porque a maioria dos softwares corporativos tem uma separação tão pobre de preocupações que é quase impossível de ser testada, e a equipe de software vive com muito medo de mudar porque eles não têm idéia de quais podem ser os efeitos colaterais de alterações aparentemente triviais no código, enquanto uma camada de domínio adequadamente fatorada será testada e verificável independentemente. Mas, na verdade, o DDD reconhece que os sistemas raramente existem isolados. O DDD inclui padrões de enfrentamento para sistemas legados (camada anticorrupção, contextos limitados, para citar alguns).
Se você pratica o design orientado a objetos, incluindo a disciplina do acoplamento flexível, pratica o teste de unidade de maneira bastante religiosa e refata o código sem piedade, e trabalha com especialistas em domínio ao criar seu sistema, basicamente você terá um resultado basicamente sobre o que os defensores do design orientado por domínio estão falando.
Existem alguns padrões específicos descritos no livro de Evans que se aplicam principalmente ao desenvolvimento de software corporativo e alguns que são princípios bastante universais, mas essencialmente, o DDD é uma abordagem pragmática do desenvolvimento de software que pode, com o tempo, reduzir o acúmulo de dívida técnica, e torne seus clientes mais felizes porque você consegue falar o mesmo idioma entre si e fornecer soluções que funcionem melhor devido às vantagens de se entender melhor.
