Aplicativo Simples de Operações Bancárias - aplicando Java com Orientação a Objetos

Esse projeto foi desenvolvido no desafio de projeto de Programação Orientada a Objetos no Bootcamp Java e IA para iniciantes, da DIO e NTT Data. O projeto consiste em uma aplicação de console que permite o cadastro de contas bancárias e a realização de operações bancárias básicas, como depósito, saque, transferência, investimento e visualização do histórico de transações.

Índice

• Ferramentas e Tecnologias
• Funcionalidades
• Conceitos de Arquitetura e Design Patterns
• Tratamento de Erros
  • Validação das Regras de Negócio
  • Validação de Inputs do Usuário
• Demonstração da Solução
• Como utilizar

Ferramentas e Tecnologias

• Java: linguagem de programação utilizada para desenvolvimento da aplicação.
• GitHub: plataforma utilizada para armazenar o repositório de código-fonte e de documentação.
• IntelliJ IDEA: IDE utilizada para desenvolvimento da aplicação.
• Lombok: biblioteca Java utilizada para reduzir a necessidade de código boilerplate.
• Gradle: ferramenta de automação de build utilizada.

Funcionalidades

• Cadastro e exclusão de contas bancárias
• Login e logout de usuários cadastrados
• Depósito e saque de dinheiro
• Criar e resgatar investimentos
• Transferência PIX para outra conta
• Registro das transações realizadas
• Visualizar informações da conta, investimentos e histórico de transações

Conceitos de Arquitetura e Design Patterns

O projeto segue o padrão de Arquitetura em Camadas, seguindo os princípios da Programação Orientada a Objetos. A abordagem utilizada permite um desenvolvimento modular, com aumento na reusabilidade do código e clara Separation of Concerns (SoC), de forma que alterações em uma camada não interferem nas demais.

• Presentation Layer: responsável por exibir a interface do usuário e lidar com suas interações, enviando os inputs para a camada lógica de negócio. No projeto, essa camada foi implementada na classe Main, com uma interface baseada em console.
• Business Logic Layer: responsável por processar requisições do usuário, implementar as regras de negócio e mediar a interação entre a camada de apresentação e de acesso aos dados. No projeto, foi utilizado o Service Pattern para implementar essa camada, incluindo os serviços AccountService e InvestmentService.
• Data Access Layer: responsável por lidar com as interações com o banco de dados e executar operações CRUD. No projeto, foi utilizado o Repository Pattern para implementar essa camada com o AccountRepository.
• Database Layer: responsável por armazenar os dados da aplicação. Atualmente, o repositório simula as operações de um banco de dados real por meio de uma implementação "In-Memory", que armazena os dados em um HashMap apenas durante a execução.
• Comunicação entre as camadas: A comunicação ocorre em uma única via: Main utiliza Service para lidar com as interações do usuário, e Service acessa Repository para aplicar as regras de negócio. Apenas Repository pode acessar e manipular diretamente os dados.

A arquitetura descrita acima foi construída a partir dos princípios da POO, aprimorando a modularização, reusabilidade e manutenção das camadas.

• Classes e objetos: os componentes de cada camada foram implementados por meio de classes e objetos.
• Encapsulamento: os atributos das classes foram definidos como privados, sendo necessário o uso de métodos públicos para acessá-los e manipulá-los. A biblioteca Lombok foi utilizada para reduzir a verbosidade ao definir os @Getters e @Setters. Além disso, através da arquitetura em camadas, o acesso e manipulação dos dados foi protegido através da imposição de regras de negócio nos Services e restringindo o acesso direto para o Repository.
• Abstração: os serviços e o repositório implementam suas respectivas interfaces, permitindo uma alta abstração e facilidade de manutenção, baixo acoplamento e reusabilidade do código. Por exemplo, a implementação InMemoryAccountRepository poderia facilmente ser substituída por uma implementação em banco de dados real sem precisar alterar os serviços que a utilizam ou a interface do usuário.
• Polimorfismo: a abstração por meio das interfaces permite o uso de polimorfismo. Por exemplo, a implementação de uma interface sobrescreve (@Override) os métodos abstratos definidos na interface. Outro exemplo está na aplicação do "Dependency Inversion Principle (DIP)": as camadas do projeto dependem das abstrações (interfaces) e não das implementações, de forma que um objeto pode se comportar como a sua classe ou a interface.

Tratamento de Erros

O projeto implementa dois tipos principais de tratamento de erros: Validação de Regras de Negócio e Validação de Input de Usuários

Validação de Regras de Negócio (Service Layer)

Quando uma regra de negócio é violada, uma exceção unchecked específica é lançada, incluindo:

• IllegalArgumentException: dados inválidos que violam uma regra (por exemplo, tentar realizar uma operação com um número negativo).
• AccountNotFoundException: repositório não encontra a conta a partir do parâmetro fornecido.
• ExistentAccountException: tentativa de criar uma conta com dados únicos (CPF e PIX) já cadastrados;
• InsufficientBalanceException: tentativa de sacar ou transferir uma quantidade de dinheiro que excede o saldo atual.
• InvestmentNotAvailableException: tentativa de resgatar um investimento que já foi resgatado.
• InvestmentNotFoundException: repositório não encontra o investimento a partir do parâmetro fornecido.

