Weekly review cw 17

Lack of time leads to less exercise

The Easter Monday travel day and my further education are my excuses for running less. Although I could get up earlier on the weekend (around 5 a.m.) to run before the course, I lack the discipline for that.

At the same time, I'm abandoning my push-up challenge again. My right shoulder probably isn't hurting from too much table tennis because I've completely stopped playing that for now, hoping it will get better.

• Monday Easter travel day.
• Tuesday 15 km run + 1.5 hours at the gym.
• Wednesday 11 km run due to knee problems from the previous day.
• Thursday 15 km run + 1.5 hours at the gym.
• Friday Rest day.
• Saturday Full-day training course.
• Sunday Full-day training course.

If you'd like, follow me on Strava

Late realization about event sourcing

In my project to develop therapy documentation, I'm using the concept of event sourcing for persistence (I reported on it in an article a few weeks ago). As part of this approach, I'm creating a data model for the administration website optimized for administration access – such a named read model. The data model links entities like therapist, patient, prescription, and documentation so employees can sort, filter, and navigate the lists.

So far, to populate the read model, I've listened to the corresponding events for each entity and written the model for therapists, based on therapist events, and patients, based on patient events. The approach worked perfectly for creating, updating, and deleting individual entities. As the development progressed, events arose that affect multiple entities—for example, a prescription that is subsequently changed to be assigned to a different patient, or documentation that is initially created without a prescription and is linked to the prescription once it has been entered.

So, I have a process for each entity that listens for the associated events. However, I don't control which process receives the events first. Because of the connections between the abovementioned entities, multiple processes now listen for the same events. It makes a difference whether I save the prescription change for the prescription and then update the patient based on this new data, or vice versa. Because I don't have control over the sequence, errors that are difficult to identify can creep in in the future. This is a classic concurrency problem.

As a solution, I initiated an extensive refactoring. There is a single process for all entities that listens for all events and secures the sequence. I can make the necessary changes to the respective entities and eliminate concurrency.

The late realization, which in retrospect was already apparent in some places—only I missed the signs—is this: To create a read model, all events linked in the read model must be considered together in one process. It's somehow obvious, but I had to learn this the hard way.

Start of my club manager training

My club manager further education at the Hamburger Sportbund began this weekend. I aim to structure the table tennis department better, make it more attractive to members, and advance the teams to higher leagues. This is based on good youth work, for which I completed my C-license coaching training last year. This weekend, I start with two eight-hour sessions on "Communication and Leadership."