Respostas:
Em primeiro lugar, se você não sabe que precisa, é possível que não precise. Se você não reconhece os problemas que o DDD resolve, talvez você não tenha esses problemas. Até mesmo os advogados do DDD apontam frequentemente que o DDD é destinado apenas a projetos grandes (> 6 meses).
Supondo que você ainda esteja lendo neste momento, minha opinião sobre o DDD é esta:
O DDD consiste em tentar tornar seu software um modelo de sistema ou processo do mundo real. Ao usar o DDD, você deve trabalhar em estreita colaboração com um especialista em domínio que pode explicar como o sistema do mundo real funciona. Por exemplo, se você estiver desenvolvendo um sistema que lida com apostas em corridas de cavalos, seu especialista em domínio pode ser um apostador experiente.
Entre você e o especialista em domínio, você cria uma linguagem onipresente (UL), que é basicamente uma descrição conceitual do sistema. A idéia é que você consiga anotar o que o sistema faz de maneira que o especialista em domínio possa lê-lo e verificar se está correto. No nosso exemplo de apostas, a linguagem onipresente incluiria a definição de palavras como 'raça', 'aposta', 'probabilidades' e assim por diante.
Os conceitos descritos pela UL formarão a base do seu design orientado a objetos. O DDD fornece algumas orientações claras sobre como seus objetos devem interagir e ajuda a dividir seus objetos nas seguintes categorias:
O DDD também recomenda vários padrões:
Agora, neste momento, devo dizer que se você nunca ouviu falar de alguma dessas coisas antes, não deveria tentar usar o DDD em nenhum projeto para o qual tenha um prazo. Antes de tentar o DDD, você deve estar familiarizado com os padrões de design e os padrões de design corporativo . Conhecer isso torna o DDD muito mais fácil de entender. E, como mencionado acima, há uma introdução gratuita ao DDD disponível na InfoQ (onde você também pode encontrar palestras sobre DDD).
Tome StackOverflow como um exemplo. Em vez de começar a projetar alguns formulários da Web, você se concentra primeiro na modelagem orientada a objetos das entidades no domínio do problema, por exemplo Usuários, Perguntas, Respostas, Votos, Comentários etc. Como o design é orientado pelos detalhes do problema domínio, é chamado de design orientado a domínio .
Você pode ler mais no livro de Eric Evans .