One Model to rule them all !

Confesso que ainda que simpatize com Domain Driven Design e procure praticar alguns de seus conceitos, não conclui a leitura da "bíblia" do assunto. Ainda assim julgava ter um entendimento satisfatório, haja vista a leitura parcial da referência e a leitura de infindáveis posts que li nas comunidades de desenvolvimento.
Uma conclusão precipitada que tomei, baseado no meu conhecimento parcial do assunto, foi que um conceito chave desta disciplina era a existência de um modelo de domínio ÚNICO por aplicação, o qual acomodaria as regras de negócio, ou parafraseando o Senhor dos Anéis: "One Model to rule them all" .
Recentemente me deparei com a entrevista de um desenvolvedor/arquiteto de software de nome Greg Young, na Infoq, que me chamou atenção pelo fato deste praticar DDD em comunhão com Imutabilidade, algo que venho confabulando há algum tempo. Porém o que mais me chamou atenção foi o fato dele ter modelos de domínio distintos para escrita e para leitura de dados. Intrigado com essas peculiaridades de design pesquisei mais sobre o assunto e encontrei um blog do referido entrevistado no qual ele desenvolve melhor esses conceitos. A explanação culmina na seguinte afirmação.

O que é uma pá de cal na minha na minha ingênua conclusão sobre DDD: "One Model to rule them all" .
Juntados os cacos, resta recompor-me e aproveitar este incidente como motivação para dar continuidade a leitura da "bíblia" e para pesquisar sobre "domínio múltiplo". Como produto destas pesquisas espero responder as perguntas do tipo: Seria o design com "domínio multiplo" uma prática comum no mundo DDD? O "domínio múltiplo" é uma condição para se praticar DDD e imutabilidade? Quais os impactos na coesão do sistema? Isso não seria uma extrapolação Chiita dos princípios de design SRP e Command-Query Separation para arquitetura? Certezas poucas e dúvidas muitas!