Boa tarde Alan.
Acho que você está com uma definição errada de domínio. Na abordagem do DDD, domínio é refente às regras de negócio. Ou seja, o domínio trata das questões de funcionalidade do sistema.
Por exemplo, o domínio de um sistema de ERP é todas as regras de negócio, legislação fiscal, etc, que devem ser contempladas pelo sistema. Você consegue identificar seu domínio quando olha para o sistema a partir
do prisma do cliente, o qual possui uma visão focada apenas no valor de negócio que o sistema irá gerar.
O domínio não é o sistema todo, ele é apenas a parte de negócio, como alguns gostam de definir, BLL (Business Logic Layer - Camada de Lógica/Regra de negócio). Questões referentes à infra-estrutura,
como relacionamentos com a base de dados ou lógica de interface não fazem parte do domínio.
Não entendi muito bem o que você quis dizer com uma aplicação fora do domínio, mas acredito que você se refere a aplicações que fogem do escopo do sistema ou implementações internas que
não satisfazem diretamente uma regra de negócio. Na filosofia do DDD, você deve implementar apenas aquilo que é necessário ao domínio, mesmo que às vezes tenha que deixar de lado práticas comuns de orientação
a objeto por exemplo. Esta filosofia prega que deve ser implementado apenas aquilo que é necessário para atender uma necessidade do domínio, nada mais do que isso. Qualquer implementação que fuja desta regra está fora
do domínio.
Infra-estrutura é toda a parte de relacionamento com o banco de dados por exemplo. A conexão com a base não faz parte do escopo do domínio, é uma implementação específica que varia de banco para banco,
e a camada do domínio não tem que se preocupar com isso.
Em relação às suas duas ultimas perguntas, utiliza-se o padrão de repositório justamente para abstrair a implementação da infra-estrutura. Vamos olhar um caso prático. Você esta desenvolvendo
um sistema com um conjunto de regras de negócio que deve armazenar um conjunto de informações na base de dados. Ao utilizar o padrão de repositório, sua camada de negócio não tem conhecimento sobre qual banco
está sendo utilizado ou como os dados são armazenados. Se você usa NHibernate ou Entity Framework é invisível para sua camada de negócio. Dessa forma, se em sua implementação inicial você utiliza
uma base oracle e posteriormente necessite migra para SQL Server, você não terá que refazer nenhuma implementação na camada de negócio, basta apenas refazer sua camada de infra-estrutura que se relaciona com a Base.
Se você utiliza DAL/DAO, fica preso à infra-estrutura, ou seja, a qual banco de dados está utilizando. O que claro, não é uma boa coisa. DAL/DAO é uma implementação específica, que varia de acordo
com o tipo de banco de dados, Repositório é uma interface genérica, que espõe apenas os operações e pode ser implementada para qualquer base de dados, e é acessada pelo dompinio do sistema.
Espero que tenha esclarecido sua dúvida, qualquer dúvida estou à disposição.
