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.

Update: I updated the example on GitHub to Spring 2.5.X! The latest post on this topic is here.

Updating data is one of the most frequent use-cases in applications. But it might also be a painful task which results in a bunch of ugly code.

Usually we use Spring’s @Configuration to define some special beans. For example a data source: