Segundo Gabriel Schenker, ao compartilhar sua experiência trabalhando como consultor e arquiteto de software, é comum encontrar alegações dizendo que as aplicações foram construídas usando o Domain-Driven Design (DDD), mas na verdade o seu domain model só consiste de entidades ou mesmo DTOs que separam os dados e a lógica dos serviços contendo uma mistura de lógica de negócios e infraestrutura. Nas aplicações que manipulam mensagens, essas mensagens são raramente denominadas no domínio, ao invés disso, são usados nomes genéricos que terminam com update ou modify.
Schenker, atualmente trabalha como diretor de arquitetura de software, observa que esses exageros não ocorrem apenas em aplicações antigas, porque ele frequentemente encontra esses problemas nas fases iniciais de novas aplicações. Umas das maiores razões para isso acredita Schenker, é a falta de conhecimento.
Ao trabalhar com DDD, Schenker enfatiza que nem todos os padrões do livro original de DDD do Eric Evans são igualmente importante e observa especialmente que a base do DDD é encontrada mais à frente no livro, algo que já foi reconhecido por Evans. Em contraste a estes padrões estratégicos, a primeira metade do livro é focado nos detalhes de implementação e padrões táticos.
Schenker aconselha que ao iniciar um novo projeto usando o DDD a primeira coisa a se fazer é trabalhar com os especialistas de domínio para obter um entendimento do domínio do negócio e destas discussões extrair a terminologia usada para criar um vocabulário comum que todos concordem, uma linguagem ubíqua nos termos do DDD. Seguindo isso, um complexo domínio deve ser quebrado, ao usar os especialistas no domínio, para identificar as áreas que podem ser separadas, criando subdomínios e contextos delimitados, outro termo DDD.
Outra coisa que Schenker desaconselha é a criação de um mundo centrado nos dados, começando com um modelo de dados. Ele acredita firmemente que os dados isoladamente não são nada; é necessário lógica para que os dados tenham significado, mas note também que isso vária com o contexto, portanto o contexto e a lógica devem ser o foco principal ao fazer DDD. Outro risco de quando focamos nos dados é que os bancos de dados acabam sendo usados para integração, efetivamente criando dependências entre os contextos de outra forma isoladas. Stefan Tilkov recentemente desaconselhou o uso de um modelo de dados comum.