Desenvolvendo um site de gerenciamento financeiro #2
Classes e pensamentos por trás delas.
Isto foi originalmente postado no Medium.
Digamos que eu sou o nerd da vizinhança que de vez em quando arruma os computadores de todos os vizinhos, seus roteadores, impressoras e talvez até crie uma arte no Photshop… O que eu preciso saber para controlar meu dinheiro?
- Eu preciso saber quem me pagou e qual foi o serviço que eu prestei.
- Preciso saber onde eu comprei uma ferramenta e quanto ela custou.
- Preciso controlar a Janet que me paga mensalmente para que eu a ajude a entender sua própria tabela do Excel.
Então, de uma maneira bem básica, eu tenho uma empresa e eu preciso saber quanto meus clientes me devem e quando eu devo aos meus fornecedores.
Vamos dar uma olhada no diagrama da esquerda. Eu tenho 2 entidades principais: Person e Company. Eles dois compartilham muitas propriedades então eu decidi criar uma entidade pai que eu chamei de BaseEntity, ela mantém todas as propriedades que Person e Company compartilham.
Mais tarde, quando eu criar meu banco de dados, isso resultará em uma única tabela que conterá todos os campos listados no diagrama. Esta tabela conterá tantos os registros de Person quanto de Company e terá uma coluna extra que servirá de identificador que usaremos para saber quem é quem.
Você deve estar se perguntando, porque? Bem, isto serve para criar abstração que, mais tarde, me salvará de digitar algumas centenas de linhas de código.
Digamos que eu quero vender um serviço à alguém. Terei que criar uma view onde eu incluirei uma entrada no banco de dados que representará o serviço e o quanto ele custa. Abstraindo o destino deste serviço, eu não preciso criar 2 views diferentes para tratar cada caso. Se o destino deste serviço é uma Company ou uma Person, isto não fará diferença e eles serão tratados da mesma forma. Isto ficará mais claro conforme avançamos.
OK, agora nós temos as entidades principais que podemos usar no projeto. Mas como eu sei que uma pessoa é um cliente, uma empresa um fornecedor ou até que uma pessoa é um fornecedor? Isto é o que as próximas tabelas me dirão. Eu as chamarei de tabelas “lista” porque a sua única função é criar uma lista de entidades que farão parte de um perfil.
Digamos que eu tenho este amigo John que me ajuda de tempo em tempo. Ele é um fornecedor. Então ele será uma Person no meu banco de dados e seu id será listado na tabela de fornecedores mais tarde.
Um desenvolvedor experiente me dirá que existem outras formas de manter este relacionamento mas isto é realmente uma questão de opinião. Eu acho de simples entendimento e fácil de manter. Inclusive, muitas das decisões que eu tomo quando estou desenhando um banco de dados já levam em consideração a framework ORM que eu usarei. Neste projeto eu ainda não estou certo se usarei Ebean ou Hibernate.
Se eu decidir pelo Hibernate, o backend será uma aplicação Spring Boot usando spring-data-jpa e spring-data-rest. Se eu decidir pelo Ebean, eu posso estar inclinado a fazer tudo uma solução mais baseada em Kotlin, com Ktor, Kodein e completamente sem Spring. Mas veremos.
OK, vamos continuar. Falaremos de dinheiro agora. Eu manterei meu dinheiro em contas de banco. Eu posso ter mais de uma conta e meus fornecedores também podem ter suas contas. Nós manteremos os dados bancários de pessoas ou empresas no banco de dados apenas para o caso onde precisemos fazer uma transferência para eles, mas por enquanto, a aplicação vai tratar apenas a minha conta.
Como você pode ver, as contas de banco estão relacionadas ao BaseEntity o que me permite registrar contas de banco para todos no banco de dados.
Mas o que importa é apenas a minha conta. Então ela será a única que terá um saldo vinculado. Este saldo terá um valor para cada dia e ele será atualizado a cada operação monetária. A razão para uma tabela separada para isto é porque evita que eu tenha que realizar operações complexas para calcular o saldo sempre que eu precisar dele. Eu apenas pego o dia anterior caso não exista um saldo para hoje e somo ou diminuo deste saldo, salvando no dia de hoje. Isto tornará a criação de relatórios muito mais rápida e fácil posteriormente.
Agora as operações com dinheiro. Eu apenas criei uma BaseAccount que conterá as propriedades que são comum a qualquer operação. Estas operações serão sempre vinculadas a uma conta bancária que eu poderei somar ou diminuir de seu saldo.
Eu sei, tudo ainda é muito básico e simples. A ideia desta série é REALMENTE lhe dar um passo-a-passo do meu processo de desenvolvimento. Eu realmente não tenho nada pronto além deste UML e eu vou criar tudo enquanto posto aqui. Você provavelmente me verá mudando de opinião, refazendo, etc… Este processo será longo e eu espero que, ao menos, seja interessante. Se não for para você, que seja para mim 🙂
Te vejo no próximo post.
