Design conduzido de domínio vs design de banco de dados para um aplicativo da Web do MVC

Question

Estou expandindo / convertendo um aplicativo de formulários Web legado em um aplicativo MVC totalmente novo. A expansão é tanto em termos de tecnologia, bem como caso de uso de negócios. O aplicativo legado é um design conduzido de banco de dados bem feito (DBDD). Então, por exemplo, Se você tem diferentes tipos de funcionários como operador, supervisor, armazenamento de armazenamento etc e você precisa adicionar um novo tipo, basta ir e adicionar algumas linhas em algumas tabelas e voila, sua interface do usuário tem tudo para adicionar / atualizar o novo tipo de funcionário. No entanto, a separação das camadas não é tão boa.

O novo projeto tem dois objetivos principais

• extensibilidade (para atualizar e futuros requisitos de pipeline)
• desempenho

  Eu pretendo criar o novo projeto que substitui o design drened do banco de dados (DBDD) com um design acionado por domínio (DDD) mantendo o requisito de extensibilidade em mente. No entanto, passar de um design acionado por banco de dados para o projeto acionado por domínio parece impactar inversamente o requisito de desempenho se eu compará-lo ao desempenho do aplicativo Legacy DBDD. No aplicativo legado, qualquer chamada para dados da UI interagiria diretamente com o banco de dados e quaisquer dados serem retornados em forma de um datatarader ou (em alguns casos) um conjunto de dados.

  Agora com um DDD estrito no lugar qualquer chamada para dados será encaminhada através da camada de negócios e na camada de acesso a dados. Isso significaria que cada chamada inicializasse um objeto de negócios e um objeto de acesso a dados. Uma única página da interface do usuário pode precisar de diferentes tipos de dados e isso é um aplicativo da Web cada página pode ser solicitada por vários usuários. Também um aplicativo da Web do MVC sendo sem estado, cada pedido precisaria inicializar os objetos de negócios e os objetos de acesso a dados todos e todas as vezes. Portanto, parece que uma aplicação sem estado de MVC o DBDD é preferível ao DDD para desempenho.

  ou há uma maneira em DDD para atingir ambas, extensibilidade de que o DDD fornece e o desempenho que o DBDD fornece?

Answer 1

Você já considerou alguma forma de separação de consultas de comando, onde as atualizações são através do modelo de domínio, mas lêem como DatarReader?DDD completo não é sempre apropriado.

Answer 2

.

"agora com um DDD estrito no lugar qualquer chamada para dados será encaminhada através da camada de negócios e na camada de acesso a dados."

Eu não acredito que isso seja verdade, e certamente não é prático. Eu acredito que isso deve ler:

.

Agora com DDD estrito no lugar, qualquer chamada para uma transação será encaminhada através da camada de negócios e na camada de acesso a dados.

Não há nada que diga que você não pode chamar a camada de acesso de dados diretamente para buscar quaisquer dados necessários para exibir na tela. É somente quando você precisa alterar os dados que você precisa invocar seu modelo de domínio que é projetado com base em seu comportamento. Na minha opinião, esta é uma distinção chave. Se você direcionar tudo através do seu modelo de domínio, você terá três problemas:

.
1. tempo - vai demorar muito mais para implementar a funcionalidade, sem nenhum benefício.
2. Modelo Design - Seu modelo de domínio será ficado fora de forma para atender às necessidades consultando em vez de comportamento.
3. desempenho - não por causa de uma camada extra, mas porque você não será capaz de obter os dados agregados do seu modelo o mais rápido possível diretamente de uma consulta. i.E. Considere o valor total de todas as encomendas colocadas para um determinado cliente - é muito mais rápido para escrever uma consulta para isso do que buscar todas as entidades do pedido para o cliente, iterar e soma.

   Como Chriseyre2000 mencionou, CQRS visa resolver essas questões exatas.

Answer 3

Usar DDD não deve ter implicações significativas de desempenho em seu cenário.O que você se preocupou parece mais como uma questão de acesso a dados.Você se refere a ele como

.

Inicialize um objeto de negócios e um objeto de acesso a dados

Por que "inicializa" caro?Quais mecanismos de acesso a dados você está usando?

DDD com objetos de longa duração armazenados em um banco de dados relacional é geralmente implementado com o Orm. Se usado corretamente , ORM terá muito pouco, se houver, impacto no desempenho para a maioria dos aplicativos.E você sempre pode voltar as partes mais sensíveis ao desempenho do aplicativo para SQL bruto se houver um gargalo comprovado.

Para o que vale a pena, o NHibernate só precisa ser inicializado uma vez na inicialização do aplicativo, depois que ele usa o mesmo pool de conexão ADO.NET como seus leitores de dados regulares.Para que tudo se resume a um mapeamento adequado, buscando estratégia e evitando erros de acesso a dados clássicos como 'n + 1 selects'.