Developing a Finance Management Website #2

Classes and thoughts behind them

Marcelus Trojahn
Aug 31 · 5 min read

Let’s say I’m the neighborhood nerdy guy that occasionally fixes every neighbor’s computers, routers, printers and maybe even create some artwork on Photoshop or whatever. What do I need to know about my money?

  • I need to know who paid me and what was the service I provided.
  • I need to know where I bought some tool and how much it costed me.
  • I need to keep track of Janet that pays me monthly to help her figuring out her own Excel spreadsheet.

So, right now, in a very basic way. I have a Company and I need to know how much my Customers owe me and how much do I owe my Suppliers.

Let’s have a look on the diagram on the left. I have 2 main entities: Person and Company. They both share a lot in common so I decided to create parent entity that I called BaseEntity and it holds all properties a company and a person share.

Later, when I create my database, this will result in a single table that will contain all the fields listed in the diagram. This table will hold both Person and Company records and it will have an extra column that will hold an identifier that we will use to know which is which.

You might be asking yourself why? Well, this is to create abstraction and later save me from a few lines of code. Let’s say I wanna provide someone a service, I’ll have to create a view where I will create an entry for the service and how much it costs and then save it… By abstracting the target of this service, I don’t need to create 2 different views to treat each case. If the target is a Company or a Person, this will not matter and they will be treated the same way. This will become more clear as we progress.

OK, we now have the main entities we can use on our project… But how do I know if a Person is a Customer, a Company is a Supplier or even a Person is a Supplier? That’s what the next tables will do. I will call them “list” tables because their only goal is to create me a list of entities that will fit in a profile.

Let’s say I have this friend John and he helps me out from time to time. He is a supplier. So, John is gonna be a Person on my database and his id will be also listed in the Suppliers database.

A more experienced developer will tell me that there are several other ways to maintain this relationship but this is really a matter of opinion. I find this very easy to understand and to maintain. Also, many of the decisions I make when I’m designing a database are also taking into account the ORM framework I will use. In this project I am still not sure if I will use Ebean or Hibernate.

If I decide towards Hibernate, the back-end will be a Spring Boot application using spring-data-jpa, spring-data-rest, etc… If I decide towards Ebean, I might be inclined to create a more Kotlin-based solution with Ktor, Kodein and no Spring at all. But we will see.

OK, let’s continue. Let’s talk about the money now. I will keep my money into bank accounts. I can have more than one and also my Suppliers might have bank accounts as well. We will keep the information of other people’s or companies’ accounts in the database just in case we need to transfer some money to then, but for now, the application will only handle my own accounts.

As you can see, the bank accounts are related to the BaseEntity which allows me to register bank accounts for everyone in the database.

The thing is, the only bank account that really matters is mine. So my account will have a balance related to it. This balance will have a value for each day and it will be updated on every money operation. The reason for a separated table for this is to avoid having very complicated operations to calculate the balance. I’ll just take the previous day if there isn’t a balance for the current day yet, add or subtract from it and save it on the current day. This will make creating reports much faster and easier.

Now, the money operations. I’ll just have a BaseAccount that will hold common properties between the two money operations. These money operations will always be related to a bank account so we can add or subtract from it’s balance.

I know, it’s all still very basic and simple. The idea of this series is REALLY give you a step-by-step walk-through of my thinking process. I really have nothing done in this project other than this UML. I will be creating everything as I post here. You will probably watch me even changing my mind, refactoring, etc… This will be a long process and I hope it will be at least entertaining. If not for you, for me ;)

I’ll see you on my next post.

Marcelus Trojahn

Written by

dev. likes: kotlin, javascript, vue, react in that order. dbs: relational. also tries to write about dev stuff.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade