SD Development

Backstory

A few years back, me and my then-girlfriend were toying with the idea of creating a tool that would help us get out shit together. It would be some sort of activity tracking and personal calendar mash-up that could be expanded to give suggestions on what to do if you had some time to spare.

Not much later, I was promoted at my previous job into a more senior position. This meant that I was getting less and less time to write code at work. Since I like creating things, and I wanted to stay technically relevant, I started working on implementing our idea.
Thus, TraMBU: Track My Bitch Up was born. The application name was inspired by a song made by The Prodigy.

Throughout it’s life, TraMBU has been through a whole bunch of redesigns. At first, it was something I quickly hacked together. The core logic was all in place, and it was looking like it would be a piece of cake to create the application. The biggest challenge I faced was creating a user-interface. At first, I made a dynamic web frontend in Wicket. Later, I used Angular. After that, I switched to JavaFX.
All these front-end changes had one thing in common: Huge rewrites of the entire codebase. It was a troublesome process.

So why go through all that trouble again?

Since creating the initial version of TraMBU a few years have passed. I have changed jobs, I moved to a different city, and I have a new girlfriend. I am now working in a company that pushes us to learn and grow as technical professionals. We have regular cross-team meetings where we study different approaches, learn working with new technologies, and teach each other from our own experience.
One of these knowledge sharing activities is reading technical books together. Our book of choice at this moment is: Patterns, Principles, and Practices of Domain-Driven Design - Millet, Tune 2015 [O’Reilly link]. This book talks about how to tackle a lot of frustrations that developers can have while working in an existing domain, and having to make changes to it. The core idea is: Divide and Conquer:

split the functional domain into contexts, so you know what you are talking about and how important things are.
split the technical domain into layers and modules, so the logic of your core domains is encapsulated and not polluted by technical decisions

Approaches like these usually sound very good in theory, but my practical experience shows me that apply these design frameworks too rigorously end up overcomplicating what in essence is a very simple application (such as TraMBU). However, since this project was started as a way to play with different technological solutions, it seems like a good candidate to verify the claims made in the book.

I want to see if I actually end up feeling more comfortable working in my own codebase, without having the urge to completely redesign it at every step.
AND
When I do inevitably rip out the frontend or persistence components, I don’t want to have to change absolutely everything

Progress so far

Days 1 - 3

Evenings during regular week

A considerable amount of time was spent thinking about things up-front, such as where to host certain functionality.
I struggled with Date representation, and remembered that this was also an issue when I first implemented the code. I must have gone from Date to LocalDate a bunch of times. This time might be different through use of the MicroType Pattern on dates.
I wrote three classes and test cases (trying to work Test-Driven)

Day 4

Weekend hacking

Decided I wanted some nice metrics
Spent 3 hours trying to set up SonarCloud into my gradle build
- Ripped out AssertJ because I thought SonarCloud did not recognize it
- ended up realizing I have to compile code coverage reports locally… Using Jacaco for this
- Got it working though!
- Available here: https://sonarcloud.io/dashboard?branch=ddd_redesign&id=be.doji.productivity%3Atrambu
- Gradle is pretty cool :)
- I feel pretty productive without actually having much to show for it

Next Steps