In their first week with Commit, each new Engineering Partner takes on a hackathon onboarding project. They build a project, present it to the Commit community, and write a short summary of their experience. There are no restrictions, no limits, no jokes.
For my hackathon onboarding project, I set out to build a travel expense tracker, to help travelers have full control over their costs by helping them track their expenses during trips. It will support offline usage so users can keep adding expenses even when they don’t have an internet connection.
My plan
My main goal here is to solve an issue I’ve been having myself: tracking how I spend my money. The daily expenses were easy to track because they don’t vary that much. However, as I started traveling more over the weekends it became a hassle to remember how much I was spending at restaurants, bars, and some paid outdoor activities. The application will allow users to create trips. Trips will have start and end dates. Ideally, a trip would be shared among many users, but for the sake of simplicity, user management is out of scope.
My process
The tech stack I used involved new technologies like TypeScript, NestJS, and GraphQL. I also decided to try a completely new approach (for me) by using domain-driven design and test-driven development after I took some courses on it. My goal was to exercise the domain knowledge of my application before getting to spend time in the tech stack itself.
By adopting DDD, my initial focus was to think of use cases for the application. Some examples include:
- Users should be able to create a trip
- Users should be able to add expenses to a trip
- When adding a new expense, users should be able to select an expense category and add a name and a value
With those listed out, I was able to start modeling my domain entities and explore how they related to each other. My next step was to set up the testing infrastructure so I could start adding tests. Tests are a fundamental piece of a good software project and given this one is a playground I decided to focus on them. Having tests in a project gives developers more clarity on how the software works—a sort of living documentation—and how it is supposed to behave.
My next steps
Even though I wasn’t able to get the full implementation going yet—yes, there’s a cost of sticking to DDD and TDD practices—I also got involved with my pilot project and that took most of my time. As of now, I have one use case fully implemented and some others as a working prototype. My next steps will be to connect these use case implementations to GraphQL resolvers so I can expose the backend logic to a frontend application that will interact with them.
Saulo Aguiar is a Commit Engineer who specializes in developing web applications and believes that engineering teams are a key component in startups. He advocates for engineering best practices like CI/CD, autonomy, and ownership, so engineers can help companies achieve their goals. When he is away from the computer he challenges himself surfing and playing drums.