Hoje, foram realizados testes multidimensionais da equipe de solicitação de dados do banco de dados, cujo processo de desenvolvimento foi descrito em detalhes e muito detalhado aqui e aqui .
O que os testes mostraram? A equipe trabalha, mas ... no caso de uso em que você precisa usá-lo, é inconveniente configurá-lo.
Como mencionei na primeira publicação, para cada troca de dados com o provedor de serviços KYC, o maior número possível de registros relativamente poucos deve ser selecionado no banco de dados. Mais de uma dúzia. O comportamento do algoritmo para extrair registros do banco de dados dentro da estrutura de cada solicitação é idêntico, apenas as configurações são alteradas. Se eu escrevesse pela primeira vez um teste de integração que demonstrasse um caso de uso de combate, entenderia quais detalhes importantes não devem ser esquecidos. Um teste de integração pode ser assim:
describe('configure and run database requests', () => { const context = require('../src/storage/requestContext'); const requestHandler = require('../src/storage/requestHandler'); it('should get full recordset from db', (done) => { for(let key of context.rules.keys()) { let handle = requestHandler.bind(context, [key]); context.store.subscribe(handle); } const assert = checkDataIsReady.bind(context, [done]); context.store.subscribe(assert); const note = { Id: 1, UserId: 38 }; const start = { type: 'NOTE', note }; context.store.dispatch(start); }); function checkDataIsReady(args) { if(notAllDataIsHereYet()) return; checkUserRecord();
A cardinalidade da diferença é que preparamos as regras para a configuração da consulta com antecedência e as armazenamos no dicionário context.rules . E esse dicionário e outros objetos necessários para executar consultas e salvar os resultados estão contidos no contexto que coletamos do context.db armazenamento de banco de dados pré-configurado, no context.store armazenamento de contêiner de estado pré-configurado e no dicionário mencionado acima.
Nesse caso, as regras de configuração da consulta podem conter dados de sequência comuns, por exemplo, o nome da tabela da qual os dados devem ser solicitados, bem como métodos de fábrica que geram consultas ao banco de dados e métodos de envio que enviam ações para o contêiner de estado. Nessa situação, a configuração dos comandos necessários parece completamente diferente do que o código existente sugere.
Essa solução arquitetônica nos permite, entre outras coisas, definir vários níveis de verificações KYC, simplesmente na forma de conjuntos de strings ( Set ), que são usados como chaves ao armazenar regras de configuração de consulta. Por exemplo, se queremos enviar apenas dados pessoais e um endereço para verificação, simplesmente colocamos as chaves correspondentes no conjunto de linhas: user , person e address .
O teste acima mostra a opção de configuração máxima, ignorando todo o dicionário de regras e configurando um código de consulta generalizado, em tabelas específicas. Bem, como você pode ver no código abaixo, o lançamento real de solicitações ocorrerá como uma reação aos eventos da alteração do contêiner de estado:
let handle = requestHandler.bind(context, [key]); context.store.subscribe(handle);
Hoje não haverá descrição do processo de implementação em todos os detalhes de refrigeração, porque ainda não ocorreu ...