Desafio para avaliar as suas habilidades como desenvolvedor.
Você deve:
- Clonar esse repositório
- Em seu fork, atenda os requisitos descritos abaixo:
- Para aprendizes de padawan: tópicos que tiverem 🐣
- Para padawans: tópicos que tiverem 🐣 e 🐥
- Para jedis: tópicos que tiverem 🐣, 🐥 e 🐤
- Para mestres jedi: tópicos que tiverem 🐣, 🐥, 🐤 e 🐔
- Nos envie um e-mail com seu nome e link do repositório
O projeto consiste na implementação de duas aplicações (cliente-servidor) que simulem o processo de uma transação financeira.
Deve ser uma aplicação desktop simples utilizando WPF. O layout não será avaliado, mas a escolha de componentes e estrutura do XAML serão.
Deve haver duas telas principais:
- Tela de transação: input dos dados da transação e envio da transação para o servidor.
- Tela de consulta das transações efetuadas: lista das transações efetuadas.
Criar um catálogo de cartões virtuais (o número que você achar razoável para testar diferentes cenários), que estarão disponíveis quando o cliente for fazer uma compra. Esses cartões deverão ter propriedades a mais do que o cartão "básico" descrito abaixo.
- A senha de cada cartão do catálogo deve estar criptografada de algum jeito
- Com esse catálogo, a verificação da senha do cartão deve ser feita apenas pelo servidor
O servidor irá simular justamente o que a Stone é, uma adquirente.
No mundo real, uma adquirente se comunica com o banco (emissor do cartão de crédito/débito) e com a bandeira (Visa, MasterCard, American Express, etc). O servidor não precisará se preocupar com isso, apenas irá simular uma transação financeira de acordo com alguns parâmetros.
Sinta-se livre para utilizar a tecnologia que quiser, desde que cumpra os requisitos abaixo. õ/
O servidor deve esperar por uma transação. Assim que o cliente enviar uma requisição (como demonstrado no esquema a seguir), o servidor deve usar parâmetros de validação dos dados da transação e parâmetros randômicos (você pode usar outro parâmetro, mas documente em algum canto!) para retornar sucesso ou erro na transação.
Códigos de retorno
| Código | Explicação |
|---|---|
| Aprovado | Transação aprovada |
| Transação negada | Transação negada |
| Saldo insuficiente | Portador do cartão não possui saldo |
| Valor inválido | Mínimo de 10 centavos |
| Cartão bloqueado | Quando o cartão está bloqueado (dãa!) |
| Erro no tamanho da senha | Senha deve ter entre 4 e 6 dítigos |
| 🐤 Senha inválida | A senha enviada é inválida |
🐤 Você pode (e deve!) adicionar novos códigos de retorno.
Deverá ser capaz de cadastrar clientes que possam passar transações no seu servidor. O limite de crédito de cada cliente deve ser considerado.
A comunicação pode acontecer em JSON ou XML.
🐤 O modelo descrito aqui pode (e deve!) ser incrementado.
| Propriedade | Descrição |
|---|---|
| CardholderName | Nome do portador do cartão |
| Number | Os números que são impressos no cartão, podendo variar entre 12 à 19 dígitos |
| ExpirationDate | Data de expiração do cartão |
| CardBrand | Bandeira do cartão |
| Password | Senha do cartão |
| Type | Chip ou tarja magnética |
| HasPassword | Se o cartão possui senha. Apenas cartões de tarja magnética podem ter essa propriedade como True |
| Propriedade | Descrição |
|---|---|
| Amount | Valor da transação |
| Type | Tipo da transação |
| Card | Propriedades do cartão |
| Number | Número de parcelas, se for uma transação de crédito parcelado |
- Desenho e arquitetura da solução
- Padrões do projeto utilizados
- Organização, documentação e legibilidade do código
- 🐤 Mapeamento ORM
- Uso de biblioteca de terceiros
- Criatividade
- 🐤 Testes de unidade e mocking
Esse desafio foi inspirado no layout maravilhoso do projeto hire.me feito pela Bemobi.