A principal ideia do DDD é a de que o mais importante em um software não é o seu código, nem sua arquitetura, nem a tecnologia sobre a qual foi desenvolvido, mas sim o problema que o mesmo se propõe a resolver, ou em outras palavras, a regra de negócio. Ela é a razão do software existir, por isso deve receber o máximo de tempo e atenção possíveis. Em praticamente todos os projetos de software, a complexidade não está localizada nos aspectos técnicos, mas sim no negócio, na atividade que é exercida pelo cliente ou problema que o mesmo possui. Como já diz o título do livro de Eric Evans, esse é o “coração”, o ponto central de qualquer aplicação, portanto todo o resto deve ser trabalhado de forma que este “coração” seja entendido e concebido da melhor forma possível.
O domínio é o ponto central de qualquer aplicação, é por causa dele que o software é criado afinal de contas. Reforçando o que já foi falado anteriormente, é o domínio que concentra a maior parte da complexidade de quase todos os projetos de software.
Podemos afirmar com alguma certeza que na maioria dos projetos, a equipe de desenvolvimento não possui inicialmente conhecimento sobre o domínio do problema. Esse conhecimento deverá ser adquirido de pessoas especialistas nesse domínio, que geralmente são os clientes (em alguns casos pode ser um membro da própria equipe – no exemplo do call center são os atendentes, supervisores etc.), desde o início do projeto. A comunicação entre equipe e especialistas do domínio deve ser constante, de forma que o conhecimento seja nivelado o quanto antes. Para que isso possa ocorrer, é necessário que tanto desenvolvedores como os especialistas utilizem a mesma linguagem, com o objetivo de facilitar a comunicação e o entendimento entre todos.
Fonte: http://www.devmedia.com.br/ddd-domain-driven-design-com-net/14416