Os seis princípios para a criação de aplicativos de dados compartilhados robustos e flexíveis
Avalie esse Artigo
Passei meus sete anos trabalhando na MongoDB Inc. refletindo sobre como as organizações podem criar melhor aplicativos dinâmicos com uso intensivo de dados. Ao longo dos anos, em conversas com clientes, procurei transmitir minhas Opiniões sobre como isso pode ser alcançado, mas, em retrospectiva, só obtive sucesso limitado, devido à minha incapacidade de definir o "por que" e o "como " corretamente. Na verdade, quanto mais reflita, mais avalio que é um tema com o qual tenho lidado durante a maior parte da minha carreia em T.I. Por exemplo, de volta a 2008, quando o SOAP ainda era comum para construir web services, abordei um tema semelhante na publicação do meu blog Web Service Messaging Nirvana. Agora, depois de algum tempo, parece que finalmente conseguira localizar os sinais no meio do ruído e captá-los em algo coeso e que poderia ser acionado por outras pessoas...
Então, agora reuni um conjunto de técnicas que identifiquei para fornecer aplicativos orientados por dados resilientes, mas evolutivos, em uma palestra on-line gravada de 45minutos, que você pode ver abaixo.
Os seis princípios para a evolvabilidade resiliente de paul feito.
Também compartilhei, no Github, uma amostra do aplicativo Rust que criei e que destaca alguns dos padrões descritos.
Em minha palestra, você ouvirá sobre o possível atrito que pode ocorrer com vários aplicativos em diferentes trens de lançamento, devido à sobreposição de dependências em um conjunto de dados compartilhado. Sem premeditação, o impacto de fazer alterações no modelo de dados compartilhado para atender aos novos requisitos de um aplicativo também pode resultar na necessidade de modificar todos os outros aplicativos, reduzindo drasticamente a agilidade e a flexibilidade dos negócios. Você pode estar se perguntando: "Se esses dados compartilhados são mantidos em um banco de dados operacional moderno em tempo real como o MongoDB, por que o modelo de dados flexível do MongoDB não é suficiente para permitir que aplicativos e serviços evoluam facilmente?" Minha palestra explicará por que essa é uma suposição ingênua feita por alguns e por que a adoção de práticas recomendadas específicas, em seu nível de aplicativo, também é necessária para mitigar isso.
Na palestra, identifico as práticas recomendadas resultantes como um conjunto de seis princípios fundamentais, aos quais me refiro como "resilient evolvability." Abaixo está um resumo dos seis princípios:
- Suporte campos opcionais. A ausência de campo transmite significado.
- Para o Finds, peça apenas campos que sejam de sua preocupação, para oferecer suporte à variabilidade e reduzir a dependência da alteração.
- Para atualizações, sempre use operadores no local, alterando apenas os campos direcionados. A substituição de documentos inteiros elimina as alterações feitas por outros aplicativos.
- Para as raras Mudanças Mutativas do modelo de dados, adote a "Duplicação Provisória" para reduzir o atraso nos requisitos de negócios de alta prioridade.
- Facilite a variação de entidades, porque as entidades do mundo real variam, especialmente quando um negócio envolve e se versifica.
- Use os mapeadores de documentos somente se eles NÃO forem "tudo ou nada," e somente se eles se adequarem aos outros cinco princípios.
Além disso, na palestra, capturo minha perspectiva sobre as três diferentes combinações de arquitetura de aplicativos/dados distribuídos que vejo com frequência, que chamo de "O Triângulo de Acesso a Dados".
Em essência, minha palestra se concentra principalmente em como obter agilidade e flexibilidade quando dados compartilhados estão sendo usados por muitos aplicativos ou serviços, mas alguns dos princípios ainda serão aplicados ao usar dados isolados ou dados duplicados para cada aplicativo ou serviço.
Por experiência própria, ao adotar os seis princípios, acredito firmemente:
- Seu software permitirá dados estruturados variados que adotam, em vez de inibirem, os requisitos do mundo real.
- Seu software não quebrará quando ocorrerem alterações aditivas no modelo de dados, para atender rapidamente aos novos requisitos de negócios.
- Você terá um processo para lidar com alterações mutantes no modelo de dados, o que reduz os atrasos na entrega de novos requisitos comerciais.
Esta palestra e seus conselhos são o resultado de muitos anos tentando resolver e abordar os problemas nesse espaço. Espero que você ache minha orientação uma contribuição útil para o seu trabalho e um conjunto de princípios que todos podem desenvolver no futuro.
Se tiver dúvidas, acesse o site da nossa comunidade de desenvolvedores, no qual os engenheiros e a comunidade do MongoDB ajudarão você a desenvolver sua próxima grande ideia com o MongoDB.
Avalie esse Artigo