DDD & Co., parte 1: O que é errado com CRUD

A aplicação é a TodoMVC "Olá, mundo" Web: O que foi originalmente concebido como uma comparação pura de diferentes frameworks de UI, amadureceu em seu próprio ecossistema. Se você deseja implementar lado do servidor do aplicativo, então por que não com Domain Driven projeto (DDD)?

DDD & Co.

  • Episódio 1: O que é errado com CRUD
  • Episódio 2: semântica em vez CRUD
  • Episódio 3: Comandos e Eventos
  • Episódio 4: Agregados

À primeira vista TodoMVC parece inofensivo: é uma lista de tarefas simples, onde você pode adicionar novas entradas e editar os existentes. formulários de inscrição preenchidos podem ser marcar e, finalmente, você pode remover as entradas para limpar novamente.

O exemplo parece tão trivial que é pouco inclinado a pensar, não para implementar a aplicação com CRUD: pode alterar uma lista, onde você adicionar entradas e excluir - como você corrigi-lo de outra forma?

CRUD é óbvia - ou não?

Em uma inspeção mais próxima, no entanto, há uma série de perguntas, pelo menos, levantar dúvidas de que a aplicação é realmente tão trivial quanto parece. Tal questão é se há uma diferença entre remover uma entrada que já está feito, e a remoção de uma entrada que ainda não está concluído.

TodoMVC TodoMVC é uma simples lista de afazeres.

Primeiro de tudo, deve-se notar que ambos são ações diferentes. Eles podem ser exibido na interface do utilizador usando os mesmos controlos, e o resultado pode ser a mesma, mas apenas os dois processos diferem do estado da aplicação fundamentalmente. Isso fica claro, o mais tardar ao introduzir a regra de que apenas as entradas podem ser removidos que já está feito.

Os dois processos diferem grave também do ponto de vista do utilizador. Por remover usuários uma entrada em um e por isso em outro caso: A fim de reconhecer isso, um tem que fazer a pergunta sobre a intenção?

notar a intenção

Seria concebível que os usuários remover itens ainda não concluídas, porque eles são obsoletos - eles são, portanto, descartado. Na verdade, os itens já concluídas são, no entanto, removido para manter a ordem na lista. No entanto, esses itens ainda são interessantes em certas circunstâncias, por exemplo, para descobrir depois que você tem feito tudo dentro de um determinado período.

Existem outras distinções: TodoMVC permite que os usuários, por exemplo, para alterar o texto de uma entrada. Em crud que seria um UPDATE, bem como o tique-taque de uma entrada completa. Mas ambos os processos são diferentes em intenção a sério: em um caso se trata de corrigir ou ajustar um item, o outro ao redor da-feito-Mark.

Que essas distinções existir mesmo impressionante quando se imagina TodoMVC com caneta e papel. Ninguém iria coloquialmente "Atualizar a terceira entrada!" dizem que se você bem "Pescada à terceira entrada do!" pode dizer o que é mais natural e também mais clara. O núcleo deste caso: A primeira formulação é um ponto puramente técnico, o segundo é tecnicamente e leva em conta a intenção.

a palavra "verificar fora" tem um significado técnico, com um associa automaticamente uma ação tangível da realidade. a palavra "ATUALIZAÇÃO" no entanto, apenas descreve o processo puramente técnica de manipulação de dados no nível de tabela.

Jargão vs. tecnologia

Isso mostra um dos maiores obstáculos no desenvolvimento de software todos os dias: A linguagem técnica e profissional diferem uns dos outros - e, geralmente, a linguagem técnica é muito menos expressivo do que o profissional. Isso dificulta a comunicação entre especialistas e desenvolvedores enormes já que em ambos os sentidos é necessário um mapeamento contínuo.

Isso também resulta em que a terminologia não está claramente definida: Uma vez que eles já estão constantemente traduzir termos técnicos e re-traduzir necessidades, tempos de "verificar fora" falar, às vezes por "ameixa seca" e horários de "esquecer", Se os três termos realmente significam a mesma operação ou se, talvez, estar por trás de vários conceitos dificilmente é questionada.

Em vez disso, suposições implícitas são feitas constantemente, em última análise, no entanto, muitas vezes significa que a implementação técnica não atender aos requisitos técnicos. Mas que cai sobre apenas quando é tarde demais para mudar apenas com um monte de tempo e custo financeiro são possíveis.

CRUD perde História

Além disso, outro problema apenas acrescenta: CRUD perder a história. Alterar usuário, por exemplo, várias vezes uma entrada no decorrer do tempo, as etapas de processamento individuais podem não entender. Pior: ele não pode nem mesmo entender se a entrada já foi alterado.

Claro que pode a obter um controlo através da inserção de um campo para um timestamp da última atualização. Mas mesmo isso não ajuda a ser capaz de recuperar os status de processamento individuais novamente. Para isso, quer um número de campos ou igual a uma nova tabela precisa criar.

O problema é que, porque você não sabe o que perguntas são feitas sobre os dados no futuro, você não pode otimizar as suas respostas nas mesas. portanto, recolher tanto muitos ou poucos dados, mas certamente sempre as erradas. Então por especialistas tais questões como solicitado, eles podem - se em tudo - única resposta com a felicidade:

Normalmente, a resposta será em cada uma dessas perguntas que você teve que escrever o código em primeiro lugar, que recolhe os dados e armazena relevantes. Então só se deve esperar algumas semanas ou meses, e já se podia entregar a avaliação desejada. Isso está longe de ser satisfatória, é óbvio.

O que está errado com CRUD

Se você considerar tudo isso, há uma imagem assustadora para CRUD. Desde que as operações atualizar e excluir destruir dados irreversivelmente a dados históricos não pode ser avaliada sem esforço adicional. Além disso, a limitação artificial para apenas quatro verbos faz com que a comunicação entre especialistas e desenvolvedores de falhar é difícil e muitas vezes.

Então por que estamos constantemente usando CRUD? A resposta é geralmente porque nós não aprendemos contrário. O modelo é tão simples e básico que conhece cada desenvolvedor em um estágio inicial - e uma vez que todos usá-lo, quase ninguém perguntou-lhes sentido e absurdo.

Mas isso levanta um monte de problemas CRUD depois de um início rápido, é muitas vezes esquecido. Como rapidamente você se deparar com esses problemas, ainda mostra um exemplo simples de modo TodoMVC.

O próximo episódio de "DDD & Co." o conceito de Domain-Driven Design (DDD) é pensado como uma alternativa para modelar o profissionalismo que rompe com a idéia básica de esquema de banco de dados relacional e se concentra sobre os aspectos técnicos realmente relevantes para a ribalta.

CRUD é simples, mas limitado: A restrição artificial em quatro verbos e a processos destrutivos UPDATE e DELETE causam numerosos problemas que tornam-se rapidamente sentida em pequenas aplicações dr; TL.