odontoprev_desafio

Desafio técnico Arquiteto de soluções.

Requisitos

1. Python versão maior ou igual a 3.8.
2. Linux.

Usage

1. git clone <este_repo> && cd <este_repo_dir>
2. ./setup_hml.sh
3. Postman collections <'odontoprev(...)collection.json> no repositório.

Rationale

• Assunções:
  • Por questões de tempo e se tratar dum teste, a solução concebida tem pouquíssimas dependências externas, portanto, a execução e validação é simples e rápida. [1]
  • Foi-se implementado componentes e funcionalidades da solução em somente algumas partes da aplicação devido ao ponto [1], e no documento .pdf do desafio na seção cenário há o seguinte trecho: “O seu desafio como Arquiteto de Solução (...) desenvolver uma parte da proposta de solução técnica (...)”.
  • Também não desenhos/diagramas da arquitetura da aplicação devido ao ponto [1], e por ser opcional segundo o documento .pdf do desafio na seção cenário.
    
    
• Endpoints:
  • Premissas:
    • /eventos: A propriedade código é do tipo inteiro. Por causa da descrição do motor de regras no .pdf do desafio.
      
      
• Arquitetura:
  • Implementação:

    • Banco de dados: sqlite.

    • Lógica backend/endpoint: AWS Chalice (framework), marshmallow.

      • O framework acima é excelente para POC’s, além de possuir muitas funcionalidades úteis, middlewares e.g, também vem com um light built-in http server para testes nos endpoints desenvolvidos.

    • Métodologia de desenvolvimento (parcial): TDD

  • Análise: Um dos primeiros passos é mapear os endpoints: construir schemas a partir da especificação, relações com outros endpoints, etc. Um pacote no python que auxilia bastante nisso é o marshmallow, pois este permite validar input data. Fora notadas algumas relações e requisitos compartilhados entre os endpoints neste desafio, logo, definiu-se alguns schemas para validação no diretório: /endpoints/schemas. Por meio do pytest + TDD, desenvolveu-se esses schemas. Em seguida, fora percebido que os endpoints 4 (Guia de Tratamento Odontológico), 5 (Prontuário Virtual) e regras de negócios 6 (Motor de regras) são condicionais a informações registradas no banco de dados através de cadastro nos endpoints 1 (Beneficiário), 2 (Dentista) e 3 (Evento). Quanto as funcionalidades 4 e 6, middlewares` auxiliarão.
    
    
  • Componentes:
    • Schemas: Responsável por validar os dados que o endpoint recebe.
    • Cli: Responsável por fazer o setup da aplicação antes de iniciar.
    • Middlewares: Responsável por validações posteriores na execução da lógica codada nos endpoints.
    • Interfaces:
      • Cursor: Permite a realização de queries no banco de dados a partir de qualquer componente da aplicação.
      • Motor de regras: Regras de negócios da aplicação, as quais as middlewares validarão.
    • Helpers: Alguns componentes possuem operações muito frequentemente usadas, portanto, este é responsável por desacoplar e abstrair a complexidade dessas.
    • Chalice views: Onde define-se os endpoints e suas lógicas, as quais se utilizam de outros componentes.
    
    
    
  • Comentários: A partir da Análise citada nesta seção, também foi interessante perceber as relações entre os endpoints, e a partir disso, tentar o máximo reduzir a complexidade em componentes frequentemente usados como foi o caso das operações: Cadastrar e Get. Todas as views da aplicação executam os dois, assim, fora definidos funções helpers para tal fim, mantendo o principio KISS. Além disso, as interfaces foram desenvolvidas com os principios SOLID em mãos. Não obstante, o design pattern utilizado foi o que o próprio framework aconselha como melhores práticas: Modularização por meio de blueprints.
    
    
  • Poréns: A solução é adequada para uma POC, e passível de escalar alterando somente as ferramentas utilizadas, o código si se mantém. Um dos primeiros pontos é o sqlite que não é assincrono e e seus datatypes são reduzidos, apesar das precauções quanto a deadlocks, em um ambiente altamente requisitado não se manteria, uma alternativa seria uma solução cloud como DynamoDB da AWS. Pensando nisto, utilizou-se o framework aws chalice que também é performático em produção. Outro ponto também é quanto a validação de input data, o ideal seria o gateway da API realizar, como é feito em alguns ambientes cloud que disponibilizam serviços de REST API.

TODO

• Componentes:

  • Schemas

    • Compartilhado
    • Beneficiário
    • Dentista

  • CLI

    • Criar banco de dados e tabelas

  • Middlewares

    • Simular sistemas distribuídos (requests)

  • Interfaces

    • Cursor (Banco de dados)
    • Motor de regras

  • Helpers

  • Chalice views

    • beneficiários
    • dentistas
    • eventos
    • guias