Como isso faz sentido?
Resposta curta: não .
Resposta mais longa: os padrões pesados para o desenvolvimento de um modelo de domínio não se aplicam às partes da sua solução que são apenas um banco de dados.
Udi Dahan teve uma observação interessante que pode ajudar a esclarecer
Dahan considera que um serviço precisa ter algum tipo de funcionalidade e alguns dados. Se não possui dados, é apenas uma função. Se tudo o que faz é executar operações CRUD nos dados, então é o banco de dados.
O objetivo do modelo de domínio, afinal, é garantir que todas as atualizações dos dados mantenham os negócios atuais invariáveis. Ou, em outras palavras, o modelo de domínio é responsável por garantir que o banco de dados que atua como o sistema de registro esteja correto.
Quando você está lidando com um sistema CRUD, geralmente não é o sistema de registro dos dados. O mundo real é o livro de registro e seu banco de dados é apenas uma representação em cache local do mundo real.
Por exemplo, a maioria das informações que aparecem em um perfil de usuário, como um endereço de email ou um número de identificação emitido pelo governo, tem uma fonte de verdade que mora fora da sua empresa - é o administrador de email de outra pessoa que atribui e revoga endereços de email, não seu aplicativo. É o governo que atribui os SSNs, não o seu aplicativo.
Portanto, você normalmente não fará nenhuma validação de domínio nos dados que chegam do mundo exterior; você pode ter verificações para garantir que os dados sejam bem formados e higienizados adequadamente ; mas não são seus dados - seu modelo de domínio não recebe veto.
Em uma abordagem DDD usando camadas, parece que as operações CRUD passam pela camada de domínio. mas pelo menos no nosso caso, isso não parece fazer sentido.
É o caso do caso em que o banco de dados é o livro de registro .
Ouarzy coloca desta maneira .
No entanto, trabalhando em muito código legado, observo erros comuns para identificar o que está dentro do domínio e o que está fora.
Um aplicativo pode ser considerado CRUD apenas se não houver lógica de negócios em torno do modelo de dados. Mesmo nesse caso (raro), seu modelo de dados não é seu modelo de domínio. Significa apenas que, como nenhuma lógica de negócios está envolvida, não precisamos de abstração para gerenciá-la e, portanto, não temos um modelo de domínio.
Usamos o modelo de domínio para gerenciar os dados que pertencem ao domínio; os dados de fora do domínio já são gerenciados em outro lugar - estamos apenas armazenando em cache uma cópia.
Greg Young usa os sistemas de armazém como uma ilustração primária das soluções em que o livro de registro está em outro lugar (ou seja: o piso do armazém). A implementação que ele descreve é muito parecida com a sua - um banco de dados lógico para capturar mensagens recebidas do armazém e, em seguida, um banco de dados lógico separado, armazenando em cache as conclusões tiradas da análise dessas mensagens.
Então, talvez tenhamos dois contextos limitados aqui? Cada um com um modelo diferente para uminvestment account
Talvez. Eu ficaria relutante em classificá-lo como um contexto limitado, porque não está claro o que outras bagagens acompanham. Pode ser que você tenha dois contextos, pode ser um contexto com diferenças sutis na linguagem onipresente que você ainda não entendeu.
Possível teste decisivo: quantos especialistas em domínio você precisa de dois especialistas em domínio para cobrir esse espectro ou apenas um que fale sobre os componentes de maneiras diferentes. Basicamente, você pode adivinhar quantos contextos limitados você tem, trabalhando a lei de Conway de trás para a frente.
Se você considera que os contextos limitados estão alinhados com os serviços, pode ser mais fácil: você deve implantar essas duas peças de funcionalidade independentemente? Sim sugere dois contextos limitados; mas se eles precisam ser sincronizados, talvez seja apenas um.
