Tenho várias preocupações ao tentar desenvolver o DDD primeiro com o código EF 4.2 (ou EF 4.1). Eu fiz uma extensa pesquisa, mas não encontrei respostas concretas para minhas preocupações específicas. Aqui estão as minhas preocupações:

O domínio não pode saber sobre a camada de persistência ou, em outras palavras, o domínio é completamente separado do EF. No entanto, para manter os dados no banco de dados, cada entidade deve ser anexada ou adicionada ao contexto EF. Eu sei que você deve usar fábricas para criar instâncias das raízes agregadas para que a fábrica possa registrar potencialmente a entidade criada no contexto da EF. Isso parece violar as regras DDD, pois a fábrica faz parte do domínio e não parte da camada de persistência. Como devo criar e registrar entidades para que elas persistam corretamente no banco de dados quando necessári

Deveria uma entidade agregada criar suas entidades filhas? O que quero dizer é, se eu tiver umOrganization e essaOrganization tem uma coleção deEmployee entidades, deveOrganization tem um método comoCreateEmployee ouAddEmployee? Caso contrário, onde é que a criação de umEmployeentidade @ tenha em mente que oOrganization raiz agregada 'possui' todos osEmployee entidade.

Ao trabalhar com o código EF primeiro, os IDs (na forma de colunas de identidade no banco de dados) de cada entidade são manipulados automaticamente e geralmente nunca devem ser alterados pelo código do usuário. Como o DDD afirma que o domínio é separado da ignorância da persistência, parece que expor os IDs é algo estranho no domínio, porque isso implica que o domínio deve lidar com a atribuição de IDs exclusivos para entidades recém-criadas. Devo me preocupar em expor as propriedades de ID das entidades?

Eu percebo que essas são questões de design em aberto, mas estou tentando fazer o possível para manter os padrões de design DDD enquanto estiver usando EF como minha camada de persistênci

Desde já, obrigado