In 2011, I wrote my Bachelor’s Thesis and about three years later in 2014 it was time for Master’s Thesis. I blogged a lot about both projects back then, but I never published the actual documents. The reason for that was that I wrote both thesis in cooperation with a company. My Bachelor’s Thesis has been a research project for IBM’s database development team (DB2 on z/OS) and my Master’s Thesis has been written for Informatica and their PIM team. So both documents have been under a blocking notice for a certain period of time. They have been confidential, if you want to say so. I wasn’t allowed to publish them.

Ich habe über die Weihnachtszeit mal wieder Schach gespielt - mehr schlecht als recht. Zusammen mit meinem Schwager bin ich auf Schacharena.de gelandet. Er hatte dort über viele Jahre Schach gespielt und nun also gegen mich.

If you are a backend developer like me, logging is the window to your application. Unlike in the frontend, there’s not much to see except of your log messages. Here are some of my personal guidelines I use when I write logs.

In an event-based system (like DDD) you will be notified about changes. For example, if the price of a product has changed, a PriceUpdatedEvent will be thrown. Any system interested in price updates can listen and react to those events.

This is the story of a data model which has been design up-front. It was one of the first implementation tasks done in a new project. With the least knowledge (begin of the project), we tried to figure out the domain.

About a month ago I published a short article about Kotlin, Spring Boot and DynamoDB.

During the last week I implemented my first persistence layer with DynamoDB using Spring Boot and Kotlin. As I stumbled over a couple of obstacles, I decided to summarize what I did and how my final implementation looked like.

Some weeks ago I published a demo project on GitHub showing a Domain Driven Design with Kotlin. You can find the original blog post right here. Now I took the approach one step further and added Event Sourcing to the demo. Here’s what I did.

I recently read Clean Architecture by Robert C. Martin. The book gives a simple advice: don’t depend on details! For Uncle Bob details are things like the database or message broker. Your architecture shouldn’t depend on the actual implementation of those details. Whether you are using Oracle, MySQL or DynamoDB, whether it’s ActiveMQ, Kinesis or an in-memory Guava event bus - your architecture shouldn’t be affected.

Three years ago I wrote a blog post with the title Don’t use Optionals for data repositories. The post received a couple of critical comments and I had the feeling that I didn’t make my point clear.