As exceções lançadas na camada de serviço são capturadas na camada de apresentação por meio de um bloco try-catch, e é exibida uma mensagem de erro para o usuário antes de redirecionar para o menu. Dessa forma, a aplicação não "quebra" diante de qualquer exceção e o usuário é informado sobre o que aconteceu.

Validação de Inputs do Usuário (Presentation Layer)

Lida com erros no formato do input antes de enviar a informação para o Service. São utilizados métodos auxiliares com loops e blocos try-catch para garantir que o usuário insira a informação no formato correto. Se um dado inválido é inserido, o usuário é solicitado a tentar novamente.

Demonstração da Solução

Inicialmente, é exibido um menu que permite que o usuário escolha a opção de Login, Cadastro ou Encerrar, conforme é exibido na Figura 1.

Figura 1 - Menu inicial (Usuário não logado)

---

Cadastro da conta

Ao cadastrar uma nova conta, o usuário é solicitado a inserir CPF, nome, senha e pelo menos uma chave PIX. O usuário pode escolher adicionar mais de uma chave PIX e não é permitido adicionar uma chave que já está em uso (pelo próprio usuário ou por outro). A Figura 2 demonstra um caso de sucesso de cadastro de uma conta e a imposição da exclusividade da chave PIX.

Figura 2 - Cadastro bem-sucedido

---

A aplicação não permite o cadastro de mais de uma conta com o mesmo CPF conforme demonstra a Figura 3.

Figura 3 - Falha no cadastro: CPF já cadastrado

---

Login

Após fazer o cadastro, é possível fazer o login na aplicação com as credenciais cadastradas, conforme exibido na Figura 4.

Figura 4 - Login bem-sucedido

---

Figura 5 - Menu após o login

---

As figuras 6 e 7 demonstram falha no login por inserir credenciais inválidas. Na figura 6, a conta ainda não havia sido cadastrada. Na figura 7, a conta já estava cadastrada, mas a senha inserida estava incorreta.

Figura 6 - Falha no login: CPF não cadastrado

---

Figura 7 - Falha no login: Senha incorreta

---

Depósito

Para realizar o depósito, o usuário deve inserir um valor positivo para depósito. A figura 8 demonstra uma operação bem-sucedida, incluindo a imposição de inserção do número positivo.

Figura 8 - Operação de depósito

---

Saque

Para realizar o saque, o usuário deve inserir um valor positivo e que não ultrapasse o seu saldo atual. A figura 9 demonstra um saque bem-sucedido, e a figura 10 demonstra a falha no saque devido a saldo insuficiente.

Figura 9 - Saque bem-sucedido

---

Figura 10 - Falha no saque: Saldo insuficiente

---

Novo investimento

O valor do investimento é sacado do saldo da conta do usuário. Sendo assim, deve atender às mesmas condições do saque (valor positivo e menor ou igual ao saldo atual). Caso o saque seja bem-sucedido, é criado o novo investimento, com o valor e descrição fornecidos. A figura 10 demonstra o investimento bem-sucedido e a figura 11 uma falha devido a saldo insufiiente.

Figura 11 - Investimento bem-sucedido

---

Figura 12 - Falha no investimento: Saldo insuficiente

---

Resgatar investimento

Para resgatar um investimento, o usuário deve inserir o ID do investimento a resgatar. Todo o saldo do investimento (incluindo valor aplicado e rendimento) será depositado na conta principal.

Figura 13 - Resgate de investimento bem-sucedido

---

Não é permitido o resgate de investimentos inexistentes ou que já foram resgatados. A figura a seguir, por exemplo, demonstra um erro ao tentar resgatar um investimento que já foi resgatado.

Figura 14 - Falha no resgate: Investimento já resgatado

---

Visualizar detalhes de investimentos

Os rendimentos dos investimentos são simulados no momento da consulta do usuário, considerando o tempo de aplicação e a taxa de 1% de rendimento por mês. As figuras a seguir demonstram a exibição do resumo de todos os investimentos, e os detalhes de cada investimento.

Figura 15 - Resumo dos investimentos (Antes do resgate)

---

Figura 16 - Investimentos disponíveis (Antes do resgate)

---

Figura 17 - Investimentos resgatados (Após resgate)

---

Transferência via PIX

Para realizar uma transferência, o usuário precisa informar uma chave PIX da conta de destino e o valor da transferência. O valor será sacado da conta de origem, logo, deve atender às mesmas condições de um saque. A figura 18 demonstra uma transferência bem-sucedida e as figuras 19 e 20 demonstram erros por chave inexistente e saldo insuficiente, respectivamente.

Figura 18 - Transferência via PIX bem-sucedida

---

Figura 19 - Falha na transferência: Chave PIX inexistente</sma