Estou lendo que você é da opinião de que os testes de unidade, assim como os objetos SOLID, devem ter "um motivo para quebrar". É um objetivo nobre, mas acho que você descobrirá que, em muitos casos, simplesmente não é viável. Um desses casos é aqui, onde você tem um objeto de domínio "rico" (o DDD diferencia entre Entidades e Objetos de Valor, que incluem o "modelo de domínio") que é uma dependência do sistema em teste.
Nessas situações, tenho a filosofia de que, dada ao objeto de domínio tem sua própria cobertura abrangente de teste de unidade, confiar que o objeto funcionará conforme projetado em um teste de unidade para um SUT diferente não viola necessariamente o teste de unidade. Se esse teste fosse interrompido devido a uma alteração no domínio, esperaria que o teste de unidade do objeto de domínio também fosse interrompido, o que me levou a algo a ser investigado. Se o teste de unidade do objeto de domínio foi atualizado corretamente como um teste vermelho, ficou verde com a alteração e esse outro teste falhou, isso também não é necessariamente uma coisa ruim; significa que as expectativas desse outro teste estão em conflito com as novas expectativas para o domínio, e eu preciso garantir que ambos concordem um com o outro e com os critérios gerais de aceitação do sistema.
Como tal, eu apenas zombaria de um objeto de domínio se esse objeto de domínio produzisse "efeitos colaterais" indesejáveis do ponto de vista do teste de unidade (por exemplo, tocar em recursos externos como armazenamentos de dados) ou se a lógica do objeto de domínio fosse suficientemente complexa que colocá-lo no estado apropriado para o teste se torna um obstáculo para definir e passar no teste.
Isso então se torna a questão motriz; qual é mais fácil? Para usar o objeto de domínio para a finalidade pretendida dentro do teste ou para zombar dele? Faça o que for mais fácil, até que não seja mais a opção mais fácil, como quando uma mudança funcional interrompe o teste do serviço de maneira complexa; se isso acontecer, reescreva o teste para produzir uma simulação que exponha os requisitos funcionais dos quais o serviço depende, sem a complexidade que o interrompe.
Entenda que, de qualquer maneira, deve haver um teste de integração que use o objeto de domínio real conectado ao serviço real que teste a interação entre os dois em um nível mais alto de abstração (como testar, por exemplo, não apenas a funcionalidade por trás de um serviço terminal, mas um proxy através do qual o objeto de domínio é serializado e enviado).